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.