-
Notifications
You must be signed in to change notification settings - Fork 78
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
Thoughts on letting CSP govern attributes that must appear in Set-Cookie #152
Comments
I guess this would be a proposal to allow CSP to say:
I guess 3. would be the default for backwards compatibility. |
Leaving this as a feature request for the future. I think something like this is worth doing, but probably more as part of https://wicg.github.io/origin-policy/ than CSP. |
Sounds good to me! (Needless to say almost), in the above proposal Shall I raise this over at https://github.com/WICG/origin-policy ? |
I suppose this issue should be closed in favor of WICG/origin-policy#8 |
thanks, sounds right. |
I realise this is mostly contrary to what CSP is conventionally: a whitelist. Though there are a few exceptions, notably
block-all-mixed-content
, which only performs blocking if proactively enabled.CSP has all sorts of directives controlling to where the page is allowed to communicate, though if an attacker on the network can exploit an XSS vuln, then they could exfiltrate data from the page via a deliberately insecurely set cookie.
Okay, so that's the extreme example.
More usefully, I wonder whether an application owner may simply want to specify a list of cookie names that it wishes to ensure are set with the
secure
and/orHttpOnly
flags, or not at all (or possibly auto-upgrade them). I can imagine a few examples where cookies are set in various places throughout code, and the application owner simply wishes to ensure that some known authentication cookies are always set securely, and out of the hands of JS.PS. I also note that CSP is parsed before
Set-Cookie
here (https://w3c.github.io/webappsec-csp/#fetch-integration), so perhaps this wouldn't be too in-plausible a change?The text was updated successfully, but these errors were encountered: