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

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 are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/253#issuecomment-199950058