L37 · The Same-Origin Policy

1. The Same-Origin Policy

Title

CS 161 · Lesson 37 of 45

The browser's core isolation boundary — why it exists · what an origin is · read vs embed · the script/image/frame origin rules · postMessage

2. By the end of this lesson you can…

Objectives

1. Explain why the SOP exists: evil.com's JavaScript must not be able to read your Gmail or send mail as you.
2. Define an origin as the (protocol, domain, port) triple and decide whether two URLs are same-origin by exact string match of all three.
3. Separate what the SOP restricts (reading another origin's data) from what it allows (embedding cross-origin resources via src).
4. Apply the origin-assignment rules: a <script> runs with the INCLUDING page's origin; an <img>/<iframe> get the origin they come FROM.
5. Describe postMessage as the controlled, limited channel for cross-origin communication — and map the SOP to XSS (L40), CSRF (L39), and CORS.

3. What survived from L36 · Web Basics: URLs, HTTP, HTML, the DOM & JavaScript?

Warm-up

4. §19 Why we need the SOP at all

Concept

Concrete scenario: in one tab you have www.gmail.com open and logged in. In another tab you have www.evil.com, a malicious site. Both are running JavaScript in the same browser at the same time.

What you absolutely do NOT want: evil.com's JavaScript reaching over and reading your emails, or sending mail as you. The browser has to keep the two pages apart.

5. Break it if you can: §19 Why we need the SOP at all

Counterexample

6. §19 The browser's answer: isolate everything

Concept

Browsers enforce the same-origin policy (SOP): every webpage is isolated from every other page — EXCEPT when two pages share the same origin. Isolation is the default; sharing is the narrow exception.

Same-Origin Policy (SOP) — A browser rule that isolates each webpage from every other page, so one page's JavaScript cannot read another page's data — unless the two pages have the SAME ORIGIN. Same-origin pages may access each other freely; cross-origin pages are walled off.

7. §19 Same-origin pages trust each other fully

Concept

The flip side of isolation: two pages that DO share an origin get full mutual access. Same-origin JavaScript can read and modify the other page's DOM, see its responses, and use its cookies.

So the SOP is binary at the origin boundary: same origin ⇒ full trust; different origin ⇒ walled off. There is no 'partial' access between two origins by default.

8. By analogy: §19 Same-origin pages trust each other fully

Analogy

9. §19 Each origin is its own walled apartment

Intuition

Think of the browser as an apartment building. Each origin is a locked apartment. Two pages in the SAME apartment (same origin) can freely walk between rooms and read each other's things.

But your evil.com tab is in a DIFFERENT apartment from your Gmail tab. It cannot walk through the wall to read Gmail's mail. The wall between apartments is the same-origin policy.

Ask yourself: just because two pages are open at once, can one read the other? (No — being open side by side doesn't grant access; only sharing an origin does.)

10. Teach it back: §19 Each origin is its own walled apartment

Explain it

11. Predict the next row: §19 Trace the threat the SOP defeats

Pattern

12. §19 Trace the threat the SOP defeats

Worked example

13. Fill in: with the SOP for §19 Trace the threat the SOP defeats

Comparison

14. Something is wrong here: 'an open tab can read another open tab's data by…

Anomaly

15. Trap: 'an open tab can read another open tab's data by default'

Trap

16. §19 Isolation is the default, sharing is the exception

Intuition

Notice the design choice: the browser doesn't start with 'everything can talk' and bolt on restrictions. It starts FULLY isolated and carves out one narrow exception — same origin.

That's secure-by-default thinking (L2/L3): deny first, permit deliberately. Every cross-origin interaction has to be explicitly allowed (embedding, postMessage, CORS) rather than assumed.

Ask yourself: if a new browser feature exposes data, what's the safe default? (Cross-origin DENIED — same as the SOP — and let sites opt in if they truly need sharing.)

17. What rests on this: §19 Isolation is the default, sharing is the exception

Socratic

18. What Is an Origin?

Section

Part 1 · §19.1 protocol + domain + port

19. §19.1 An origin is a triple

Concept

The SOP is defined over origins, so we need an exact definition. An origin is built from three pieces of a URL — and only these three.

Origin — The triple (PROTOCOL, DOMAIN, PORT). Two pages have the same origin only if ALL THREE match exactly (as strings). The path, query, and fragment are NOT part of the origin.

20. Take the definitions apart: Same-Origin Policy (SOP) vs Origin

Definition probe

21. §19.1 Read the origin off the URL

Concept

Take the URL http://wikipedia.org:80/wiki/Cat. Its origin is everything that names WHERE the resource lives — protocol, domain, and port — and nothing about WHICH resource.

http :// wikipedia.org : 80 / wiki/Cat
\__/      \___________/  \_/  \_______/
PROTOCOL     DOMAIN     PORT    path
\_________ origin ________/  (NOT origin)

Same-origin test: line up two URLs and compare protocol, domain, and port. If all three are character-for-character identical, same origin. If any differs, different origin.

22. §19.1 Default ports

Concept

If a URL omits the port, the browser fills in the protocol's default port: 80 for HTTP, 443 for HTTPS. So http://wikipedia.org is treated as http://wikipedia.org:80.

So http://wikipedia.org ≡ http://wikipedia.org:80 (same origin), but http://wikipedia.org ≠ http://wikipedia.org:81 — the port differs.

23. What each one costs: §19.1 Default ports

Trade off

24. §19.1 A subdomain is a different domain

Concept

wikipedia.org and www.wikipedia.org look like 'the same site,' but as origin DOMAIN strings they are not equal — www. makes a different string, hence a different origin.

The same-origin comparison is a literal string match on the host — there is no 'these belong to the same company so they're the same origin' rule.

25. Which is which, by compared to wikipedia.org

Discrimination

26. §19.1 All three must match — like a full address

Intuition

An origin is like a full street address: house number AND street AND city. Match the street but not the city and it's a different place. Match domain but not protocol or port, and it's a different origin.

The path is which ROOM you visit once you're at the address — it doesn't change the address. That's why /a/ and /b/ on the same site are the same origin.

Ask yourself: is www.wikipedia.org the same place as wikipedia.org? (No — a different subdomain is a different domain string, so a different origin.)

27. §19.1 Same origin? Decide each pair

Worked example

28. Draw the shape of it: §19.1 Same origin? Decide each pair

Blank canvas

29. Trap: 'same domain = same origin'

Trap

http://wikipedia.org        vs  https://wikipedia.org   <- protocol differs
http://wikipedia.org        vs  http://www.wikipedia.org <- domain differs
http://wikipedia.org:81     vs  http://wikipedia.org:82  <- port differs

30. Inspect it line by line: Trap: 'same domain = same origin'

Error analysis

31. §19.1 Build the origin, then compare

Worked example

32. Fill in: domain for §19.1 Build the origin, then compare

Comparison

33. Something is wrong here: 'the path is part of the origin'

Anomaly

34. Trap: 'the path is part of the origin'

Trap

35. What the SOP Restricts vs Allows

Section

Part 2 · §19.2 read is blocked, embed is allowed

36. §19.2 The SOP blocks cross-origin READS

Concept

Concrete rule: the SOP stops one origin's JavaScript from reading another origin's data — its DOM, the responses to its fetch/XHR requests, and its cookies. evil.com's JS simply cannot read gmail.com's anything.

• Another origin's DOM — can't read its page contents.
• Another origin's fetch/XHR responses — can't read what its requests return.
• Another origin's cookies — can't read its stored credentials.

37. §19.2 …but cross-origin EMBEDDING is allowed

Concept

Crucially, the SOP does NOT stop you from LOADING cross-origin resources. A page may embed images, scripts, and frames from other origins via src. The whole web depends on this — CDNs, ad scripts, embedded videos.

<!-- all allowed on any origin -->
<img    src="https://other.com/logo.jpg">
<script src="https://cdn.com/lib.js"></script>
<iframe src="https://other.com/widget"></iframe>

The line is embed vs read: you may EMBED a cross-origin resource, you just can't READ its contents across the origin boundary.

38. §19.2 Hang the painting, but don't open the safe

Intuition

Embedding a cross-origin image is like hanging a borrowed painting on your wall: you can display it, frame it, size it. That's fine — display is allowed.

Reading across origins is like opening the lender's safe in their house. The SOP locks that. You can show their stuff; you can't reach in and read their private contents.

Ask yourself: does embedding a cross-origin image let your JS read that image's pixels? (No — you can display it, but reading its contents is across the origin boundary, so it's blocked.)

39. §19.2 'Read' covers DOM, responses, and cookies

Concept

When we say the SOP blocks 'reading another origin's data,' that bundles three concrete capabilities an attacker would love — and the SOP denies all three across origins.

40. What rests on this: §19.2 'Read' covers DOM, responses, and cookies

Socratic

41. Predict the next row: §19.2 Embed (allowed) vs read response (blocked)

Pattern

42. §19.2 Embed (allowed) vs read response (blocked)

Worked example

<!-- on http://cs161.org -->
<img src="http://google.com/logo.jpg">      <!-- embed: OK -->
<script>
  fetch('http://google.com/').then(r => r.text())
</script>                                    <!-- read: BLOCKED -->

43. Which is which, by allowed?

Discrimination

44. Something is wrong here: 'the SOP blocks loading anything from another origin'

Anomaly

45. Trap: 'the SOP blocks loading anything from another origin'

Trap

46. §19.2 Why 'embed but not read' is the whole web

Concept

If the SOP blocked all cross-origin loads, there would be no CDNs, no embedded maps, no ad networks, no shared font/script libraries. The web only works because EMBEDDING cross-origin is allowed.

The SOP's design splits the difference: maximize useful sharing (anyone can embed anyone) while denying the one dangerous capability (reading another origin's private contents). Embed freely; read never.

