Summary

  • draft-ietf-httpbis-layered-cookies-02 defines Secure as a condition on sending a cookie over a secure channel; it does not turn cookie receipt into proof of the original setter, an authenticated human, valid server-side session or authorized action.
  • Cookie integrity boundaries differ from the web origin model: cookies are not isolated by port, Path is not an integrity barrier, and a sibling host can set a broader Domain cookie that another sibling may be unable to distinguish from its own.

The application received SID through TLS. The cookie carried Secure, HttpOnly and an apparently valid shape. The request therefore entered the authenticated-session branch before the application checked where that state could have originated.

Earlier, a sibling host under the same parent domain had set a broader Domain cookie with the same name. The user agent returned it on the protected request. TLS had faithfully delivered bytes from the connected client to the intended endpoint. It had not certified that this application created those bytes.

Revision 02 of Cookies: HTTP State Management Mechanism was published on 21 May 2026 as an active IETF HTTP Working Group Internet-Draft intended for the Standards Track. It expires on 22 November 2026 and says it would obsolete RFC 6265 and 6265bis if approved. It remains work in progress, not an RFC, browser-conformance survey or deployment result.

The document is valuable because it refuses to disguise the historical shape of cookies. The mechanism carries state effectively, but its coordinates do not line up with every modern security boundary.

Secure constrains delivery, not the whole state history

The Secure attribute tells the user agent to include the cookie only when the request uses a secure channel, normally HTTP over TLS. That is a meaningful protection. It prevents ordinary cleartext delivery under the specified retrieval rules.

It does not make the value self-authenticating. The application still needs to establish that the value was generated under its session policy, has not been revoked, maps to the expected principal and is valid for the requested action. A flag in user-agent storage cannot sign the server's internal state.

The draft also retains a historical warning: the cookie protocol's Secure attribute does not by itself provide integrity against every active network scenario. More broadly, transport protection begins after the client has selected which cookie values to attach. TLS authenticates a peer and protects the exchange under TLS semantics; it does not reconstruct how a stored value entered the cookie jar.

The safe log says: this request reached this endpoint over this negotiated TLS connection and carried this cookie material. It does not say: this application originally set the value, the current human intended the action or the server accepted the session.

Domain scope lets siblings share more than trust

Without a Domain attribute, a cookie is host-only and is returned to the origin host rather than its subdomains. With Domain, the cookie can apply to the named domain and eligible subdomains. Public-suffix controls stop a site from claiming an unrelated registry-wide scope, but they do not make sibling applications mutually trustworthy.

The draft's weak-integrity discussion is direct. A server at foo.site.example can set a Domain cookie for site.example. The user agent then returns it to bar.site.example. In a worst case, the receiving server cannot distinguish the value from one it set itself.

That is an authority problem, not merely a naming problem. A parent-domain cookie says where the user agent may return state. It does not say every eligible sibling shares one application principal, release process or compromise boundary.

Host-only cookies and prefixes can narrow exposure. They are controls worth using. Yet they still do not prove the human identity or the eventual authorization decision. Narrow scope is better evidence about routing, not a transfer of application authority.

Ports belong to origins, but not to cookie isolation

The web origin model includes scheme, host and port. Cookies do not provide isolation by port. Services on site.example:443 and another port on the same host can inhabit different origin tuples while participating in the same cookie scope.

An architecture diagram that draws ports as separate security boxes can therefore disagree with the state mechanism underneath. The separation is real for some browser policies and APIs, but not automatically real for Cookie and Set-Cookie handling.

The operational consequence is simple: do not place mutually distrustful services on different ports of one cookie host and assume the port boundary protects session state. Either separate the cookie host, cryptographically bind and validate the state, or remove the shared ambient credential from the design.

Observability should record destination scheme, host and port even when the cookie store does not. A session anomaly visible only on one port can still have originated from a value shared at the host level.

Path routes state; it does not isolate distrust

Path controls which request paths cause a cookie to be returned. It is tempting to give /finance and /support separate cookies and treat the paths as security containers.

The draft explicitly rejects that inference. Path does not provide integrity protection because a response from one path can set a cookie whose Path points somewhere else. Servers should not run mutually distrustful services on different paths of one host and rely on cookies for security-sensitive isolation.

The distinction is the same one Heng Lu's doctrine demands in governance: a bookkeeper's coordinate is not a mandate. Path is a selection coordinate. It helps the user agent decide when to send state. It does not grant one application exclusive authorship over that state.

Deleting also depends on exact scope. A Set-Cookie response with an expiry in the past removes the intended cookie only when Path and Domain match the stored tuple. A logout handler that emits the right name under the wrong scope can report success while another credential remains.

Prefixes reduce ambiguity without proving a person

Cookie-name prefixes such as __Secure- and __Host- impose additional acceptance requirements. A __Secure- cookie must satisfy secure-setting conditions; __Host- narrows the host and path shape further. These constraints can eliminate common injection and scope mistakes.

They do not change the claim ladder. The user agent accepted a cookie under stronger rules. Later, it retained and sent the value. The server must still validate the handle, recover server-side state, establish a principal and authorize the requested operation.

Prefix presence is not proof that application code follows one identity model, that a session has not been revoked or that a user approved the action. Treating a good hardening control as the last authentication step makes it carry liability it was not designed to own.

HttpOnly and SameSite govern different surfaces

HttpOnly limits exposure through non-HTTP APIs such as browser JavaScript. It reduces the surface from which script can directly read the value. It does not hide the cookie from the receiving server, prove who set it or prevent automatic attachment to eligible requests.

SameSite changes when the user agent sends the cookie in cross-site contexts. It can mitigate important classes of cross-site request behavior. It is not a person's identity, a consent receipt or universal protection against confused-deputy actions.

Stacking Secure, HttpOnly and SameSite is good practice when their semantics fit the application. The stack remains a collection of controls, not a single certificate reading “authorized user.” Each attribute owns a different decision and can fail independently.

Security reviews should therefore name what each setting prevents, which residual actor remains and what server-side check closes the next gap. A checklist with three green flags is not a threat model.

Ambient authority attaches before intent is proved

Cookies are an example of ambient authority because user agents attach them automatically to requests. A remote party can designate a target through a redirect, form or other mechanism without knowing the cookie value, while the user agent supplies the authority.

The server then sees a credential-bearing request. Without an anti-CSRF design and action-specific validation, it can confuse possession supplied by the browser with intent supplied by the user. The attacker designated the action; the browser attached the state.

This is why Cookie-header presence cannot sign human intent. It supports a bounded inference: under its current rules and store state, the user agent selected and sent these values. The application owns everything that follows.

A robust action receipt binds the authenticated session, request purpose, freshness, anti-replay or anti-CSRF material, authorization decision and committed result. The cookie is one input to that receipt, not its substitute.

Expiration is a ceiling, not a storage promise

Expires and Max-Age express maximum lifetime. The user agent is not required to retain the cookie for that whole period. It can evict state because of host or global quotas, memory pressure, privacy policy or direct user action.

A missing cookie therefore does not prove server revocation, logout, expiry or attack. It might have been evicted. Conversely, a present cookie does not prove the server-side session remains active. The server can rotate, revoke or reject the associated state.

Operational models need two lifecycles: client-side retention and server-side validity. A logout process should invalidate server state and attempt correctly scoped client deletion. Measuring only one side leaves an unowned gap.

The same discipline applies to incident review. “The cookie disappeared” is an observation. Cause requires store events, user-agent policy, response history and server session records.

Sources and limits

The frozen packet includes revision 02 and its Datatracker status, history and references; the HTTP Working Group; RFC 6265 and the 6265bis record; HTTP semantics; TLS 1.3; WHATWG origin and URL definitions; the IANA HTTP field registry; and the Public Suffix List.

These sources establish protocol text and official records. They do not establish conformance, prevalence, a real compromise, a browser implementation or a named service's behavior. The opening scenario is constructed to test the evidence chain.

Sources