3

This is not the same question as Why is the same origin policy so important?.

That one asks only about why cookies are only ever send to origin they came from, which I understand.

What I don't understand is why there's a restriction to the resources I can request from the browser, ie. why

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy.

(from developer.mozilla.org)

Obviously a web application developer can always work around that restriction by delegating such requests to the app's server.

First I thought it may be so that an XSS breach into a web app doesn't allow the attacker to send critical data to himself - but that one is still possible: He just needs to send the right CORS headers from the server he owns, as the CORS headers are expected to come from the requested resource and oddly not from the origin server (as is the case with content security policies, which I again understand).

So what's the point?

John
  • 141
  • 4
  • 2
    Possible duplicate of [What is the point of the same-domain rule for xmlhttprequest when script tags/JSONP can cross domains?](https://security.stackexchange.com/questions/13010/what-is-the-point-of-the-same-domain-rule-for-xmlhttprequest-when-script-tags-js). In summary: the main point of SOP for XHR and fetch is to prevent **read**-access to other sites where the user might be logged in or similar. – Steffen Ullrich Aug 07 '18 at 11:37
  • @SteffenUllrich Then why are the requests not made without the respective cookies? (The question is duplicate indeed, but I still don't find the answers satisfactory.) – John Aug 07 '18 at 13:31
  • This is a different question - i.e. you understand why SOP is for with XHR with how XHR (and other requests from the browser) work but now ask why the XHR behavior does not get modified to not include cookies or credentials instead of enforcing SOP. – Steffen Ullrich Aug 07 '18 at 14:42
  • XHR and fetch api, the latter doesn't send any cookies by default anyway, not even to the same origin. The question is indeed only about the requests, not about foreign-origin cookies that obviously have no business being sent. So you have an answer to this mystery? – John Aug 07 '18 at 16:21

1 Answers1

4

I think the issue is that you might have a bit of misunderstanding about the purpose of SOP/CORS in the first place. An important point that often gets missed is that the SOP doesn't forbid you from sending data to a different origin - it only prevents you from reading the response from the separate origin. You say this:

First I thought it may be so that an XSS breach into a web app doesn't allow the attacker to send critical data to himself

And then clarify that the attacker would still be able to send data to himself by enabling some CORS headers on the receiving server. However, even that is not necessary. For simple GET and POST requests the browser will still send the request to the destination server, and that server will be able to receive and act on it normally without any issue what-so-ever. The only thing that will change as a result of the SOP is that the browser will refuse to allow the calling script to receive the response from the server [**exeception at bottom].

That's really the key. The same-origin-policy is all about refusing to let origin A read anything from origin B unless explicitly allowed by origin B. That is why CORS headers are set on the receiving server, not the origin server. If someone accidentally visits evil.com we don't want javascript on that page to be able to read data from facebook.com unless facebook.com has explicitly said otherwise.

Of course the primary use-case for this is with access credentials. The browser will automatically attach cookies from facebook.com to every single request that goes out to facebook.com, even if the javascript making the request runs on evil.com. As a result if the SOP did not prevent cross-domain reads, anyone would be able to read your facebook profile anytime you visited any page anywhere that had javascript they control. The browser's insistence on sending cookies with every request to a given domain (which is pretty much a requirement for many web applications to work properly) is the main impetus behind the SOP and CORS restrictions.

For a website that doesn't use authentication CORS is generally going to be a lot less important. After all (as you say) the request could simply be made by a server and the response relayed to whatever javascript is running in the browser. In such a case a site can even disable CORS by sending the Access-Control-Allow-Origin: * back on all requests. Note that if a server does that it cannot also set the Access-Control-Allow-Credentials: true flag on. Browsers do not allow you to let everyone read your stuff and also send cookies along to all requests.

All that to reiterate: SOP is all about forbidding javascript running on origin A from reading anything from origin B. It separates out domains/protocol/port so that people are only allowed to read their own things, and is one of the most basic protections baked into web browsers.

** I said that SOP/CORS does not stop the browser from sending your request. There is an exception to this rule. In the event of a "non-standard" request the browser will send a "pre-flight" verification request. Specifically, it will send a request to the endpoint with a request method of "OPTIONS", asking the server what kind of requests it will accept. If the request being sent doesn't match then the browser will not send the request in the first place.

Edit to add

Obviously your main question is "But if no cookies are involved then why even block reads in the first place?". I aimed to get that with my original answer, but let me try to address that more directly:

You're looking at security from the wrong perspective (in this particular case). You're effectively looking for a reason to deny access to a particular privilege (i.e. "why can't I do that?"). A much more robust way of approaching security problems is from the opposite direction: everyone should have the minimum privileges they need and they should only be given additional access if there is a reason. Instead of asking "Why can't I do this?" the better question is "Why should I let you do this?".

When you look at it from that perspective the default policy of the SOP to block all read requests unless explicitly authorized makes much more sense and is basically just standard security. Yes, people can circumvent this security step by doing things like making the request via a server. However, the fact that a security step can be circumvented doesn't mean it is a bad idea. There are lots of ways to circumvent the lock on your car door, but that doesn't mean you should just stop locking your car. Good web security is about defense-in-depth: layered security so that if a weakness is found in one area your system can still be secure. The SOP and read restrictions is basically just the very first layer of security for web applications.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • I see that it would be wrong to attach the cookies on requests to a different domain, but what's the rationale for prohibiting them altogether (or prohibiting reading the response)? Also to "In such a case a site can even disable CORS by [...]", that's not correct, is it? I need to have that header on all the resources being requested, which are potentially not even under my control. – John Aug 07 '18 at 13:29
  • 1
    @John By site I meant the third party domain that is being accessed from elsewhere. I.e. if you run a site `lateststockprices.com` and want to make those prices available to anyone anywhere, then you can set a header in your responses (`Access-Control-Allow-Origin: *`) that will allow people to include your stock prices via javascript API call on any site that wants to. – Conor Mancone Aug 07 '18 at 16:34
  • @John I added another section to my answer to address your main question a bit more directly. – Conor Mancone Aug 07 '18 at 16:46
  • The reasoning of your edit makes sense to me for security policies, which are defined by the origin server. But here the *resource owner* gets to restrict access - and I can‘t understand what he‘s got to do with it: If he wants to protect his resource, he obviously needs other means anyway. Authentication, most likely. – John Aug 07 '18 at 16:56
  • I don't follow. The resource owner has everything to do with it, because he owns the resource. Who *but* the resource owner should determine access rules? Again, the SOP effectively makes sure that everyones' resources are safe by default, and the resource owner has to take action to make their resources available without restriction. That's the only model of security that would work. – Conor Mancone Aug 07 '18 at 17:00
  • Obviously I can access his resource, just not with browsers. That‘s about as much security as allowing access only from every odd IP address. Makes no sense. Except if there‘s some key argument missing here that applies only to browsers. – John Aug 07 '18 at 17:04
  • The special thing about a browser is that it doesn't belong to you - it belongs to someone else, and works on their behalf, but executing the code you supply. They are assumed to be willing to blindly follow your instructions on how to interact with your resources, but they can't be assumed to be willing to blindly follow your instructions on how to interact with third party resources unless you can persuade them to install a native application or similar. – bdsl Feb 21 '19 at 21:37
  • The browser is a 'deputy' of its user. If it didn't correctly enforce the same origin policy it would have the *confused deputy problem*. https://en.wikipedia.org/wiki/Confused_deputy_problem – bdsl Feb 21 '19 at 21:43
  • "However, the fact that a security step can be circumvented doesn't mean it is a bad idea." I don't quite agree with this. As a default behaviour, it's not a bad idea, but there are certainly cases where the SOP is unnecessary. Unnecessary "security" leads to a false sense of confidence. In these cases, it's more like security by obfuscation or security theatre. – cbreezier Nov 04 '20 at 02:26