47. The Origin-Assignment Rules

Section

Part 3 · §19.2 scripts, images & frames

48. §19.2 A resource's origin ≠ the URL it came from

Concept

Here's the subtle, exam-critical part. A resource does NOT always get the origin of the URL it was fetched from. Which origin a resource gets depends on the KIND of resource — and the rules differ for scripts, images, and frames.

Getting this wrong is the single most common SOP mistake — and the script rule is exactly what makes XSS (L40) devastating. We'll take the three resource types one at a time.

49. §19.2 JavaScript runs with the INCLUDING page's origin

Concept

Rule 1: JavaScript runs with the origin of the page that LOADS it — not the origin it was downloaded from. A <script src=…> from anywhere runs as if it were part of YOUR page.

<!-- page is on http://cs161.org -->
<script src="http://google.com/tracking.js"></script>
<!-- tracking.js runs with origin cs161.org,
     NOT google.com -->

So that included script has the SAME origin as your page — full access to your DOM, your data, everything. This is why pulling in third-party scripts is dangerous: you're giving their code your origin.

50. §19.2 Images keep the origin they COME FROM

Concept

Rule 2: an image has the origin of where it comes from. An <img src="http://google.com/logo.jpg"> on cs161.org has origin google.com — not cs161.org.

<!-- page is on http://cs161.org -->
<img src="http://google.com/logo.jpg">
<!-- image origin = google.com; cs161.org
     learns only its DIMENSIONS, not pixels -->

