What Is a Session Cookie?

A server creates a session cookie by sending a Set-Cookie response header that has no Max-Age and no Expires attribute — those are the two things that would give it a lifespan:

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

The browser holds this cookie in memory (not on disk) and automatically attaches it to the Cookie header of every later request to the same origin during the same session:

GET /account HTTP/1.1
Cookie: sessionId=abc123

Close the browser and the cookie disappears. On the next visit the server sees no sessionId, so it treats you as a brand-new visitor — there is nothing left to recognise you by.

By default, per RFC 6265, the cookie goes back only to the exact origin server that set it (not its subdomains) unless the Domain attribute widens that scope. The Path attribute can do the opposite and limit which URLs receive the cookie.

The only thing that separates the two is how long they live, and that is decided by two attributes on Set-Cookie:

A persistent cookie lives on disk through browser restarts and is removed only when its Max-Age runs out, its Expires date passes, or the user clears it by hand. The "remember me" checkbox on a login form simply turns a session cookie into a persistent one by attaching an expiry date weeks or months in the future.

Caveat: modern browsers smudge this line with session restoration. Chrome, Firefox, and Safari can keep session cookies across restarts when the user has "continue where you left off" turned on. To the server it is still a session cookie; to the user it may quietly survive a reboot. RFC 6265 deliberately leaves what counts as "session ends" up to the browser.

Even with no Expires/Max-Age, a Set-Cookie header can carry several other attributes that meaningfully change how the session cookie behaves:

• HttpOnly — JavaScript cannot read the cookie through document.cookie. This matters because it blocks XSS attacks (malicious scripts injected into a page) from stealing session IDs. A session cookie missing this flag is a security bug.
• Secure — the cookie is sent only over HTTPS (encrypted) connections, never plain HTTP. Every modern session cookie should have it.
• SameSite=Lax | Strict | None — controls whether the cookie rides along on requests coming from other sites. Lax (today's default) sends it when you click through to the site but not on cross-site sub-requests like <img> tags or XHR (background JavaScript fetches). Strict blocks every cross-site request. None allows full cross-site sending but requires Secure — used by embedded widgets and federated login. Most CSRF protection (defence against forged cross-site requests) comes from SameSite=Lax.
• Domain — widens the cookie from origin-only to a whole parent domain (e.g. Domain=example.com makes it visible to api.example.com, www.example.com, and so on). Without it, RFC 6265 keeps the cookie tied to the exact origin that set it.
• Path — restricts the cookie to certain URL paths (e.g. Path=/account sends it on /account/* but not /blog/*). Used less often.

A modern, well-configured session cookie looks like:

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Nearly every major anti-bot vendor stores its session-level trust in a session cookie. The cookie is the visible sign that a client has passed — or is currently being scored against — the vendor's detection model. Examples:

• _abck — Akamai Bot Manager. Its value starts at ~-1~ (untrusted) and flips to ~0~ only after sensor.js POSTs valid signals. Trust builds up over the session.
• cf_clearance — Cloudflare. Shows the client solved a JavaScript challenge or a Turnstile interaction.
• datadome — DataDome. Scored per request, but the cookie tags sessions already seen and lightly trusted.
• reese84 — F5 Shape Security. A validated session token from its custom JS VM; expires in minutes.
• _px3 / _pxde — PerimeterX / HUMAN Security. Carries the 5-vector fingerprint score.
• x-kpsdk-ct — Kasada. A single-use proof-of-work token, not reusable across requests.

By RFC 6265's definition these are all session cookies — no Expires or Max-Age, lifetime tied to the browser session. That has a real consequence for scrapers: swapping proxies in the middle of a session throws away the trust those cookies built up, which is why ISP static residential IPs are preferred over rotating residential for Akamai targets.

The takeaway: when an anti-bot vendor talks about "session-level scoring", they almost always mean a session cookie they control. Knowing which cookie they set, what state values to expect, and when the state flips is half the work of handling the vendor's verification flow.

• Session fixation. If an attacker can plant a session cookie value (via a subdomain takeover, a network MITM — man-in-the-middle interception — or a too-permissive Domain attribute), they can hijack the victim's session after the victim logs in. Defence: regenerate the session ID at every privilege boundary (login, role change) and always set HttpOnly + Secure + SameSite=Lax.
• Session hijacking via XSS. Without HttpOnly, injected JavaScript can read document.cookie and ship the session ID off to an attacker-controlled URL. The HttpOnly flag is the single most important protection for session cookies; it should be on by default for every one of them.
• GDPR and consent. Strictly necessary session cookies (login, shopping cart, CSRF tokens) need no consent under GDPR. Analytics and tracking cookies do — even when they are technically session cookies in the RFC sense. The legal line is drawn by purpose, not by lifetime.
• Third-party session cookies. Chrome's 2024 phase-out of third-party cookies killed the cross-site session cookie use case (federated login, ad attribution). First-party session cookies are untouched and remain core to web authentication.
• Session cookie length. Common in 2026: 128–256 bits of entropy (entropy here meaning how hard the value is to guess), base64 or URL-safe encoded. Shorter is brute-forceable; longer is wasteful. Always generated server-side from a CSPRNG (a cryptographically secure random generator), never from time or user data.