HTTP Cookie Parser & Auditor

01 Cookie Attribute Impact Matrix

02 Header Audit Pipeline

03 The Three Flags That Decide Cookie Security

Most cookie vulnerabilities trace back to a missing or misconfigured flag. Three attributes, Secure, HttpOnly, and SameSite, do the heavy lifting, and they protect against three distinct threats. Understanding what each one stops (and what it does not stop) is the difference between a session cookie that survives a penetration test and one that leaks tokens.

Secure, protects the cookie in transit

The Secure flag tells the browser to send the cookie only over HTTPS. Without it, a session cookie set on an HTTPS page can still be transmitted over a plain HTTP request to the same host, for example a stray http:// link, an image, or an attacker forcing a downgrade on an open network. That single cleartext round-trip is enough to capture the session token. Modern browsers also require Secure for any cookie marked SameSite=None, and they silently drop a Secure cookie if the originating request was not HTTPS, a frequent cause of "my cookie isn't being set" on localhost over HTTP.

HttpOnly, protects the cookie from scripts

HttpOnly removes the cookie from the document.cookie API, so client-side JavaScript can neither read nor write it. This is your primary defense-in-depth against cross-site scripting (XSS): even if an attacker manages to inject a script into your page, they cannot exfiltrate an HttpOnly session token through the cookie store. Crucially, HttpOnly does not stop CSRF, the browser still attaches the cookie automatically to every matching request, and it does nothing about network interception. Any cookie that authenticates a user (session IDs, refresh tokens) should be HttpOnly; cookies your front-end genuinely needs to read (a theme preference, a non-sensitive feature flag) should not be.

SameSite, protects against cross-site requests

SameSite governs whether the cookie rides along on requests originating from other sites, and it is the front line against CSRF. Strict blocks the cookie on every cross-site request, including a user clicking a link from an external page into your app, secure, but it logs people out when they arrive from an email or search result. Lax, the modern Chrome default when no attribute is specified, sends the cookie on same-site requests and on top-level GET navigations, but withholds it from cross-site POSTs, fetch() calls, and iframes, a sensible balance for most session cookies. None sends the cookie on all cross-site requests and must be paired with Secure; reserve it for cookies that genuinely operate inside third-party iframes, such as embedded checkout or single sign-on widgets.

04 Reading a Set-Cookie Header

A production Set-Cookie header packs the name, value, and every directive onto a single semicolon-delimited line. Knowing how to read it at a glance saves you from copying secrets into a logging service or misjudging a cookie's scope. Consider this typical session cookie:

Set-Cookie: session_id=eyJhbGciOi...; Domain=example.com; Path=/;
        Expires=Wed, 09 Jun 2027 10:18:14 GMT; Max-Age=31536000;
        Secure; HttpOnly; SameSite=Lax

The first token, session_id=…, is the name-value pair; everything after the first semicolon is an attribute. Domain and Path define the scope, which hosts and URLs the browser will replay the cookie on. When both Max-Age and Expires are present, Max-Age wins in every modern browser, so this cookie lives for one year regardless of the absolute date. The trailing flags, Secure, HttpOnly, SameSite=Lax, are the security posture. This header represents a well-configured session cookie: it cannot be read by JavaScript, never travels over HTTP, and is withheld from cross-site POST requests.

The parser above tokenizes exactly these directives, normalizes the two expiry representations into a single human-readable lifetime, resolves Domain wildcards against the host that set the cookie, and then audits the flag combination against current browser defaults. Because all of this runs locally in your browser, you can paste headers straight from production traffic, live JWTs, CSRF secrets, and opaque session identifiers included, without any of those values leaving your machine.

05 Session vs Persistent: How Cookie Lifetime Works

A cookie's lifetime is decided entirely by its expiry directives. With neither Expires nor Max-Age, the browser treats it as a session cookie, it lives in memory and is discarded when the browsing session ends. This is the safest default for authentication: close the browser, and the credential is gone. Add either directive and the cookie becomes persistent, written to disk and surviving restarts until the deadline passes.

The two directives express the same idea differently. Expires is an absolute timestamp in the IMF-fixdate format (Wed, 09 Jun 2027 10:18:14 GMT), which means it depends on the client's clock being correct, a device with a skewed clock can expire the cookie early or keep it alive long past intent. Max-Age is a relative count of seconds from the moment of receipt, immune to clock skew, and it always takes precedence when both are present. To delete a cookie, a server re-sends it with the same name, domain, and path but a Max-Age=0 or a past Expires date; the browser then drops it immediately. The parser above collapses both representations into one human-readable lifetime so you never have to do the date arithmetic by hand.

06 Common Misconfigurations and How to Fix Them

Most cookie bugs are not exotic, they are the same handful of mistakes repeated across codebases. Recognizing them turns a confusing "the cookie just won't set" afternoon into a one-line fix.

SameSite=None without Secure. Every modern browser rejects this combination outright, the cookie is silently dropped. If you need a cookie inside a third-party iframe, you must add Secure, and increasingly Partitioned as well. A wildcard Domain that is too broad. Setting Domain=.example.com when only app.example.com needs the cookie hands it to every subdomain, including ones you do not control as tightly, a needless expansion of attack surface. Scope it to the exact host unless cross-subdomain sharing is a genuine requirement.

Missing HttpOnly on a session token. If your authentication cookie is readable from document.cookie, a single XSS payload exfiltrates it. Front-end frameworks rarely need to read the session cookie directly, so default it to HttpOnly and expose only non-sensitive state to JavaScript. Relying on Path for isolation. Path scoping is cookie hygiene, not a security boundary, any script on the page can read cookies regardless of their Path. The auditor flags each of these patterns independently and explains the trade-off so you can decide what is intentional and what is an oversight.