4 ms·

Again, CORS does not protect, the SOP does :-)

• goto11 5y ago
  You can consider CORS a relaxation on top of SOP (same-origin policy), since CORS allows you to opt-in to certain cross-site requests which are not allowed under SOP. Then again, SOP allows certain requests like 'PUT' and 'DELETE' requests back to the origin server which was not allowed before SOP, so in that sense SOP is also a relaxation. Bit it is a good point that CORS enables more forms of cross-site requests than what is allowed under the same-origin policy. But the requests are enabled under certain confusing restrictions which is better understood if you understand the scenarios they are designed to protect against.
  • JanSt 5y ago
    SOP is certainly not a relaxation. SOP restricts all those cross-origin request. I don't quite understand what you mean with PUT and DELETE not being allowed before SOP? What exact operations where not possible before SOP and are now (and pose a security risk?)
    • goto11 5y ago
      It was not possible to initiate a PUT or DELETE request from browsers until XMLHttpRequest with same-origin-policy was introduced.
      • JanSt 5y ago
        That doesn't matter at all in a security context. POST can (and is used) for everything DELETE and PUT are used. Adding DELETE and PUT did not relax anything. The only question is whether requests are restricted (i.e. in terms of sending resources like cookies).
        • goto11 5y ago
          If that is the case, then SOP does not restrict anything either, since you can still send cross-origin POST requests under single-origin-policy. I don't think this is a useful way to look at things.
          • feanaro 5y ago
            SOP should primarily be understood as a restriction on reading responses, not making requests.
            • SahAssar 5y ago
              SOP certainly does make restrictions on making requests, like setting any non-default headers (including content-type). It is one of the reasons that validating content-type to not be one of the normal form values used to be a valid way to handle CSRF for APIs.
        • FpUser 5y ago
          One can use GET as well. It is up to whatever sits behind the browser to interpret request and it can do as pleases. I personally use JSON based RPC in my apps.
• fivea 5y ago
  > Again, CORS does not protect, the SOP does :-) This is simply false. You are somehow wrongly assuming that only same-origin requests exist or are needed. This scenario never existed in the real world beyond the scope of small personal projects.
  • feanaro 5y ago
    To explain your error a bit less facetiously, the point my sibling is making is that SOP is the default policy, which is maximally restrictive. CORS is a technology used to relax SOP, to make it less restrictive. So it is not CORS that protects, since it restricts nothing, but SOP (potentially relaxed by CORS).
  • shukantpal 5y ago
    > You are somehow wrongly assuming that only same-origin requests exist or are needed. No they are not making that assumption.
  • JanSt 5y ago
    How am I assuming that? How exactly does CORS add security?
• lolinder 5y ago
  Strictly speaking you are correct, but is there any actual harm in people using the word CORS as a shorthand for the whole system of Same Origin Policy + Cross Origin Resource Sharing? If there's some kind of dangerous misunderstanding that stems from this, I can understand emphasizing it, but otherwise it just feels pedantic.
  • JimDabell 5y ago
    > is there any actual harm in people using the word CORS as a shorthand for the whole system of Same Origin Policy + Cross Origin Resource Sharing? Yes. Consider: > Hey, the results from the security audit are in and it’s mostly fine, except the pen testers said that we don’t need CORS for our /foo endpoint. Can you disable it entirely please? If you understand what CORS is, you will interpret that as “Our security is too lax, let’s tighten it up by removing the exceptions to the SOP that CORS grants” and correctly increase security. If you think CORS is how you described, you will misinterpret that as “We don’t need security for this endpoint, open it up to the world with Access-Control-Allow-Origin: *” and create a massive security vulnerability. If you think of CORS as something that restricts things in the name of security, your understanding is 100% backwards from what it actually is, and this can be disastrous for security.
  • JanSt 5y ago
    There are misunderstandings arising - reading this thread or the articles makes it clear for me…