Because the image is a different origin, the loading page learns only the image's dimensions (so it can lay out the page) — it cannot read the image's actual pixels.

51. Where does each piece belong: L37 · The Same-Origin Policy

Sorting

52. §19.2 Frames get the origin they're RETRIEVED from

Concept

Rule 3: a frame has the origin of the URL the frame is retrieved from. An <iframe src="http://google.com"> on cs161.org has origin google.com — the frame's own URL, not the embedding page's.

<!-- page is on http://cs161.org -->
<iframe src="http://google.com"></iframe>
<!-- frame origin = google.com,
     NOT the embedding page cs161.org -->

So the embedding page (cs161.org) and the framed page (google.com) are DIFFERENT origins, and the SOP walls them off from reading each other — exactly the frame isolation from L36.

53. §19.2 You hire the script; you only display the image

Intuition

Including a <script> is like HIRING a contractor into your house: they walk around with your keys (your origin) and can touch everything. That's why a third-party script is a big trust decision.

Embedding an <img> or <iframe> is like DISPLAYING a borrowed object behind glass: it keeps its own owner (its source origin), and you only see it — you can't reach inside it.

Ask yourself: which of the three resource types gives YOUR page's powers to someone else's code? (The script — it runs with your origin. Images and frames keep theirs.)

54. What rests on this: §19.2 You hire the script; you only display the image

