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

Sending Sec-Fetch-Site: none after redirects from directly user-initiated requests #39

Closed
arturjanc opened this issue Jul 31, 2019 · 4 comments

Comments

@arturjanc
Copy link
Contributor

It is clear that we want to set site=none on non-webby requests, e.g. initiated from the address bar, bookmarks, etc.

It is less clear what we should do upon redirects to such requests, i.e. whether we should still treat them as trusted and set none or whether we should follow the usual logic we apply to redirects (which would take into account the original URL, and would downgrade the site value to same-origin, same-site or cross-site depending on the target of the redirect).

The security downside of none is that an address bar navigation to a seemingly benign URL (evil.com) will allow the owner of the server to redirect the user to an arbitrary cross-site URL and make the navigation seem trusted. The compatibility downside of cross-site is that it would make address bar navigations to redirectors (e.g. shortlinks) appear as untrusted to the target server, which may want to then reject the request.

I don't think the security risk is particularly bad here so perhaps the status quo in Chrome (sending site=none) is the best choice. But we should think about this more explicitly.

@mikewest
Copy link
Member

mikewest commented Aug 5, 2019

I do think Chrome's current behavior is pretty reasonable, especially in the somewhat common case of shortlinks. If I type https://mkw.st/r/csp into my address bar, I really do mean to go to a hideously outdated article I wrote a million years ago. It would be odd if we triggered security checks for that use case (and I'm not sure it's at all distinguishable from the evil.com case you note above).

@arturjanc
Copy link
Contributor Author

Sounds reasonable -- let's leave site=none sticky on redirects and wait until this comes back to haunt us.

I think @jerryzz0 was considering proposing some spec text to provide a more detailed explanation about the meaning of site=none. Maybe it be useful to also document this aspect explicitly in the redirects section (§4.1 Redirects)?

@mikewest
Copy link
Member

I welcome spec text proposals. :)

@mikewest
Copy link
Member

I added a note to close this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants