L36 · Web Basics: URLs, HTTP, HTML, the DOM & JavaScript

1. How the Web Actually Works

Title

CS 161 · Lesson 36 of 45

URLs · the HTTP request/response model · HTML & frame isolation · CSS, JavaScript & the DOM — the browser model behind every web attack

2. By the end of this lesson you can…

Objectives

1. Break a URL into its three mandatory parts — protocol, location/domain, and path — and say which one picks the server.
2. Describe the HTTP request/response model, read a request's method/path/version + headers, and contrast GET vs POST (only POST has a body).
3. Explain the webpage as a distributed application and identify the security-relevant HTML elements, including why frames are isolated.
4. Trace the HTML → DOM → JavaScript-modifies-DOM → render pipeline and explain why page JS runs in a sandbox.
5. Map each piece of this model to the upcoming web attacks (SOP, sessions/CSRF, XSS, clickjacking) it makes possible.

3. What survived from L35 · SQL Injection & Code Injection?

Warm-up

4. Why a whole lesson on web basics

Concept

Every web attack in this unit — same-origin policy, sessions, CSRF, XSS, clickjacking — is an attack on how the browser and server talk. Before we can break the web, we have to model it precisely.

Where does it live?

§18.1 URLs name every resource

How does it travel?

§18.2–18.5 HTTP request/response

What gets rendered?

§18.6–18.9 HTML, the DOM & JavaScript

5. Which is which: Why a whole lesson on web basics

Matching

6. URLs — Naming Every Resource

Section

Part 1 · §18.1 protocol, location, path

7. §18.1 Every web resource has a URL

Concept

Concrete scenario: you type an address into the browser bar and a page loads. That address is a URL — a Uniform Resource Locator — and it's how the browser knows what to fetch and from where.

URL — A string that names a web resource. Every resource the browser loads — a page, an image, a script — is identified by a URL. It has three mandatory parts: a protocol, a location (domain), and a path.

8. Break it if you can: §18.1 Every web resource has a URL

Counterexample

9. §18.1 The three mandatory parts

Concept

Take the running example http://www.example.com/index.html. Read it left to right and it splits into exactly three parts.

http://www.example.com/index.html
\__/   \_____________/\________/
  |            |          |
PROTOCOL    LOCATION     PATH
(scheme)    (domain)

1. Protocol / scheme — comes before ://. For this course just HTTP and HTTPS (HTTPS = HTTP over TLS).
2. Location / domain — www.example.com: WHICH server to contact.
3. Path — /index.html: which resource to ask that server for.

10. By analogy: §18.1 The three mandatory parts

Analogy

11. §18.1 The location can carry more

Concept

The location part has two optional extras: a username@ prefix, and an explicit :port. If no port is given, the browser uses the protocol's default (80 for HTTP, 443 for HTTPS).

http://alice@www.example.com:81/index.html
       \___/ \_____________/ \_/
      userinfo    host       port

So www.example.com:81 means: contact that server on port 81 instead of the default 80. The port narrows down which service on the machine answers.

12. Teach it back: §18.1 The location can carry more

Explain it

13. §18.1 A URL is a mailing address

Intuition

Think of mailing a letter. The location/domain is the building you send it to — it routes the letter to the right place. The path is the apartment or person inside that building — it only matters once the letter has arrived.

The protocol is the postal service you use (regular vs certified mail) — it decides how the delivery is handled, here HTTP vs HTTPS.

Ask yourself: if you change only the path, does the letter go to a different building? (No — same building/server, different room. Only changing the domain changes the server.)

14. What rests on this: §18.1 A URL is a mailing address

Socratic

15. §18.1 Label every part of a URL

Worked example

16. Fill in: part for §18.1 Label every part of a URL

Comparison

17. Something is wrong here: 'the path tells the browser which server to contact'

Anomaly

18. Trap: 'the path tells the browser which server to contact'

Trap

19. HTTP — The Request/Response Model

Section

Part 2 · §18.2–18.5 methods & headers

20. §18.2 The request/response model

Concept

Concrete scenario: you click a link. Under the hood the browser opens a connection to the server, sends a request, and the server sends back a response. HTTP powers the web with exactly this back-and-forth.

