3 ms·

I thought origin policies could be applied at the cookie level such that the browser would only send the relevant cookies to your bank if the request originated

by dcow 6y ago

I thought origin policies could be applied at the cookie level such that the browser would only send the relevant cookies to your bank if the request originated from active user navigation to bank.com or from content served by the response received thereafter: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...? That way instead of service X saying "only requests from these origins are allowed", bank.com is saying "these cookies are sensitive please restrict them to requests that happen when the user has actually navigated to our website". In the bank scenario you presented, does CORS provide any additional benefit beyond cookie-level access control policies? Is there another scenario I'm missing in general?

lostcolony 6y ago
SameSite was created by Google in 2016, and required both adoption across browsers and backend changes to be secure (that is, reliance on SameSite being set for security would mean backends that don't set it are not secure; it is opt in). Preventing cross origin requests as a necessary security measure happened as part of the initial implementation of XmlHttpRequest back in the 90s. CORS was a working draft as early as 2006, implemented across browsers by 2013ish, accepted as a W3C recommendation in 2014, and was 'secure by default'; the only backend changes necessary were when you wanted to allow cross origin requests (that is, it is opt out).
- deleted 6y ago
  [deleted]
colinclerk 6y ago
The SameSite cookie policy doesn't offer fine-grained control like CORS. So, if you want to allowlist cookies for certain third-party origins but not all, CORS would be a better option. In practice, most sites want to prevent all cross-origin requests and SameSite is easier. And in more recent practice, Safari and Firefox are blocking third-party cookies by default, so it's pretty rare to see a setup leveraging CORS for fine-grained cookie access.
- kenoyer130 6y ago
  We just ran into this CORS Same-Site cookie issue and it is going to become much more common. If the original author expanded to include the Same-Site rules as it applies to cookies it would be great!

by dcow 6y ago

lostcolony 6y ago

SameSite was created by Google in 2016, and required both adoption across browsers and backend changes to be secure (that is, reliance on SameSite being set for security would mean backends that don't set it are not secure; it is opt in). Preventing cross origin requests as a necessary security measure happened as part of the initial implementation of XmlHttpRequest back in the 90s. CORS was a working draft as early as 2006, implemented across browsers by 2013ish, accepted as a W3C recommendation in 2014, and was 'secure by default'; the only backend changes necessary were when you wanted to allow cross origin requests (that is, it is opt out).

deleted 6y ago
[deleted]

colinclerk 6y ago

The SameSite cookie policy doesn't offer fine-grained control like CORS. So, if you want to allowlist cookies for certain third-party origins but not all, CORS would be a better option. In practice, most sites want to prevent all cross-origin requests and SameSite is easier. And in more recent practice, Safari and Firefox are blocking third-party cookies by default, so it's pretty rare to see a setup leveraging CORS for fine-grained cookie access.

kenoyer130 6y ago
We just ran into this CORS Same-Site cookie issue and it is going to become much more common. If the original author expanded to include the Same-Site rules as it applies to cookies it would be great!