Thoughts on letting CSP govern attributes that must appear in Set-Cookie

[aidantwoods]

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/or HttpOnly 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?

[aidantwoods]

I guess this would be a proposal to allow CSP to say:

1. All cookies must be set with secure and HttpOnly
2. Here is a list of cookies which must be set with secure and HttpOnly
3. Cookies can be set without secure or HttpOnly

I guess 3. would be the default for backwards compatibility.
Possibly allow some granularity on whether secure and HttpOnly must be set, or whether just one of the flags is enforced in 1. and 2.

[mikewest]

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.

[aidantwoods]

Sounds good to me!

(Needless to say almost), in the above proposal sameSite should also be considered, along with any newer attributes that might exist when this is implemented.

Shall I raise this over at https://github.com/WICG/origin-policy ?

[Malvoz]

I suppose this issue should be closed in favor of WICG/origin-policy#8

[dveditz]

thanks, sounds right.