Socratic

55. §19.2 Three resources, three origins

Worked example

<!-- all on http://cs161.org -->
<script src="http://google.com/track.js"></script>
<img    src="http://google.com/logo.jpg">
<iframe src="http://google.com"></iframe>

56. What each one costs: §19.2 Three resources, three origins

Trade off

57. Trap: 'an included third-party <script> runs with the third party's origin'

Trap

58. §19.2 The image leaks shape, not content

Intuition

When cs161.org embeds a google.com image, the browser has to lay out the page, so it must tell cs161.org how big the image is. But size is all it tells — the image's actual pixels belong to google.com's origin.

Think of a wrapped package: you can see its dimensions to fit it on a shelf, but you can't see what's inside. Dimensions leak; contents don't.

Ask yourself: could cs161.org's JS read the colors of an embedded cross-origin photo? (No — that's reading the image's contents across origins, which the SOP blocks; only its dimensions are exposed.)

59. Teach it back: §19.2 The image leaks shape, not content

Explain it

60. Something is wrong here: 'http and https share an origin'

Anomaly

61. Trap: 'http and https share an origin'

Trap

62. Controlled Cross-Origin Communication

Section

Part 4 · §19.2 postMessage (and ⊕ the rest)

63. §19.2 postMessage: a narrow, opt-in channel

Concept

Sometimes two different-origin pages genuinely need to talk — say an embedded widget and its host. JavaScript's postMessage lets pages of different origins communicate, but with very limited functionality.

postMessage — A JavaScript API that lets two pages of DIFFERENT origins exchange messages in a controlled, limited way. It is not a hole in the SOP: the channel is narrow, and the RECEIVER must validate the sender's origin before trusting a message.

64. §19.2 The receiver must check the origin

Concept

postMessage does not let any origin freely read another's page. It only passes discrete MESSAGES, and the side receiving a message is responsible for verifying who sent it before acting on it.

window.addEventListener('message', (e) => {
  if (e.origin !== 'https://trusted.com') return; // validate!
  handle(e.data);
});

If the receiver skips the e.origin check, any page can send it messages — a real bug. The SOP gives you the sender's origin precisely so you can check it.

65. By analogy: §19.2 The receiver must check the origin

Analogy

66. §19.2 A safe vs unsafe postMessage receiver

Worked example

window.addEventListener('message', (e) => {
  // UNSAFE: no origin check — any page can send this
  handle(e.data);
});

67. Fill in: who can drive handle() for §19.2 A safe vs unsafe postMessage receiver

Comparison

68. ⊕ Beyond §19: CORS, document.domain, JSONP, DNS rebinding

Concept

⊕ Supplemental — beyond §19.1–19.2. Several other mechanisms relax or attack the SOP; you'll meet them later or in practice, but they're outside this textbook section.

• ⊕ CORS — servers OPT IN to cross-origin reads via the Access-Control-Allow-Origin response header; complex requests trigger a preflight, simple ones don't.
• ⊕ document.domain — a legacy mechanism that let two pages relax to a shared parent domain (now deprecated).
• ⊕ JSONP — an old trick that abuses the <script> cross-origin-embed rule to fetch data as executable JS, sidestepping the read restriction.
• ⊕ DNS rebinding — an attack that swaps the IP behind a domain after load, so 'same origin' by name maps to a different machine.

69. §19.2 postMessage is a mail slot, not an open door

Intuition

postMessage is like a mail slot between two locked apartments: you can slide a NOTE through, but you can't walk in and rummage through the other apartment. The wall (the SOP) still stands.

And the note is stamped with the sender's address (e.origin). A careful receiver reads the stamp and ignores notes from addresses it doesn't trust.

Ask yourself: does receiving a postMessage let you read the sender's DOM? (No — you only get the message data, plus the sender's origin to validate. The pages stay isolated.)

70. Break it if you can: §19.2 postMessage is a mail slot, not an open door

Counterexample

71. Something is wrong here: 'postMessage lets any origin freely read any other…

Anomaly

72. Trap: 'postMessage lets any origin freely read any other origin's page'

