3 ms·

It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able

It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it. Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*. This is also not the sole use-case, it also stops your backend api being up under a different frontend which would allow data theft since you could log into real services on google.com, but you're actually on g00gle.com enabling data exfiltration because now every request can be MitM'd.

crackalamoo 4mo ago
I love this, easy intuitive explanation
StrauXX 4mo ago
No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.
- himata4113 4mo ago
  ah right, my own brain got jumbled from reading all the comments forgetting that cors: '*' is not the default.
- flux3125 4mo ago
  And now he's part of the confusing comment section lol
  - himata4113 4mo ago
    I fixed it, it stays relatively the same vs original explanation, just had inverted defaults I have no idea why I thought '*' was the default. Definitely impacted by the confusing comment section haha.
krackers 4mo ago
To understand the threat model you need to understand historical decisions browsers made, such as when cookies are sent, and the distinction between actually sending the request versus allowing client-side JS to read back request content. The decisions are just really counterintuitive and often build on legacy precedent. I think the nature of threat model has also changed over time. Now that samesite cookies are the default, API requests made with the user's credentials shouldn't be an issue, but there is still value in preventing cross-origin reads to do things like preventing random webpages from scanning intranet (there are probably still timing side-channels though). I guess the limitation against non-simple post/get is also marginally beneficial for preventing ddos.

crackalamoo 4mo ago

I love this, easy intuitive explanation

StrauXX 4mo ago

No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.

himata4113 4mo ago
ah right, my own brain got jumbled from reading all the comments forgetting that cors: '*' is not the default.
flux3125 4mo ago
And now he's part of the confusing comment section lol
- himata4113 4mo ago
  I fixed it, it stays relatively the same vs original explanation, just had inverted defaults I have no idea why I thought '*' was the default. Definitely impacted by the confusing comment section haha.

krackers 4mo ago

To understand the threat model you need to understand historical decisions browsers made, such as when cookies are sent, and the distinction between actually sending the request versus allowing client-side JS to read back request content. The decisions are just really counterintuitive and often build on legacy precedent. I think the nature of threat model has also changed over time. Now that samesite cookies are the default, API requests made with the user's credentials shouldn't be an issue, but there is still value in preventing cross-origin reads to do things like preventing random webpages from scanning intranet (there are probably still timing side-channels though). I guess the limitation against non-simple post/get is also marginally beneficial for preventing ddos.