The browser security model and same-origin policy

Before the vulnerabilities make sense, you need the rules of the arena. The browser runs code from many sites at once and must stop them interfering with each other. The same-origin policy is that wall — and a huge share of web security is about where the wall has gates, and how attackers slip through them.

What is an origin

An origin is the combination of scheme, host, and port. Two URLs are same-origin only if all three match.

https://app.example.com:443/page      origin = https + app.example.com + 443

Same origin?
  https://app.example.com/other     YES  (same scheme, host, port)
  http://app.example.com            NO   (scheme differs: http vs https)
  https://api.example.com           NO   (host differs)
  https://app.example.com:8443      NO   (port differs)

All three parts must match. A different scheme, subdomain, or port is a different origin. This exact definition is what every cross-origin rule is built on.

What the same-origin policy blocks

The same-origin policy (SOP) stops a script from one origin reading data from another. So JavaScript on evil.com can’t read the responses of requests to bank.com, can’t touch bank.com’s cookies, and can’t read into a bank.com iframe.

What it does NOT block

The SOP blocks READING cross-origin responses, but the browser still:
  - SENDS cross-origin requests (with cookies!) -> the basis of CSRF
  - loads cross-origin images, scripts, styles  -> the basis of some attacks
  - lets pages navigate each other

Key takeaways

• An origin is scheme + host + port — all three must match.
• The same-origin policy blocks scripts reading cross-origin responses.
• It does NOT block requests being sent (cookies still attach) — that’s CSRF.
• CORS, CSRF, and XSS are all stories about this one wall.

Next module, the deep mechanics — prototypes, the prototype chain, and the pollution bug they enable.