Same Origin Policy (SOP)

tags : CORS, XSS, Web Authentication, CSRF, Cookies, Security, Javascript

Origin §

• Origin: Scheme + Hostname + Port
• Can also be an IP address

Site §

• Site: Scheme + eTLD+1
• There’s also schemeless site, in which change of change of scheme means same site. (This is the current standard)

X-origin and X-site jargon §

same-origin §

cross-origin §

• When it’s not same-origin, it’s cross origin
• subdomains will be cross-origin
• different port will be cross-origin

same-site §

• subdomains will be same-site
• different port will be same-site

cross-site §

• When it’s not same-site, it’s cross-site
• different scheme will be cross-site

Same Origin Policy §

• SOP is good, CORS allows us to bypass SOP when needed
• Browsers by default follow SOP
• No request to other origins

Scope of “Same origin” §

• This is not limited to API calls
• Not limited to Cookies not having access to cookies of other origin
• Not limited to access of parent-child in iframe
• It’s a meta thing

Why SOP needed in the first place? §

Confusion is like:

If we have to do CORS anyway, why do browsers enforce SOP? Non-browser clients can anyway make the request to the API endpoint, why not allow the browser to do so?

Spoiler: We don’t always need CORS and it’s better to avoid CORS when you can by design.

• Now, neither SOP nor CORS are for protecting the API endpoint.
• It exists so as to reduce possibility of attacks that can be done when you open a webpage in the browser.
• Its a policy, there’s no specific implementation so the idea of SOP is implemented by the browser at different levels
• Eg. Cookies will be disallowed from accessing cookies of other origins. Script running on evil.com can’t access X.com cookies.
• Eg. You’re not allowed to just randomly fetch data from any random website. A script in evil.com should not be able to hit localhost:8000 and relay the data to the attacker.
• Eg. file:// is also another origin, you don’t want random websites to have access to file:// origin for sure.

SOP does allow cross-origin! §

• SOP is nuanced, even without CORS it does allow limited cross-origin requests.
• Whenever things are denied by SOP, browser will attempt to do CORS by using a preflight request. If the preflight fails, you really won’t be able to access the resource.

Write: Allowed §

• You’re allowed to send request, server will receive it and respond as expected, but browser will not let you read the response
• You can send GET, POST (certain content-type), HEAD, others will need preflight w OPTIONS.

Embed: Allowed §

• <script>, <link>, <video>, <audio>, <iframe>, <img> tags etc.

Read: Denied §

• Any response coming from cross-origin will be blocked by the browser by default. You’ll need to configure CORS to bypass this.

Harden CORS on SOP §

• Since SOP does allow some CORS, by default we can tighten it even further. See MDN docs on SOP for this.
• Eg. For iframe with X-Frame-Options: DENY you can make sure your page cannot be embedded even if by default SOP it allows.