Re: [fetch] Add new Access-Control-Suppress-Headers CORS response header (#253)

@sicking, OK, here's a use-case for Access-Control-Suppress-Headers. You
may argue it's a little contrived :)

A developer has multiple endpoints (API's) on the same server. Each API
returns multiple headers, some of which are returned by all APIs, and some
of which are API-specific. The developer doesn't necessarily have direct
access to setting the CORS headers (maybe that's done in the web server
config or in a load-balancer or by a CDN). Or maybe they do, but they're
looking for simplicity.

So we have something like this:

*getCustomerData() *returns* x-header1, x-secure and x-header2*
*getCustomerStatus() *returns* x-header1 and x-header3*
*setCustomerStatus() *returns* x-header1, x-secure, x-header2 and x-header3*

In this case, all API's return *x-header1*, and the others are only
returned by some API's. The *x-secure* header is only returned by two of
the API's, and it should only be exposed if the request comes from the same
domain as the API.

If we only allow Access-Control-Expose-Headers, then the generation of that
header line must be done by the developer (or by someone with explicit
knowledge about which headers are allowed to be returned by which API and
which are not). So the developer would have to generate the following
header lines which are specific to each API:

*getCustomerData() - Access-Control-Expose-Headers: x-header1, x-header2
(plus x-secure if request coming from *.example.com <http://example.com>)*
*getCustomerStatus() - Access-Control-Expose-Headers: x-header1, x-header3*
*setCustomerStatus() - Access-Control-Expose-Headers: x-header1, x-header2,
x-header3 (plus x-secure if request coming from *.example.com
<http://example.com>)*

However, if we are able to simply specify this:

*Access-Control-Suppress-Headers: x-secure (unless request coming from
*.example.com <http://example.com>)*

then this can be done in the load-balancer or CDN, by someone with only
minimal knowledge of the underlying application. All they need to know is
that x-secure MAY be returned by the application, and if so, it should not
be exposed unless the request came from *.example.com.

Additionally, if a new header, *x-header4* is being added to any of the
above API's, then the various *Access-Control-Expose-Headers* lines need to
be changed in the code to add it. Whereas if they have used
*Access-Control-Suppress-Headers:
x-secure*, then there is no additional work - *x-header4* will
automatically be exposed.

Essentially, if we make security simpler to implement, then more people
will use it correctly. This gives them the option to suppress things which
they don't want exposed, with minimal fuss.

I think the problem here is that server-side developers are not a single
group - there are often multiple different groups involved (especially in
large organizations, and doubly-so where those organizations are not
themselves tech companies). Giving an organization the ability to simplify
their setup, whether it's in their Apache configuration or somewhere else
which is not controlled by the actual server-side developer is a good
thing, no?




On Tue, Mar 22, 2016 at 11:22 AM, Jonas Sicking <notifications@github.com>
wrote:

> I agree that Access-Control-Expose-Headers: * would be useful. And
> probably safe enough that we should add it.
>
> You still have not provided a use case for Access-Control-Suppress-Headers.
> I.e. when would a developer knowingly want to send a header to the client,
> but not expose it to the webpage?
>
> The whole design philosophy behind CORS is that server-side developers
> should not be required to have perfect understanding of all the code that
> is running on your webserver but still allow them to expose data that they
> want to expose to 3rd parties.
>
> So even on a server where you might be handling sensitive user data, or
> where you might have scripts that do sensitive transactions on the server,
> you can white-list certain URLs and let those send and receive data. And
> you can do that without having to perfectly audit the rest of the
> URL-handling scripts on the server.
>
> But say that the server-side developer *know* that some URLs serves some
> data that should be shared with 3rd parties, and some data that should not
> be shared with 3rd parties. In that case, simply stop sharing the data that
> should not be shared with third parties before you opt in to CORS for that
> URL.
>
> It seems silly to at that point opt in to CORS but knowingly keep sending
> the data that should not be shared, and send a header saying "I know i'm
> sending this data, but please don't share it with the website". Simply stop
> sending the data instead.
>
> Or, to put it another way. If you can't perfectly audit what data you are
> sending in which headers, use Access-Control-Expose-Headers: a, b, c to
> opt in to sharing the headers that you know are safe. If you can perfectly
> audit what data you are sending in which headers, then stop sending any
> data that should not be shared, and then use Access-Control-Expose-Headers:
> *
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub
> <https://github.com/whatwg/fetch/issues/253#issuecomment-199950058>
>



-- 
Rory Hewitt

http://www.linkedin.com/in/roryhewitt


---
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/253#issuecomment-199978295