Allow servers to take full responsibility of cross-origin resource protection

[RubenVerborgh]

Some servers want to completely opt out of cross-origin request protection, as evidenced by https://enable-cors.org/. This is a common use case.

Unfortunately, the there described way of opting out has recently been broken due to tightened security, as discussed in #862. Client applications stopped working, and the solution was at the server side. So https://enable-cors.org/ needs to be extended, and servers have to be reconfigured. This will take years to propagate.

To make matters worse, security can be tightened again at any point in the future, which will again break apps, and force new server-side changes.

I therefore propose the introduction of a header where the server states it will assume full responsibility of cross-origin resource protection, which is a future-proof way of opting out of any such protection on the client side. Servers who do not require any protection (think open data), or servers who have their own protection mechanisms (various forms of auth) will prefer that option to keep on working indefinitely. Servers with other needs can still resort to client-side protection and more granular CORS headers.

[pietercolpaert]

What is needed to get this issue on a high priority list?

[annevk]

Well, you'd need a detailed processing model, implementer support, and tests. Given that we explicitly did not want this kind of wildcard approach when we introduced CORS (it was seen as too dangerous by security teams), I somewhat doubt it'll see traction now, but perhaps. It's also not clear to me how exactly this is supposed to work as CORS affects requests too, to some extent.

[RubenVerborgh]

@annevk Thanks, could you point us to an example of such a detailed processing model that we could adapt for this purpose?

[annevk]

It basically comes down to an enumeration of the changes required to the standard. E.g., https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e. Even better would be a PR.

https://whatwg.org/working-mode and https://whatwg.org/faq#adding-new-features have more general guidance on new features. And might actually be a better place to start given that it's unclear there's much appetite for wildcarding as I said.

(https://github.com/WICG/origin-policy might also do away with some of the more granular need for CORS here and there.)

[yoavweiss]

@RubenVerborgh If I were you, I'd start by focusing on https://whatwg.org/faq#adding-new-features and particularly step 2 there: write down and detail out exactly what problem you're trying to solve, and why current solutions (e.g. adding Access-Control-Allow-Origin: * for such open-data servers) are not good enough.

Like @annevk, I'm skeptical there's much appetite for wholesale removal of CORS protections, but maybe we can solve the problems that you're hitting in some other way.

[mnot]

FWIW - I think there's plenty of appetite for this, just not from browser vendors.

In the past, we've talked about a disable-cors-i-know-this-is-really-dangerous-for-my-site flag.

I agree that origin policy (or similar) would be preferable to a header.

[RubenVerborgh]

Thanks @yoavweiss and @mnot, my colleague @pietercolpaert and I are writing a motivation.

Many servers are currently using Access-Control-Allow-Origin: * as a disable-cors-i-know-this-is-really-dangerous-for-my-site, without really understanding a) that this is not what it means b) what is actually happening. Part of the argument is that such obscurity is actually worse then giving them control.

We plan to provide an update soon.

[RubenVerborgh]

Formal proposal submitted to #878. Thanks @yoavweiss for input on the process.

@annevk @mnot I welcome your feedback at #878