Cookie-Attribute request header proposal

David Eckel <> Sat, 03 September 2016 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7475112B018 for <>; Sat, 3 Sep 2016 01:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.468
X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DFZIk1QmCBlD for <>; Sat, 3 Sep 2016 01:17:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE2F3127A90 for <>; Sat, 3 Sep 2016 01:17:49 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bg64y-00065J-2U for; Sat, 03 Sep 2016 08:13:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bg64r-00064a-6a for; Sat, 03 Sep 2016 08:13:25 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bg64m-0001md-O3 for; Sat, 03 Sep 2016 08:13:24 +0000
Received: from ([] helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bg64m-000AKy-6W for; Sat, 03 Sep 2016 08:13:20 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: David Eckel <>
Resent-From: Yves Lafon <>
Date: Thu, 01 Sep 2016 22:09:14 +0000
Content-Transfer-Encoding: quoted-printable
Resent-Date: Sat, 3 Sep 2016 10:13:17 +0200
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
Message-Id: <>
X-Mailer: Apple Mail (2.3124)
X-W3C-Hub-Spam-Status: No, score=-2.0
X-W3C-Scan-Sig: 1bg64m-0001md-O3 29e0f0bcb197965ebc5b31a76c311a7d
Subject: Cookie-Attribute request header proposal
Archived-At: <>
X-Mailing-List: <> archive/latest/32373
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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