Re: [whatwg/fetch] Proposal: Allow servers to take full responsibility for cross-origin access protection (#878)

> A number of your use cases (2, 4, and 7) refer to authentication or access control. I think understanding whether those use cases are being addressed securely (and, e.g., not in a way that's subject to the confused deputy problem) requires understanding what the use cases for that authentication or access control are.

Thanks @dbaron, that's a very relevant point indeed.

So, broadly (and very loosely) speaking, I see four categories of authentication between browser apps and servers:
1) none (public resources)
2) based on network access (e.g., IP or firewall, as mentioned in the [fetch spec](https://fetch.spec.whatwg.org/#basic-safe-cors-protocol-setup))
3) based on a client-side secret shared among different origins (e.g., cookie)
4) based on a client-side per-origin secret (e.g., OIDC)

Clearly, cross-origin protection is necessary for the second category, or the danger is that a web app reads privileged information. It is also necessary for the third category, if the client uses `credentials: include`, for the same reason. In both categories, the protection prevents that a script on evil.com can send a request to good.com and obtain personalized information.

The problem is that the browser doesn't know in which of the categories it is, so it makes a pessimistic assumption (for instance, that it is in category 2). That makes sense, given no explicit indication of which category it is in.

However, cross-origin protection is also applied in categories 1 and 4, and undesirably so. If the browser is told by the server in which category it is, a more informed action can be taken.

In category 1, the resource is public. So anyone from anywhere in the world sees the same thing; as such, the user's information cannot be compromised. So if the server were to state "this is a public resource", then not having cross-origin protection (now or in the future) is perfectly acceptable.

In category 4, evil.com cannot access the resource unless the user has authorized evil.com, in which case an evil.com-specific key will be sent to the server. So again, no need for browser-side cross-origin protection here _if_ the server indicates that it is taking care of cross-origin protections, because another mechanism is active that handles these protections.

We do not have a confused deputy problem in these categories. In 1, anyone can access. In 4, access for the specific origin is regulated through another mechanism.

> That is, why is authentication or access control being used, and is this solution sufficient for that reason?

Given that, as proposed, the server explicitly indicates that it takes control of cross-origin protections, then:

In category 1, no authentication is used/needed at all (so sufficient).
In category 4, authentication is used to personalize (access to) resources, and this personalization is regulated through another mechanism (so sufficient).

> This means that this header […] can make large amounts of data usable cross-origin in browsers, quickly

Well, yes and no. Yes, in that several cases work; no, in that it has become difficult to provide an exhaustive list of conditions that requests have to satisfy before being usable—or, conversely, an algorithm to generate the necessary headers for _any_ request to be usable. And any such a list or algorithm would not be stable.

Understood that such changes happen for security reasons, but the above categories 1 (no auth) and 4 (separate auth) are not impacted by them if the server chooses to regulate cross-origin protection itself. So that's why I am arguing for a sustainable solution for those categories.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/878#issuecomment-471170146