Featured Developer Sponsor • Zero-Token Protection
HTTP Cookie & Set-Cookie Dissector
Audit RFC 6265bis security attributes, SameSite policies, privacy compliance, and modern Chrome CHIPS Partitioning rules.
Parsed Attributes
| Name | -- |
| Value | -- |
| SameSite | -- |
| Secure Flag | -- |
| HttpOnly Flag | -- |
| Partitioned (CHIPS) | -- |
| Domain Scope | -- |
| Path Scope | -- |
Security & Privacy Audit
RFC 6265bis Cookie Scope & CHIPS Partition Key Architecture
Modern user agents compute cookie isolation boundaries using strict canonical domain matching and double-keyed partition maps:
1. Canonical Domain-Match Predicate:
DomainMatch(H, D) ≡ (H = D) ∨ (EndsWith(H, "." + D) ∧ ¬IsIPv4orIPv6(H))
2. CHIPS Double-Keyed Storage Key:
PartitionKey = (TopLevelSite, OriginHost)
Prevents cross-site tracking across embedder contexts A.com and B.com.
3. ITP In-Browser Expiration Clamping:
Max-Ageeffective = min(Max-Agedeclared, 7 days [604,800s]) (or 24h if ad-click param present)
5 Fatal Traps in HTTP Cookie Security & Privacy Architecture
1. SameSite=None Without the Secure Flag
Modern engines (Google Chrome 80+, Safari 13+, Firefox 69+) unconditionally discard any incoming
Set-Cookie header that declares SameSite=None without simultaneously including the Secure directive. This ensures cookies transmitted across cross-site boundaries are never exposed over plaintext unencrypted HTTP.
2. Broad Domain Scoping Exposing Session Tokens to Subdomains
Explicitly declaring
Domain=.example.com scopes the cookie to the apex domain and all current and future subdomains (e.g. staging.example.com, cdn.example.com). If an attacker compromises a single neglected subdomain or XSS is present on an internal tool, they can silently harvest authentication cookies. Omit the Domain attribute entirely to lock cookies strictly to the origin host.
3. Omitting the __Host- Prefix Defense
Standard cookies can be overwritten or shadowed by malicious subdomains. Adopting the RFC 6265bis
__Host- prefix guarantees that the browser enforces three strict invariants: 1) the cookie must be Secure, 2) it must have Path=/, and 3) it must NOT include any Domain attribute.
4. Omitting HttpOnly on Sensitive Authentication Cookies
Failing to attach
HttpOnly makes cookies readable via document.cookie in client JavaScript. If any cross-site scripting (XSS) vulnerability exists—even in an auxiliary analytics script or third-party tag manager—attackers can immediately exfiltrate full session tokens without needing network interception.
5. Silent Dropping of Third-Party State in Iframes
Third-party unpartitioned cookies are completely disabled in Safari (ITP) and increasingly blocked in Chrome. Embedded widgets, payment iframes, and cross-domain authentication modules that do not declare
Partitioned (CHIPS) will fail to persist state, causing silent authentication loops.
Frequently Asked Technical Questions
What is the Partitioned (CHIPS) cookie attribute?+
Cookies Having Independent Partitioned State (CHIPS) allows third-party cookies to be partitioned by the top-level site you are visiting, preventing cross-site tracking while keeping embedded widgets and authentication functional.
Why is SameSite=None without Secure rejected by browsers?+
Modern browsers enforce that any cookie marked SameSite=None must also include the Secure flag, preventing transmission over unencrypted HTTP and defending against man-in-the-middle network interception.
What is the difference between __Secure- and __Host- cookie prefixes?+
The __Secure- prefix requires the cookie to be transmitted via HTTPS. The __Host- prefix goes further: it requires HTTPS, must have Path=/, and MUST NOT specify a Domain attribute, locking the cookie strictly to the origin host and preventing subdomain shadowing attacks.
How does Safari ITP impact cookie expiration?+
Apple Safari Intelligent Tracking Prevention (ITP) caps the lifetime of all cookies set via browser JavaScript (document.cookie) to a maximum of 7 days (or 24 hours if incoming tracking parameters like fbclid or gclid are present). Server-set HTTP cookies via Set-Cookie remain unconstrained.
What is the practical difference between SameSite=Lax and SameSite=Strict?+
SameSite=Strict prevents the cookie from being sent on any cross-site request, including top-level URL navigations (e.g. clicking an external link to your site leaves the user logged out). SameSite=Lax permits the cookie on top-level safe GET navigations while withholding it on cross-origin POST requests.
Sponsored Utility
While You're Here
Sponsored Recommendations
Advertisement