Cookie-Attribute request header proposal

In the idea of a Cookie-Attribute request header was suggested as a way to inform HTTP servers if a cookie could be trusted or not, without breaking backwards compatibility.  It would work as follows in the hypothetical request to

   GET / HTTP/1.1
   Cookie: tz=America/Los_Angeles;SESSIONID=a1b2c3
   Cookie-Attribute: ;Secure,HttpOnly,SameSite=Strict

The order of the attributes would match the order of the cookies. In the above example, the server could be confident that the SESSIONID cookie was set over a secure connection and was not vulnerable to being set via an XSS attack. It can also infer that the tz cookie may have been set by an untrusted party, and might choose to ignore it.

To accommodate more security and non-security related use cases, the Cookie-Attribute header could also include all of the other attributes, like Domain, Path, Expires.  Due to header size concerns they probably shouldn't be included by default.  Servers could opt-in to receiving these additional attributes by setting a uniquely named cookie that enumerates desired attributes, like "__Cookie-Attribute=Path,Domain". This could be useful when debugging, deleting cookies, and distinguishing between multiple cookies with the same name.  Example:

   GET /index HTTP/1.1
   Cookie: analyticsId=1;analyticsId=2;__Cookie-Attribute=Path,Domain
   Cookie-Attribute: Path=/,;Path=/index,;Path=/,

Known concerns:
   - Sending a new header and attributes increases the request size (per mnot's suggestion, this could be partially mitigated by abbreviating the header to something like "Cookie-A: ;S,H,SS=S" in the first example)
   - Opt-in security means a long road to adoption
   - Overlaps with Secure flag improvements in


David Eckel

Received on Saturday, 3 September 2016 08:13:25 UTC