HTTP request/response model — HTTP is a protocol where the CLIENT (browser) initiates a connection and sends a request; the SERVER responds with a reply. The client always speaks first; the server only answers.

21. Take the definitions apart: URL vs HTTP request/response…

Definition probe

22. §18.3 HTTP/1.1 is text; HTTP/2 is binary

Concept

HTTP/1.1 is text-based: a request or response is a header section followed by an optional payload body. You can read it by eye, which is why we study it.

HTTP/2 packs the same information into a binary wire format for speed — but the concepts are identical: same methods, same headers, same request/response idea. Learn HTTP/1.1 and you understand both.

23. §18.4 The structure of a request

Concept

The very first line of a request carries three things: the method, the path, and the version. After that come the request headers, one per line.

GET /index.html HTTP/1.1
Host: www.example.com
Dnt: 1
User-Agent: Mozilla/5.0

24. What each one costs: §18.4 The structure of a request

Trade off

25. §18.4 Why a separate Host header?

Intuition

The first line's path is just /index.html — no domain. But one server (one IP) can host many sites. So the request repeats the domain in the Host: header to say which site's /index.html it wants.

Ask yourself: where did the domain from the URL go? (It's in the Host: header. The browser split the URL — domain into Host:, path into the first line.)

26. §18.5 GET vs POST: two intents

Concept

Scenario: viewing a page vs submitting a login form. These are different intents, and HTTP gives them different methods.

• GET — for GETTING information. In the original model it shouldn't change server state. Data rides in the URL as query parameters.
• POST — for SENDING data that modifies state (logging in, posting a comment). The data rides in the request body.

The key structural fact: only POST has a body. GET passes its data through query parameters in the URL instead.

27. §18.5 A real GET request

Concept

A GET carries its data in the URL's query string — everything after the ?, as key=value pairs joined by &. There is no body.

GET /posts?search=security&sortby=popularity HTTP/1.1
Host: www.example.com

(no body)

The server reads search=security and sortby=popularity straight out of the path's query part. Because it's in the URL, it's visible in the address bar, bookmarks, and server logs.

28. §18.5 A real POST request

Concept

A POST puts its data in the body, below a blank line that separates headers from payload. This is how a login form sends a password.

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 35

username=alice&password=hunter2

The blank line marks the end of the headers; everything after it is the body. The username=…&password=… payload modifies state — it creates a logged-in session.

29. Predict the next row: §18.4–18.5 Read the parts of an HTTP request

Pattern

30. §18.4–18.5 Read the parts of an HTTP request

Worked example

31. Fill in: content for §18.4–18.5 Read the parts of an HTTP request

Comparison

32. §18.5 The model vs reality of GET

Intuition

The HTTP spec says a GET should be 'safe' — it shouldn't change server state, just retrieve. That's the intended contract. A verifier (or a cache, or a prefetcher) is allowed to assume GETs are harmless.

But the spec only says shouldn't, not can't. Nothing in the protocol stops a server from acting on a GET — and modern apps routinely do, via query parameters like /delete?id=7.

Ask yourself: why is this gap security-relevant? (A GET that changes state can be triggered just by loading a URL — no form needed — which is the heart of CSRF in L39.)

33. Trap: 'GET requests can't change server state'

Trap

34. Something is wrong here: 'GET requests have a body'

Anomaly

35. Trap: 'GET requests have a body'

Trap

GET /login HTTP/1.1
Host: www.example.com

username=alice&password=hunter2   <-- wrong: GET has no body

GET /login?username=alice HTTP/1.1   <-- GET: query params

POST /login HTTP/1.1                  <-- POST: body

username=alice&password=hunter2

36. Inspect it line by line: Trap: 'GET requests have a body'

Error analysis

37. The Webpage as a Distributed App + HTML

Section

Part 3 · §18.6–18.7 HTML & frame isolation

38. §18.6 A web page is a distributed application

Concept

Scenario: loading a page isn't 'downloading a document' — it's running a program split across two machines. There's a server-side component that generates the response and a browser-side component that renders it.

Distributed web application — A web page runs as two cooperating parts: a server-side component that produces the response, and a browser-side component (HTML/CSS/JavaScript) that the browser executes and renders. Both halves are part of one application.

39. §18.6 The media type tells the browser how to read it

Concept

The server's response includes a media type (a.k.a. content type) that tells the browser how to interpret the body — as HTML to render, an image to draw, JSON data, and so on.

HTTP/1.1 200 OK
Content-Type: text/html

<html> … </html>

Content-Type: text/html says 'treat the body as HTML.' The same bytes labeled differently would be handled differently — the label drives the interpretation.

40. §18.7 HTML structures the document

Concept

HTML (HyperText Markup Language) structures the page as a tree of nested elements written with tags like <tag>…</tag>. A few elements matter a lot for security.

<a href="https://example.com">a link</a>
<img src="photo.jpg">
<script>alert(1)</script>
<iframe src="https://other.com"></iframe>

41. What each one costs: §18.7 HTML structures the document

Trade off

42. §18.7 Why an inline <script> is special

Intuition

<img> and <a> just point at resources. But <script>alert(1)</script> is executable code embedded in the document — the browser runs whatever is between the tags as JavaScript.

Ask yourself: if an attacker could slip their own <script> tag into a page you view, what could they do? (Run arbitrary JS in that page — the entire basis of XSS in L40.)

43. §18.7 Frames embed a page inside a page

Concept

An <iframe> embeds one web page inside another. The outer page is the host; the inner page (the frame) is whatever the src points to — possibly a page from a different, untrusted site.

That's a real risk: the outer page is embedding a possibly-malicious inner page, and vice versa. So browsers enforce a protection.

Frame isolation — A browser rule that an outer page and an embedded inner frame CANNOT read or modify each other's contents. Each frame is walled off from the other, even though they're displayed together.

44. Predict the next row: §18.7 What an embedded frame can and can't do

Pattern

45. §18.7 What an embedded frame can and can't do

Worked example

<!-- served by a.com -->
<h1>A's page</h1>
<iframe src="https://b.com/widget"></iframe>

46. Which is which, by allowed?

Discrimination

47. Something is wrong here: 'an embedded iframe can freely read/modify the outer…

Anomaly

48. Trap: 'an embedded iframe can freely read/modify the outer page'

Trap

49. CSS, JavaScript & the DOM

Section

Part 4 · §18.8–18.9 the render pipeline

50. §18.8 CSS styles the page — and is dangerous

Concept

CSS (Cascading Style Sheets) controls how the page looks: colors, layout, positioning. It seems harmless next to JavaScript — but it isn't.

Used maliciously, CSS is as powerful as JavaScript: forcing a victim to load attacker-controlled CSS is roughly as dangerous as forcing them to run malicious JS. Styling can move, hide, and overlay elements to trick or exfiltrate.

51. §18.9 JavaScript runs in the browser

Concept

JavaScript is the programming language the browser runs. Crucially, page JavaScript can arbitrarily modify any HTML or CSS on the page — add elements, change text, restyle, rewrite the whole document.

JavaScript on a page — Code the browser executes as part of rendering a page. It can read and arbitrarily modify the page's HTML and CSS at runtime — which is why injecting attacker JavaScript (XSS) is so powerful.

52. §18.9 The DOM is the parsed tree

Concept

JavaScript doesn't edit the raw HTML text. The browser first parses the HTML into an internal tree structure — the DOM — and JS manipulates that tree.

DOM (Document Object Model) — The browser's internal, in-memory TREE representation of a parsed HTML document. JavaScript reads and modifies the DOM (not the original HTML text), and the browser renders the DOM to the user.

53. §18.9 The render pipeline

Concept

Putting it together, a page is rendered in a pipeline. HTML comes in as text; the browser builds the DOM; JavaScript modifies the DOM; the browser renders the final DOM to the screen.

HTML text  --parse-->  DOM tree  --JS modifies-->  DOM'  --render-->  pixels

Every change JavaScript makes happens on the DOM tree, and the user only ever sees the rendered DOM — not the original HTML the server sent.

54. §18.9 HTML is the recipe; the DOM is the cake

Intuition

The HTML text is like a recipe the server hands over. The browser 'bakes' it into the DOM — a live, structured object. JavaScript can then change the cake after it's baked (add a layer, restyle the frosting).

If you only read the recipe (the raw HTML), you might miss what JS did afterward. The user eats the cake (the rendered DOM), which can differ from the recipe.

Ask yourself: when an attacker injects a <script>, does it attack the recipe or the cake? (Both — it rides in as HTML, then runs and rewrites the live DOM that the user actually sees.)

55. What rests on this: §18.9 HTML is the recipe; the DOM is the cake

Socratic

56. §18.9 JavaScript runs in a sandbox

Concept

Because page JS is so powerful, browsers run it in a sandbox: page JavaScript can't touch your files or read other sites' data. It's confined to its own page's world.

JavaScript sandbox — The restricted environment the browser runs page JavaScript in. Sandboxed JS cannot access the local filesystem or other origins' data — it can only act within its own page/origin.

The sandbox is why visiting a web page is (mostly) safe even though the page runs arbitrary code: that code is boxed in.

57. Teach it back: §18.9 JavaScript runs in a sandbox

Explain it

58. §18.9 JS is the browser's attack surface

Concept

Most browser exploits need JavaScript. Either the JS engine itself is the target (a bug in how it runs code), or JS is used to shape memory so a separate bug becomes exploitable.

And JS is JIT-compiled to machine code for speed — the just-in-time compiler is itself complex attack surface. So 'just turn off JavaScript' really does shrink the attack surface, at the cost of a broken web.

59. By analogy: §18.9 JS is the browser's attack surface

Analogy

60. What has to happen first: §18.9 HTML → DOM → JS modifies DOM → render

Ranking

61. §18.9 HTML → DOM → JS modifies DOM → render

Worked example

<p id="greet"></p>
<script>
  document.getElementById('greet').textContent = 'Hi, Alice';
</script>

62. Which is which, by the <p id=greet> node

Discrimination

63. Trap: 'page JavaScript can read any file on your computer'

Trap

64. Something is wrong here: 'the DOM is the same as the raw HTML text'

Anomaly

65. Trap: 'the DOM is the same as the raw HTML text'

Trap

66. Why This Model Powers the Attacks

Section

Part 5 · the bridge to L37–L42

67. Each piece maps to a coming attack

Concept

Everything in this lesson is load-bearing for the rest of the web unit. Here's the map from mechanism to attack.

68. Fill in: enables for Each piece maps to a coming attack

Comparison

69. Statelessness is why cookies exist

Intuition

HTTP has no built-in memory: each request stands alone, with no notion of 'who sent the last one.' That's statelessness.

So to stay logged in, the browser attaches a cookie to each request — that's how the server recognizes you across requests. Sessions (L38) and CSRF (L39) both flow directly from this patch.

Ask yourself: if cookies ride on EVERY request to a site, what happens when a different site triggers a request to it? (Your cookie goes along — which is exactly the CSRF problem.)

70. Break it if you can: Statelessness is why cookies exist

Counterexample

71. ⊕ Supplemental tools to flag (beyond §18)

Concept

⊕ Supplemental — beyond §18.1–18.9. A few practical pieces you'll meet when we use this model in attacks and defenses.

• ⊕ innerHTML vs textContent — writing user data with innerHTML parses it as HTML (can inject <script>/XSS); textContent treats it as plain text (safe). The choice is an XSS sink (L40).
• ⊕ fetch / XMLHttpRequest — JS APIs that make HTTP requests from the page itself, governed by the same-origin policy and CORS.
• ⊕ Browser dev tools — inspect the live DOM, network requests, and console; how you SEE the rendered DOM vs the raw HTML.
• ⊕ URL-parsing confusion — different parsers disagree on where the host ends (e.g. http://a.com\@b.com), enabling SSRF/open-redirect tricks.

72. Something is wrong here: 'HTTP remembers who you are between requests'

Anomaly

73. Trap: 'HTTP remembers who you are between requests'

Trap

74. Which of these survive contact with L36 · Web Basics: URLs, HTTP, HTML, the DOM…?

Two truths and a lie

75. Without one step: The web-model playbook

Constraint

76. The web-model playbook

Pattern

1. Parse the URL: protocol (HTTP/HTTPS) · location/domain (which server) · path (which resource). The DOMAIN picks the server; optional user@ and :port extend the location.
2. Read the HTTP request: first line = method + path + version; then headers (Host: repeats the domain); blank line; optional body.
3. GET vs POST: GET gets info and should be side-effect-free, data in URL query params, NO body. POST sends state-changing data in a BODY. Only POST has a body.
4. Render pipeline: server response (with a media type) → HTML → browser parses to the DOM tree → JavaScript arbitrarily modifies the DOM → browser renders. The user sees the DOM, not the raw HTML.
5. Containment: frames are isolated (no cross-frame read/write, but the outer page controls geometry); page JS is sandboxed (no files, no other origins). CSS is as powerful as JS when forced on a victim.
6. Map to attacks: origin (scheme+host+port) → SOP (L37); stateless HTTP + cookies → sessions/CSRF (L38/L39); DOM + injected <script> → XSS (L40); iframe geometry → clickjacking (L41).

77. Where does it stop working: The web-model playbook

Edge cases

78. Rule out three: Checkpoint — which statement is TRUE?

Elimination

79. Checkpoint — which statement is TRUE?

Check

A browser loads https://shop.example.com/cart?id=7, the page's JavaScript rewrites part of the page, and a login form POSTs a password. Think through URL parts, GET vs POST, the DOM, and the JS sandbox before choosing.

80. Misconceptions to retire

Concept

• The path selects the server — no: the LOCATION/domain does; the path is requested from it.
• GET can't change server state — no: the spec says it SHOULDN'T, but servers often do (the seed of CSRF).
• GET requests have a body — no: only POST has a body; GET uses URL query parameters.
• An iframe can read/modify its parent page — no: frame isolation walls them off (it only controls geometry).
• Page JavaScript can read local files — no: it's sandboxed to its own page/origin.
• The DOM is the raw HTML text — no: the DOM is the PARSED tree the browser built and JS manipulates.

81. Synthesis — the browser is a TCB running untrusted code

Concept

• This browser/protocol model is the foundation of the entire web-attack unit — every L37–L42 attack is an attack on a mechanism defined here.
• The origin = scheme + host + port (read straight off the URL) is what the Same-Origin Policy (L37) is defined over — never the path.
• HTTP's statelessness is why cookies/sessions exist at all; cookies ride on every request (L38), and that they ride even on cross-site-triggered requests is CSRF (L39).
• Injected <script> runs in the page's origin with full DOM power → XSS (L40); iframes + frame-isolation's geometry gap → clickjacking (L41).
• Back to the §1 trust-boundary idea (L2/L3): the browser is a TCB that must safely run UNTRUSTED code (HTML/CSS/JS) from every site you visit — the sandbox and frame isolation are the trust boundaries enforcing it.

82. Primary sources & where to read more

Concept

• Textbook §18.1 — URLs and their three parts: protocol, location/domain, path.
• Textbook §18.2–18.5 — the HTTP request/response model, HTTP/1.1 vs HTTP/2, request structure and headers, GET vs POST.
• Textbook §18.6–18.7 — the web page as a distributed app, media types, HTML elements, and frame isolation.
• Textbook §18.8–18.9 — CSS (as powerful as JS), JavaScript, the DOM, the render pipeline, the sandbox, and JIT.
• RFC 9110 (HTTP Semantics) and RFC 3986 (URI/URL syntax) — the authoritative protocol definitions; WHATWG DOM Living Standard — the DOM; MDN Web Docs ⊕ — readable HTTP/DOM overviews.
• Next lessons: the Same-Origin Policy (L37), cookies & sessions (L38), CSRF (L39), XSS (L40), and clickjacking (L41) all build directly on this model.

83. Connect it up: L36 · Web Basics: URLs, HTTP, HTML, the DOM & JavaScript

Connect it up

84. Recap — Lesson 36

Recap

You can now split a URL into protocol/location/path and name which part picks the server, read an HTTP request and tell GET from POST (only POST has a body), explain the page as a distributed app with isolated frames, trace HTML → DOM → JS-modifies-DOM → render, and say why page JS is sandboxed — and map every piece to the web attacks ahead.