Allow * for Access-Control-Expose-Headers

[roryhewitt]

This has almost certainly been discussed before, but would it be possible to allow * (allow-all) as a separate value for the Access-Control-Expose-Headers CORS response header?

This would allow all non-simple headers passed in the request to be 'exposable' to client-side code.

When the original CORS spec was written, there was an assumption (I assume!) that the preflight OPTIONS response would be served by the same application that would serve the subsequent CORS GET/POST/whatever request. Therefore, that application would have full knowledge of what headers the API might eventually respond with, and which of them should be exposed or suppressed.

However, with the advent of CDN's and load balancers, it may be that the code that responds to the preflight OPTIONS request is not the actual application that will process the subsequent GET/POST/whatever request. Indeed, website owners might want the OPTIONS response to be served from non-application code, because that code may be quicker to respond to the client.

(Full disclosure: I work for Akamai, a large CDN. Whilst my views don't represent any official Akamai position, we would obviously like this, since it would make our (and out customer's) lives easier. I have also implemented CORS solutions using an F5 LTM load balancer, and run into this problem).

So the spec would become the following:

Access-Control-Expose-Headers = "Access-Control-Expose-Headers" ":" #field-name | "*"

If Access-Control-Expose-Headers: * is returned, browser would allow all headers to be returned using e.g. XMLHttpRequest getResponseHeader().

[annevk]

Implementers have traditionally been wary about doing this, since it could be a footgun. Servers might have forgotten about certain debug headers exposing information that was meant to be kept secret, etc.

@sicking @tyoshino?

[sicking]

I'd have to defer to the mozilla security team. I'm personally not super worried about this one though.

[annevk]

@dveditz @bifurcation @freddyb?

[annevk]

@rlbmoz? Or maybe you know who to ask?

[annevk]

See #253 (comment) for a comment from @sicking which suggests this should be reasonably safe to add, even for credentialed requests.

[tyoshino]

Hmm, From Jonas's comments, #253, I don't quite understand where the difference in handling (consideration) of credentials between wildcarded ACEH and the others (wildcarded ACAH, etc.) comes from. Maybe I'm missing something?

Jonas's #253 (comment) is assuming that the server doesn't alter the values of the non-simple headers based on the received cookie value?

[sicking]

I don't really have a strong reason for feeling more ok with * in ACEH than for the other AC* headers.

My thinking was mainly that it's less likely that headers contain personal data in general.

This isn't an argument for allowing * for ACAH since the concern there isn't about leaking private data, but rather about triggering dangerous side effects on the server.

I'm totally fine with allowing * in ACEH only for credential-less requests. It certainly makes things more consistent.

[dveditz]

I could support '*' for UN-credentialed requests (for consistency with ACAO) and it's unlikely to harm anything. I doubt that helps with the original use-case all that much though.

If your system has data for the application layer to use why can't it be included in the data/body itself? Why must it be stuffed into the metadata for the HTTP transport layer?

[dveditz]

It would help to see examples of real-world applications using ACEH to evaluate the need and safety of allowing '*' for credentialed requests. I'd rather respond to a demonstrated need than offer it just because we think it might be useful. It's a footgun to be sure.

[annevk]

Thank you @dveditz. We'll keep it restricted and consistent for now.