Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Content-Length header in CORS requests #622

Closed
benjamingr opened this issue Oct 29, 2017 · 13 comments
Closed

Expose Content-Length header in CORS requests #622

benjamingr opened this issue Oct 29, 2017 · 13 comments
Labels
security/privacy There are security or privacy implications topic: cors

Comments

@benjamingr
Copy link
Member

As discussed with @annevk on IRC. (thanks again for the direction)

Currently Chrome and IE (but not Firefox) expose e.total on ProgressEvents. This was discussed in #284.

The value of Content-Length is very valuable on HEAD requests. We sometimes make HEAD requests to resources in order to choose whether or not they are prohibitively expensive for the client to download or not - or to make smart decisions about downloading them.

Currently this is possible (due to ProgressEvents on Chrome) but not Firefox - I think we should safelist the Content-Length header in CORS requests.

@annevk annevk added the security/privacy There are security or privacy implications label Oct 31, 2017
@annevk
Copy link
Member

annevk commented Oct 31, 2017

@estark37 @mikewest @dveditz @ckerschb what do you think? The additional risk here would be when Content-Length contains some unusual value, but generally if you expose the response body you also expose its length. And apparently we already expose it through side channels such as progress events.

@mikewest
Copy link
Member

mikewest commented Nov 3, 2017

For my own clarity, the suggestion is that we'd add this to the list of CORS-safelisted response-header names, so that it would be exposed on filtered responses without the server opting-in via Access-Control-Allow-Headers? That seems reasonable to me.

@TejasQ
Copy link

TejasQ commented Nov 3, 2017

I'd find this quite useful as well. +1.

@annevk
Copy link
Member

annevk commented Nov 3, 2017

@mikewest yes.

@estark37
Copy link
Contributor

estark37 commented Nov 3, 2017

Sounds reasonable to me as well.

@annevk
Copy link
Member

annevk commented Nov 6, 2017

@benjamingr are you interested in writing a PR for this and perhaps even corresponding changes to web-platform-tests?

@annevk
Copy link
Member

annevk commented Nov 6, 2017

(To be clear, I think this has enough support from implementers to be merged.)

@benjamingr
Copy link
Member Author

@annevk sure, I'll go right ahead. I apologize in advance about getting the PR wrong :)

benjamingr added a commit to benjamingr/fetch that referenced this issue Nov 6, 2017
@domenic
Copy link
Member

domenic commented Nov 6, 2017

I'm unclear why we're adding more cross-origin information leaks to the platform :(

@annevk
Copy link
Member

annevk commented Nov 6, 2017

@domenic you're concerned about a server having Content-Length: SECRET and inadvertently revealing that to the other party it's happy to use CORS with?

@domenic
Copy link
Member

domenic commented Nov 6, 2017

I think so, although maybe I'm not fully understanding?

In general I'm concerned with any movement away from a model where getting information cross-origin requires opt-in from the cross-origin target server.

@benjamingr
Copy link
Member Author

@domenic this is specifically for content length in a CORS request, this is useful for video players who can then decide whether or not to download a video segment via HEAD request for example.

If you'd like I can add more motivating examples. It currently leaks anyway, but in a hacky way.

@domenic
Copy link
Member

domenic commented Nov 6, 2017

I think I was misunderstanding the situation because of my confusion between "CORS request" and "cross origin request". This is probably fine, and I didn't mean to second-guess security folks anyway, just understand better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security/privacy There are security or privacy implications topic: cors
Development

No branches or pull requests

6 participants