5 ms·

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 unde

by 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.

by goto11 5y ago

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.