Force cookie scope to host, secure, or none

[enygren]

Relying purely on the public-suffix-list for limiting cookie scope doesn't scale well.
It would be preferable if there was a way for servers to indicate that cookie scope
should be limited via a response header.

@mikewest wrote up https://www.w3.org/TR/csp-cookies/ a few years back but it stalled out.
One approach would be to define this as a new response header (not part of CSP) as part of 6265bis.

Outside of CSP this might be something like:

Cookie-Scope: none
Cookie-Scope: host, secure

From the csp-cookies draft it proposes:

The directive has one of four values:

• "host" allows "host only" cookies to be set, but will block setting cookies which set a domain attribute.
• "http" allows cookies to be set via the Set-Cookie HTTP header, but not via document.cookie.
• "none" blocks all cookies.
• "secure" allows cookies to be set with a secure attribute, and will block setting any non-secure cookies.

[davidben]

Moving this out of CSP seems like a step backwards to me.

By the time the UA receives Cookie-Scope, cookies have already been sent. So, on the cookie reading side, this isn't a replacement for the server only looking at __Host-- and __Secure--prefixed cookies. As phrased, this can only help on the cookie setting side.

So then perhaps the theory is this is some declarative extra layer to prevent the resource from accidentally setting cookies it doesn't want. However, the Set-Cookie and Cookie-Scope headers all in the same response anyway. If serving logic is adding a Cookie-Scope header to defend against bad Set-Cookie lines, it could strip the bad Set-Cookie lines in the first place.

Now, document.cookie is also a way to set cookies. Between XSS and such, it is perhaps worth a an extra layer against unwanted calls to document.cookie. That requires integrating the header into document-level state in the web platform. That infrastructure and use case is precisely CSP.

[miketaylr]

If serving logic is adding a Cookie-Scope header to defend against bad Set-Cookie lines, it could strip the bad Set-Cookie lines in the first place.

This was my thought as well. Is there some implied use-case where you can only add headers, but not control what headers you send out at the application level?