You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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)?
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 tosame-origin
,same-site
orcross-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 ofcross-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.The text was updated successfully, but these errors were encountered: