same-origin policy should not be enforced on cross-origin requests where credentials is omit or same-origin

[davidbarratt]

Problem
Native apps are able to make a cross-origin, credential-less requests without the need of the CORS header. Web Apps should have the ability to make credential-less requests cross-origin without requiring the origin to state that the request is allowed. Credential-less requests pose no threat to the requested server.

Use Case
Suppose I want to create an RSS reader web app. It would be impossible to do that, because I'd have to ask every single site owner on the web to correctly implement CORS on their server.

Solution
Do not enforce same-origin policy on credential-less cross-origin requests where the requested server does not return any Access-Control headers.

Browser Bug Reports
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1483250
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=874079

[annevk]

I'm sorry, but this would break the same-origin policy. See https://annevankesteren.nl/2015/02/same-origin-policy for an explanation.

You cannot really compare this to native applications as they have a different trust model.

[davidbarratt]

"We invented CORS so that Untrusted can access the contents of resources on Example (and even on Credentialed and Intranet) as long as the resource opts in."

Why does the resource need to opt-in to un-credentialed requests? That doesn't make any sense.

[annevk]

@davidbarratt local network resources, IP-authenticated resources, etc.

[davidbarratt]

@annevk so instead of making the less than 1% of sites that that applies to opt-in to a restriction we'd rather the 99%+ of sites opt-in to the request being allowed? Asking that number of sites to opt-in creates a potential security vulnerability if they use * with credentials. On top of that, it cripples web apps from being able to access publicly available resources without asking for permission to do so.

[annevk]

There's basically no way to change the status quo here without unduly affecting end users.

[davidbarratt]

It wouldn't be the first time the web has changed the status quo without unduly affecting end users.

Let me give an example:
Suppose I want to create an RSS reader web app. It would be impossible to do that, because I'd have to ask every single site owner on the web to correctly implement CORS on their server.

So basically, it's impossible to create an web app like that (even though, it's a perfect use case for a web app).

To your point about same-origin policy... why is it that credential-less cross-origin requests are subject to the same-origin policy?

[davidbarratt]

The way this could be implemented without breaking backwards-comparability is, if a request is cross-origin, credential-less, then do the preflight request (like normal) if the response does not have any Access-Control headers, then the request is implicitly allowed. Likewise, on the actual request, the headers are checked again to ensure there are no Access-Control headers are present. If they are present, the normal CORS / same-origin policy applies. This way, existing sites that utilize CORS correctly can continue to do so, and sites that have not implemented CORS do not have to in order for their public resources to be accessible.

[annevk]

I'm sorry, but you continue to misunderstand the same-origin policy and what it protects against. I've given an external pointer and I'm sure you can find more on your own. Suffice to say that it's not just about credentials and isn't really about CORS either (CORS was created to enable sharing of resources within the confines of the same-origin policy).

[davidbarratt]

Perhaps a compromise would be to create a permission to do this? Allow the user to opt-into credential-less cross-origin requests?

[gileswells]

I see what @davidbarratt is saying though. If it's a publicly accessible resource that can be accessed through a server-side language without credentials or any other restrictions then why is the policy such that it prevents access to these same, fully publicly available resources, through ajax calls? I feel this is more of an issue that should be opened up for discussion. Per the policy as it stands right now it's not a bug but a discussion about if the policy should be updated might be a fair use of time.

[annevk]

@davidbarratt there's no way you can phrase that question in a way users will comprehend. https://annevankesteren.nl/2015/03/public-internet-proxy has some other alternatives I've considered.

@gileswells there's no guarantee that it's publicly accessible. There's no way to tell that it is (other than using a proxy of sorts).

[davidbarratt]

"Due to the same-origin policy protecting servers behind a firewall, cross-origin HTTP came to browsers as CORS and TCP as WebSocket."

Perhaps, that's the root of the problem... I guess what I am saying is that the web browser ought not be responsible for protecting servers behind a firewall. Those servers ought to be responsible for protecting themselves.

[annevk]

Sure, but we cannot flip that at this point. It'd put hundreds of millions of people at risk.

[davidbarratt]

[citation needed]

That assumes that hundrds of millions of people use a site behind a firewall that has absolutely no other protections.

I have yet to see a site like that. Every intranet site I've used (at a Fortune 500 company) have not only been restricted to to the firewall, but also have had some sort of employee authentication system.

I have no idea how this could be measured, but from my experience, this is a non-issue. If you allow anyone who has access to your network to have access to your intranet site, that means anyone could come into your physical location, use an open Ethernet port and take all of the data off of the intranet site... that's a huge security risk that most organizations are not going to take.