Trap

73. Which of these survive contact with L37 · The Same-Origin Policy?

Two truths and a lie

74. The same-origin playbook

Pattern

1. Compute the origin: read off (PROTOCOL, DOMAIN, PORT). Fill defaults — 80 for http, 443 for https. Ignore the path/query/fragment.
2. Same-origin test: two pages are same-origin only if all THREE parts match exactly as strings. Any difference in protocol, subdomain/domain, or port ⇒ different origin.
3. Restrict vs allow: the SOP BLOCKS reading cross-origin data (DOM, fetch/XHR responses, cookies) but ALLOWS embedding cross-origin resources (img/script/iframe via src).
4. Assign the resource's origin: a <script> runs with the INCLUDING page's origin (yours!); an <img> keeps the origin it came from (you get dimensions, not pixels); an <iframe> keeps the origin of the URL it was retrieved from.
5. Cross-origin talk: use postMessage for limited, opt-in messaging — and ALWAYS validate e.origin on the receiving side.
6. Map to attacks: 'script runs with the including origin' ⇒ XSS (L40); 'request sent cross-origin but response can't be read' ⇒ CSRF (L39); ⊕ CORS/postMessage are the controlled exceptions.

75. Where does it stop working: The same-origin playbook

Edge cases

76. Checkpoint — read the origin

Check

A page served from http://cs161.org includes <script src="http://google.com/tracking.js">. Separately, consider whether http://wikipedia.org and https://wikipedia.org are the same origin. Think before choosing.

77. Misconceptions to retire

Concept

• Open tabs can read each other — no: the SOP isolates them; only same-origin pages share access.
• Same domain = same origin — no: protocol AND port matter too, and a different subdomain is a different domain.
• http and https share an origin — no: different protocol (and default port) ⇒ different origin.
• The SOP blocks embedding cross-origin resources — no: it blocks READING, not embedding; img/script/iframe via src are allowed.
• An included third-party script runs with the third party's origin — no: it runs with YOUR (the including page's) origin.
• The path is part of the origin — no: only protocol, domain, and port count; the path is ignored.

78. Synthesis — the SOP is the web's process isolation

Concept

• The SOP is the browser's core isolation boundary — the web's version of process isolation / a trust boundary from L2/L3, enforced over origins instead of processes.
• origin = scheme + host + port comes straight from the L36 URL model — the SOP just decides access over that triple.
• 'A script runs with the including page's origin' is exactly what makes XSS (L40) devastating: injected <script> runs in the victim page's origin with full DOM power.
• 'A request can be SENT cross-origin but the response can't be READ' is why CSRF (L39) works despite the SOP: the malicious request fires (with cookies), even though the attacker can't read the reply.
• CORS and postMessage are the controlled exceptions — servers/pages opt in to specific cross-origin sharing, rather than the SOP being globally relaxed.

79. Primary sources & where to read more

Concept

• Textbook §19 — why the SOP exists (the evil.com vs Gmail scenario) and the isolate-everything-except-same-origin rule.
• Textbook §19.1 — the definition of an origin as (protocol, domain, port), default ports, and the same-origin examples.
• Textbook §19.2 — what the SOP restricts (reading DOM/responses/cookies) vs allows (embedding), the script/image/frame origin-assignment rules, and postMessage.
• RFC 6454 (The Web Origin Concept, Barth 2011) and the WHATWG HTML Standard (Origin) — the authoritative definitions; MDN — Same-origin policy for a readable overview.
• W3C/WHATWG CORS ⊕ — how servers opt in to cross-origin reads via Access-Control-Allow-Origin (beyond §19).
• Next lessons: cookies & sessions (L38), CSRF (L39), and XSS (L40) all build directly on the SOP defined here.

80. Connect it up: L37 · The Same-Origin Policy

Connect it up

81. Recap — Lesson 37

Recap

You can now say why the SOP exists (keep evil.com out of your Gmail), compute an origin as (protocol, domain, port) and decide same-origin by exact match of all three, separate what the SOP restricts (reading cross-origin data) from what it allows (embedding), apply the script/image/frame origin rules — especially that an included script runs with YOUR origin — and describe postMessage as the controlled cross-origin channel.