Re: Taking responsibility for CORS on the server side

This is something that has been raised a few times.  There is even a
proposal: https://wicg.github.io/origin-policy/#fetch-bypass-preflight

The webappsec group is probably a better place to discuss that (though
I note that the proposal is in the WICG group).

On Sat, Mar 9, 2019 at 2:51 AM Ruben Verborgh (UGent-imec)
<Ruben.Verborgh@ugent.be> wrote:
>
> Dear all,
>
> Recently, we had a very unpleasant surprise when one of our Web apps, which had been running fine for years, suddenly broke.
> It happened because our app accesses resources from public APIs at different origins. Those origins have CORS enabled.
> However, the fetch specification suddenly decided that valid HTTP headers above a certain length need explicit approval (we use a long Accept header).
> The only solution is to fix this on the server side.
> So servers that were correctly configured, suddenly have to change—without any guarantee that they will keep on working.
>
> This is bad news for the many Open Data APIs, public APIs, and authenticated APIs, out there,
> and the Web apps using them, which rely on cross-origin requests.
>
> Therefore, in addition to the very granular and complex CORS mechanism, we want a solution in which a server can simply state:
> “it’s okay, I am accepting full control of protecting cross-origin requests” (because I publish open data, or have my own authentication mechanism).
>
> Such a proposal is clearly advantageous for client and server developers, but the browser builders are the ones we have to convince.
> Therefore, if you also want a Web where public APIs are guaranteed to keep on working, please vote for our issue at
> https://github.com/whatwg/fetch/issues/878
>
> Your feedback is most welcome.
>
> Thanks in advance,
>
> Ruben
> --
> Ruben Verborgh
> Professor of Semantic Web Technology
> IDLab, Ghent University – imec
> https://ruben.verborgh.org/ – @RubenVerborgh

Received on Sunday, 10 March 2019 23:35:59 UTC