Skip to content
Access and Blast Radius

07.01 · Lecture

Permissions as Sets

Explain the same-origin policy as the boundary a browser enforces, and how cross-site request forgery abuses a request the browser was willing to authorise.

Same-origin policy is the browser’s read boundary: it stops one origin’s JavaScript from reading another origin’s responses, but it does not stop every cross-origin request. CSRF exploits that gap by making the victim’s browser send an authenticated state-changing request using cookies the browser is allowed to attach.

What this lesson answers

  • what does same origin policy actually block
  • how does csrf work with browser cookies
  • why cors is not csrf protection

Notes

Permissions as Sets — Permissions exist to make authorization a bounded set operation; without a clear boundary like the browser’s same-origin policy, a page from one site could read or trigger privileged actions using another site’s cookies and expand blast radius across accounts.

Key Concepts: - An origin is the tuple , so `https://bank.example:443` and `http://bank.example:80` are different origins. - The same-origin policy lets `https://app.example` read responses from `https://app.example/api`, but blocks JavaScript from reading `https://bank.example/account`…

Common questions

What is an origin in browser security?
An origin is defined by scheme, host, and port together. If any part changes, the browser treats it as a different origin. Same-origin policy uses that boundary to decide whether JavaScript from one page may read data returned from another location.
Why can CSRF work if same-origin policy exists?
Same-origin policy mainly restricts reading cross-origin responses. Browsers can still send some cross-origin requests, including form submissions, and they may attach matching cookies automatically. CSRF abuses that by causing the victim’s browser to perform an action the target site believes is authorised.
Do CSRF tokens still matter with SameSite cookies?
Yes. SameSite cookies reduce many ambient cross-site cookie sends, especially for unsafe requests, but they are not a complete authorisation design. A CSRF token ties the request to server-side state for the user’s session and gives the application an explicit value to validate before changing data.