What Is Same-Origin Policy? (Web Security 101)

Short answer

The same-origin policy (SOP) is the foundational browser security rule: JavaScript running on one origin (combination of scheme + host + port) cannot read responses, cookies, or storage from another origin. Without it, any malicious site you visit could silently make authenticated requests to your bank, email, or any other site you're logged into and read the responses. SOP is what keeps the web's authentication model viable.

What "origin" means

An origin is the triple scheme + host + port. Two URLs share an origin only when all three match exactly:

URL A	URL B	Same origin?
https://example.com/a	https://example.com/b	✓ Yes
https://example.com	http://example.com	✗ Different scheme
https://example.com	https://api.example.com	✗ Different host (subdomain)
https://example.com:443	https://example.com:8443	✗ Different port
https://example.com	https://example.com:443	✓ Same (443 is HTTPS default)

What SOP blocks

• Reading cross-origin response bodies from fetch() or XMLHttpRequest
• Reading cross-origin DOM from an <iframe>
• Reading cookies set by another origin
• Accessing localStorage / sessionStorage from another origin
• Reading pixel data from cross-origin images drawn to canvas (taints the canvas)

What SOP doesn't block

• Loading cross-origin resources — <img src>, <script src>, <link rel=stylesheet>, <iframe src> all work
• Sending cross-origin requests — your POST still arrives at the server. SOP only blocks reading the response.
• Form submissions — a form on origin A can POST to origin B (and the user's cookies for B will be sent unless SameSite blocks them)

This last point is critical: SOP doesn't prevent CSRF. Cross-site request forgery succeeds because the request is allowed; only the response can't be read. Mitigate CSRF separately with SameSite=Strict cookies + CSRF tokens.

How sites legitimately work across origins

Mechanism	Use case
CORS	Server explicitly opts in to allowing cross-origin reads (see CORS glossary)
postMessage()	Iframes/popups talk to parent across origins via message events
document.domain	Legacy: subdomain pages relax origin (deprecated)
Server-side proxy	Your backend fetches the cross-origin resource and re-serves from your origin (no SOP issue)
JSONP	Legacy hack predating CORS — don't use it for new code

Why SOP exists at all

Without SOP, here's the attack: you visit malicious-site.com. Its JavaScript silently issues fetch('https://yourbank.com/transfer?to=attacker&amount=10000'). Your browser sends your bank cookies along (you're logged in). The bank processes the transfer because credentials look valid. Without SOP, attacker.com's JavaScript could also read the response — confirming success and inspecting your account balance.

SOP cuts that attack in half: the request fires, but malicious-site.com can't read the response. CSRF tokens + SameSite cookies block the request itself.

Public vs private network distinction

Modern browsers extend SOP with the Private Network Access spec. Public sites can no longer make requests to local network resources (10.x, 192.168.x, localhost) without explicit consent — preventing public sites from probing your home router or printer.

Related tools

For URL parameters that need encoding: URL encoder/decoder. For inspecting auth tokens used in cross-origin requests: JWT decoder. For HTTP status code reference (CORS-related codes appear here): HTTP status codes.