Web Security: Same Origin Policy

Main ideas / lessons

• Same-Origin Policy (SOP) is a core browser security rule that controls:
  • Whether a browser is allowed to send HTTP requests to another origin.
  • Whether JavaScript is allowed to read the response from those cross-origin requests.
• The web is a “web of data” where a page on one site often needs resources from others (images, scripts, CSS, embedded content), but browsers must prevent sites from stealing or abusing sensitive data (e.g., authenticated responses/cookies).
• Cross-origin access is not fully blocked—browsers allow some cross-origin interactions (and allow some response visibility) in controlled ways.

---

What “origin” means (and why it matters)

• An Origin is defined as a tuple of:
  • scheme
  • host
  • port
• Path, query, and fragment do not affect origin matching.
• Examples:
  • http://example.com and http://example.com:80 → same origin
  • http://example.com vs https://example.com → different origin (scheme differs)
  • http://example.com vs http://cats.example.com → different origin (host differs)
  • http://example.com:80 vs http://example.com:8080 → different origin (port differs)

---

How SOP affects sending requests and reading responses

1) Sending cross-origin requests: “Simple requests” (allowed)

For different origins, SOP allows some cross-origin HTTP requests called simple requests.

• Simple request methods allowed:
  • GET
  • HEAD
  • POST
• Allowed customizable headers (with restrictions):
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (but not arbitrary)
  • Range (only “simple” values)

Content-Type restrictions for POST

• Allowed examples:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain
• Not allowed in this “simple request” model:
  • e.g., application/json is not allowed as a simple cross-origin POST.

Lesson: cross-origin “simple” actions are commonly permitted (e.g., loading images, basic form submission), but more complex request types are blocked by default.

---

2) Reading cross-origin responses: heavily restricted

Even if a browser allows you to send a request, it often blocks JavaScript from reading the raw response bytes.

• JavaScript cannot generally read the response body of cross-origin requests.
• You can “effectively read” data when the browser itself renders/parses it using specific HTML embedding mechanisms, such as:
  • <img>
  • <video>
  • <audio>
  • <object>
  • <embed>
  • <iframe>
  • <link> (CSS)
  • <script> (JavaScript loading; key point: the browser controls how the response is used/rendered)

But JavaScript cannot normally:

• fetch an arbitrary cross-origin resource
• then inspect the raw response bytes directly

Lesson: SOP permits using embedded resources for display/functionality, but prevents cross-origin response content from being programmatically extracted by untrusted scripts.

---

Cookies, authentication, and why SOP matters

• If a cross-origin request occurs, the server might require authentication (often via cookies/session state).
• If the browser were to send cookies automatically for any cross-origin request, it could enable attacks where a malicious site tricks a user’s browser into sending sensitive credentials.
• Therefore, browsers apply strict rules about when cookies are included and when responses can be read.

---

“Site” vs “Origin” (for cookie handling)

Definitions

• Domain name: labels separated by dots (e.g., www.example.com).
• Public suffix list (Mozilla-published): used to derive Effective Top-Level Domains (eTLDs).
• Effective Top-Level Domain (eTLD): determined by the public suffix list.
• Site: (effective top-level domain + one label to the left).
  • Examples:
    • example.com is a site
    • google.com and google.co.uk are different sites
    • poland.college and dojo.poland.college are described as the same site (same eTLD + one-left-label logic)

Cookie attribute: SameSite

Browsers use a cookie attribute SameSite to decide when cookies are sent in cross-site requests (more relaxed than strict cross-origin matching).

• SameSite=None
  • Cookie is sent in cross-site requests.
  • Example consequence: a preference cookie could make images appear in black-and-white across other sites.
• SameSite=Lax (described as newer default around ~2020, with some browser differences)
  • Cookie is only sent on certain “safe” cross-site navigations (described primarily as cross-site top-level navigation GET).
• SameSite=Strict
  • Cookie is not sent in cross-site requests.
  • Result: if you open a new top-level navigation to a strict-site, you may need to re-authenticate (e.g., “logged out” behavior).

Other cookie attributes

• Domain
  • Controls which domain(s) the cookie is sent to (including subdomains when set).
  • By default, cookies are sent only to the setting host (excluding subdomains).
• Path
  • Limits cookie sending to a specific path and subpaths.

---

CORS: relaxing SOP to allow controlled cross-origin reads

When a developer wants to allow cross-origin JavaScript to read responses, they use Cross-Origin Resource Sharing (CORS).

Core mechanism: pre-flight for non-simple requests

If the request is not “simple”, the browser performs a pre-flight request:

• Uses the HTTP OPTIONS method
• Includes headers describing:
  • the intended method (GET/POST/PUT/etc.)
  • which custom headers will be used (custom headers make requests “non-simple”)
  • the Origin

This pre-flight asks the server: “Is it safe for JavaScript on Origin A to make this request to Origin B and read the response?”

Pre-flight response (server approval)

The server responds with CORS headers such as:

• Access-Control-Allow-Origin
  • May specify a particular allowed origin (e.g., a)
  • May use * to allow any origin (“everyone”)
• Access-Control-Allow-Methods
  • Which methods are allowed (GET/POST/PUT/etc.)
• Access-Control-Allow-Headers
  • Which request headers are allowed
• Access-Control-Allow-Credentials
  • Whether credentials (cookies/authorization data) are allowed to be sent and used
• Access-Control-Expose-Headers
  • Which response headers JavaScript is allowed to read (not all headers are readable by default)

No pre-flight needed for “simple” requests (but reading may still require headers)

• For simple requests, browsers generally do not pre-flight.
• Instead, CORS headers in the actual response determine whether JavaScript is allowed to read it, using headers like:
  • Access-Control-Allow-Origin
  • Access-Control-Allow-Credentials (if credentials are involved)
  • Access-Control-Expose-Headers

---

Putting it all together (conceptual flow)

• The browser decides:
  1. Can the request be sent cross-origin?
     • Often allowed if it’s a simple request.
     • Otherwise, CORS pre-flight is required for non-simple requests.
  2. Can the response be read by JavaScript?
     • Default SOP blocks reading; CORS can permit it explicitly.
  3. Are cookies sent?
     • Controlled by SameSite cookie attribute and CORS credential settings.
  4. Which cookies/headers are accessible?
     • Cookie scope via Domain/Path, and header access via Expose-Headers.

---

Speakers / sources featured

• Speaker: “hello everybody and welcome back…” (no specific named person provided in subtitles)
• Source referenced: Mozilla (for the Public Suffix List concept)