4

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. – Steve DL Feb 2 '16 at 16:12
  • Also are you sure this isn't a duplicate of security.stackexchange.com/questions/8264/…? – Steve DL Feb 2 '16 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. – Neil McGuigan Feb 2 '16 at 18:48
  • @SteveDL - did you mean iframes and not classic browser frames? I don't think the latter provide any security boundaries. – Neil Smithline Feb 3 '16 at 0:43
  • 1
    @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... – Ilya Chernomordik Feb 3 '16 at 8:21
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. – Ilya Chernomordik Feb 3 '16 at 12:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.