[annevk]

Your router doesn't have a site?

[davidbarratt]

sure it does! but it also has a username/password. With this change, I wouldn't be able to pass an Authorization or a Cookie header, so there would be no way to access it anyways.

Another security risk to a completely open intranet site, is that I could have a user download a portable native application onto their computer, then I have unrestricted access to every intranet site. This again, is why corporations have additional protections on their intranet site, and why my router requires a password on it's site. Sure, there might be some old old routers that don't, but that's already a huge security vulnerability that should be fixed anyways.

My point is, is that the browser is unnecessarily protecting intranet sites and giving a false sense of security.

[annevk]

That's a fairly weak point as installing a native application is much more involved than visiting a site. Anyway, this debate has been had many times already and browsers have repeatedly pointed out they're not willing to compromise end user security here.

[davidbarratt]

Your argument is that, it's ok to sacrifice user experience, in favor a security issue that is effectively nonexistent. And that a user's web browser (a client application) is responsible for protecting a server on the local network.

And that's fine to argue that, but please let the browsers themselves make their own decision(s) instead of closing my issues.

[annevk]

Well, I don't think it's nonexistent. And yes, I do think that a browser is responsible for not regressing on its end-user security.

And furthermore, I can speak for Mozilla Firefox on this matter.

[davidbarratt]

Ah, I'm sorry, I didn't know of the association.

What I am saying, is that the odds are greater that a security vulnerability is created by a server-administrator incorrectly implementing CORS, than they are of the security vulnerability of a completely open intranet site.

In my mind, you're choosing the greater vulnerability of the two. I understand that you don't agree with that, but I think it's worth considering that perhaps browsers have already implemented a security regression and it would be better to stop that regression.

[annevk]

I guess I should point out that Access-Control-Allow-Origin: * will fail for credentialed requests for the reasons you point out.

[davidbarratt]

well that's good to know!

The UX issue, is still a big problem in my mind. We're basically asking every site on the web to add an Access-Control header except open-access intranet sites and IP-authentication sites (and even they should probably add it restrict it to their own domain in order to be safe).

[annevk]

It sounds like you don't understand CORS. CORS only enables access, it doesn't restrict it. The same-origin policy restricts access.

[davidbarratt]

That's the discussion we are having, the default behavior is that access is restricted and you have to allow it with CORS.

I'm arguing that the default behavior ought to be allowing the non-credentialed request, unless CORS has put a restrictions on that request. Or to put it another way: CORS would be used to allow credentialed requests or restrict non-credentialed requests. If you've set Access-Control-Allow-Origin to a fixed value of example.com then the change I'm proposing would not affect your site because I would not be allowed to access your domain, I would be restricted by CORS. So while it's currently not used as a restriction, there's nothing stopping it from being used this way.

Reversing the behavior would mean that non-credentialed public resources would become available to a web app, and that intranet sites would be responsible for their own security (as they ought to be).

[sleevi]

It is standard in software design, such as APIs, or in secure system design, that once an API contract is made, or an invariant guaranteed, you don’t reverse that. The web’s invariant in the beginning was that there was no cross-origin access to program against. You could only display the content, reflecting the origins of HTML as a display language. The introduction of JavaScript, and the ability to control and manipulate content, necessitated security improvements to preserve that invariant. That was the Same-Origin Policy. As the ability to control and make arbitrary requests was expanded (via XMLHttpRequest), it became even more essential that websites - whether internal or external - should continue to have the invariants and API contracts preserved. I understand you are advocating that we should weaken the security of browsers and expose users to risk, because you feel these decades old security mitigations prevent legitimate use cases. However, since the Web tries very, very hard not to break APIs and invariants - especially when security is on the line - it opted for a different approach, CORS, to allow sites to opt-in. I do not see this changing anytime soon, not without fundamentally redefining the Web’s security assumptions. Every single Web feature would need to be re-evaluated if the SOP was changed as you describe, and there is real cost in doing so, and real harm if even the tiniest mistake is made. Given that alternative solutions exist, energy is better spent in making use of those alternative solutions.

[davidbarratt]

I completely understand why it is the way it is, and why you wouldn't want to change it. It makes 100% sense to me. I suppose I just don't agree with that, and that's ok. :)

I really appreciate @annevk & @sleevi taking the time to discuss this. That wasn't necessary at all, so it means a lot. I hope that my disagreement does not discourage you in the slightest. Keep up the good work. :)