There is a same origin policy in the browser to ensure that e.g. bad site won't read your data from Facebook. But it seems that the only problem that it tries to solve is that cookies are automatically sent with the request which authenticates the user (+ maybe some other authentication schemes like basic or maybe certificate).

So my question is: would we really need this policy if the browser would not send all the http auth details and cookies with this request automatically?

Maybe the best way is to allow cross-origin by default, but make sure that this information (cookie, http auth) is not transferred. In any case we can produce token based API now e.g. and so on if a cross-site request is required. And a 3d party caller would need to obtain a token the same way so that no CORS would be required.

  • 1
    It also means that a JavaScript script included in a frame from a third-party website does not get to see the content of the original page that includes said frame. And probably a couple of other similar things. Essentially SOP indicates which resources can be trusted within a security context, which is important for all forms of client-side code executions. Feb 2, 2016 at 16:12
  • Also are you sure this isn't a duplicate of security.stackexchange.com/questions/8264/…? Feb 2, 2016 at 16:13
  • This kills the internet. The business model of the internet is surveillance. Third party sites wouldn't be able to track you. Feb 2, 2016 at 18:48
  • @SteveDL - did you mean iframes and not classic browser frames? I don't think the latter provide any security boundaries. Feb 3, 2016 at 0:43
  • 2
    @SteveDL this is not a duplicate since that questions says it's important because of cookies mostly. The main point of that question is to understand if cross-origin requests in ajax are blocked only for the reason of cookies? Why not to just not send the cookies in this case... Feb 3, 2016 at 8:21

2 Answers 2


No, the Same Origin Policy also protects against:

  • Cross domain manipulation in the DOM (e.g. a page manipulating another page from another origin loaded in an IFrame).
  • The response from AJAX requests being read when the origins don't match.
  • Images loaded from other origins from being read into an HTML5 canvas.

So my question is: would we really need this policy if the browser would not send all the http auth details and cookies with this request automatically?

Yes we do need it for the above reasons.

It could work like that, but not now because of backwards compatibility reasons. It would break too many things suddenly changing a standard that most of the world's web is based upon.

In any case, what would happen in the case that the whole window is redirected? e.g. if there's as sensitive function that could be exploited via CSRF using the GET method, the attacker could simply redirect the whole page to https://example.com/delete_users in order to execute the attack.

How would the browser know not to send cookies in that situation? It appears the only thing you would achieve is to make the rules more complicated, and complexity is the enemy of security.

  • Well, I guess that the latest problem is fixed by not allowing GET requests to such operations. I guess there are other issues with that like receiving that url in a mail where no same-origin will help you. Feb 3, 2016 at 12:10

To add to SilverlightFox' excellent answer:

Even if browsers did not send HTTP Auth headers and cookies with cross-domain requests (which is not practical because too many pages rely on this), cross-domain requests would still be dangerous, because a request may return private information even without authorization headers.

Essentially, the problem is that the client browser may have access to private resources using other authorization mechanisms. For example:

  • If the browser is in a private network behind a firewall, there may be private resources that are freely accessible from the private network, but not from outside.
  • If a resource authorizes access based on the client IP address or MAC address, the browser may have access because of the client computer it is running on.

In these situations, stripping out specific HTTP headers would not be enough.

As an aside, the idea of deliberately not sending cookies for certain requests has been implemented with SameSite cookies. SameSite cookies are not sent with cross-domain requests.

To avoid the backwards compatibility problems mentioned, SameSite cookies are "opt-in" - to create a SameSite cookie, the server must specify the SameSite when setting the cookie. Cookies set without this attribute continue to be sent for cross-domain requests, hence the Same-Origin policy remains important.

  • Careful with terminology: site has a very technical meaning in the context of the SameSite attribute. Using "cross-domain" instead of "cross-site" is misleading.
    – jub0bs
    Feb 4, 2021 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .