What Is a Session Cookie?

Paste into ChatGPT, Claude, or any LLM

On this page

A session cookie is an HTTP cookie that has no Max-Age or Expires attribute, so the browser stores it only in memory and deletes it when the browsing session ends. Defined in RFC 6265, it is the simplest form of HTTP state management — a small piece of data the server sets via the Set-Cookie header and the browser returns on every subsequent request in the same session. Also called an in-memory cookie, transient cookie, or non-persistent cookie. Login state, shopping carts, and most anti-bot trust tokens (_abck, cf_clearance, datadome, reese84) are session cookies.

Defining attribute	Absence of Max-Age and Expires in Set-Cookie
Storage	Browser RAM — not written to disk in most browsers
Lifetime	Until the browsing session ends (browser-defined)
Standard	RFC 6265 (HTTP State Management Mechanism, 2011)
Also known as	In-memory cookie, transient cookie, non-persistent cookie

How session cookies work

A server sets a session cookie by sending a Set-Cookie response header with no Max-Age and no Expires attribute:

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

The browser stores this cookie in memory (not on disk) and includes it in the Cookie header of every subsequent request to the same origin within the same session:

GET /account HTTP/1.1
Cookie: sessionId=abc123

When the user closes the browser, the cookie is gone. The next time they visit, the server treats them as a new visitor because there is no sessionId to identify them.

By default, per RFC 6265, the cookie is returned only to the origin server (not subdomains) unless the Domain attribute explicitly broadens the scope. The Path attribute can further narrow which URLs receive the cookie.

Session cookie vs persistent cookie

The difference is entirely about lifetime, controlled by two attributes on Set-Cookie:

Cookie type	Has `Expires` or `Max-Age`?	Stored where	Survives browser restart?
Session	No	RAM	No (usually)
Persistent	Yes	Disk	Yes, until expiration

Persistent cookies survive browser restarts and are deleted only when the Max-Age expires, the Expires date passes, or the user clears them manually. A "remember me" checkbox on a login form converts a session cookie into a persistent one by adding an expiry weeks or months out.

Caveat: modern browsers blur this line with session restoration. Chrome, Firefox, and Safari can preserve session cookies across restarts if the user has "continue where you left off" enabled. From the server's perspective the cookie is still a session cookie; from the user's perspective it might survive a reboot. RFC 6265 explicitly leaves the definition of "session ends" to the user agent.

The five attributes that change behaviour

Even without Expires/Max-Age, a Set-Cookie header carries several attributes that materially change how the session cookie behaves:

HttpOnly — the cookie is not accessible to JavaScript via document.cookie. Critical for session cookies because it neutralises XSS attacks that try to steal session IDs. If your session cookie is missing this flag, that is a security bug.
Secure — the cookie is sent only over HTTPS connections, never over plain HTTP. Should be set on every modern session cookie.
SameSite=Lax | Strict | None — controls cross-site request behaviour. Lax (the modern default) sends the cookie on top-level navigations but not on cross-site sub-requests like <img> or XHR. Strict blocks all cross-site requests. None requires Secure and allows full cross-site sending — used by embedded widgets and federated login. Most CSRF protection comes from SameSite=Lax.
Domain — broadens the cookie scope from origin-only to a parent domain (e.g. Domain=example.com makes the cookie visible to api.example.com, www.example.com, etc.). Without this, RFC 6265 restricts the cookie to the exact origin that set it.
Path — narrows the cookie to specific URL paths (e.g. Path=/account means the cookie is sent on /account/* but not /blog/*). Less commonly used.

A modern, well-configured session cookie looks like:

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

Session cookies in anti-bot systems

Almost every major anti-bot vendor encodes session-level trust as a session cookie. The cookie itself is the visible evidence that the client has passed (or is being scored against) the vendor's detection model. Examples:

_abck — Akamai Bot Manager. State starts at ~-1~ (untrusted) and flips to ~0~ only after sensor.js POSTs valid signals. Trust accumulates across the session.
cf_clearance — Cloudflare. Indicates the client has solved a JavaScript challenge or Turnstile interaction.
datadome — DataDome. Per-request scored, but the cookie marks sessions previously seen and lightly trusted.
reese84 — F5 Shape Security. Validated session token from the custom JS VM; expires in minutes.
_px3 / _pxde — PerimeterX / HUMAN Security. Carries the 5-vector fingerprint score.
x-kpsdk-ct — Kasada. Single-use proof-of-work token, not reusable across requests.

All of these are session cookies by RFC 6265's definition — no Expires or Max-Age, lifetime bounded by the browser session. That has practical implications for scrapers: rotating proxies mid-session invalidates the trust accumulated in these cookies, which is why ISP static residential IPs are preferred over rotating residential for Akamai targets.

The lesson: when an anti-bot vendor talks about "session-level scoring", they almost always mean a session cookie they control. Understanding which cookie they set, what its expected state values are, and when the state flips is half the work of bypassing the vendor.

Security and privacy considerations

Session fixation. If an attacker can set a session cookie value (via a subdomain takeover, network MITM, or a permissive Domain attribute), they can hijack a victim's session after the victim authenticates. Defence: regenerate the session ID on every privilege boundary (login, role change), and always set HttpOnly + Secure + SameSite=Lax.
Session hijacking via XSS. Without HttpOnly, JavaScript can read document.cookie and exfiltrate the session ID via an attacker-controlled URL. The HttpOnly flag is the single most important hardening for session cookies; it should be on every session cookie by default.
GDPR and consent. Strictly necessary session cookies (login, shopping cart, CSRF tokens) do not require consent under GDPR. Analytics and tracking cookies do — even if they are technically session cookies in the RFC sense. The legal distinction is purpose, not lifetime.
Third-party session cookies. Chrome's 2024 phase-out of third-party cookies removed the cross-site session cookie use case (federated login, ad attribution). First-party session cookies are unaffected and remain core to web authentication.
Session cookie length. Common in 2026: 128–256 bits of entropy, base64 or URL-safe encoded. Shorter than that is brute-forceable; longer is wasteful. Generated server-side from a CSPRNG, never from time or user data.

Code example

python

# How session cookies behave in scraping — preserve them across requests
from curl_cffi import requests

# 1. Use a Session — cookies persist across .get() / .post() calls
s = requests.Session(impersonate="chrome131")

# 2. Warm-up request: server sets the session cookie
r1 = s.get(
    "https://target.example.com/",
    proxies={"https": "http://user:pass@isp-residential:port"},
)
# Inspect what was set — anti-bot vendors usually mark their cookie here
for name in s.cookies.keys():
    if name in ("_abck", "cf_clearance", "datadome", "reese84", "_px3"):
        print(f"Anti-bot session cookie set: {name}")

# 3. Subsequent request — Session re-sends the cookie automatically
r2 = s.get(
    "https://target.example.com/api/protected",
    proxies={"https": "http://user:pass@isp-residential:port"},
)
# Same Session, same IP, same cookies — trust accumulates on multi-request
# scored vendors like Akamai.

# 4. To clear and start a new session: instantiate a new Session().
# Closing the Python process is the HTTP equivalent of closing the browser.

Related terms

What Is Akamai Bot Manager?

Akamai Bot Manager is an enterprise bot-protection product used by roughly 30% of the Fortune 500 — airlines, banks, retailers, ticketing. I…

What Is DataDome?

DataDome is a bot-protection vendor used on roughly 1,200 enterprise sites, scoring more than 5 trillion signals per day. Unlike Cloudflare …

What Is PerimeterX (HUMAN)?

PerimeterX, now operating as part of HUMAN Security, is a bot-protection vendor whose biggest asset is its network. It protects 29,650+ site…

What Is an ISP Proxy?

An ISP proxy (also called a "static residential" proxy) is a static IP hosted in a datacenter but announced under a consumer ISP's autonomou…

What Is Stateful Web Scraping?

Stateful web scraping preserves cookies, session tokens, browser fingerprint, and proxy IP across multiple requests so the target site sees …

What Is Favicon Fingerprinting (Supercookies)?

Favicon fingerprinting (the “Supercookie” technique) abuses the browser’s separate, long-lived favicon cache to store a persistent identifie…

What Is Imperva Incapsula?

Imperva Incapsula is the enterprise WAF and bot-protection product from Imperva (acquired by Thales in 2023). It is heavily deployed across …

Concept map

How Session Cookie connects

The terms most directly tied to this one. Hover a node to see its neighbours, click to preview, drag to rearrange.

0 terms · 0 connections

You are here · Anti-Bot

Tools & solutions for this topic

Frequently asked questions

How long does a session cookie last?

Until the browsing session ends, which the browser defines. In practice that usually means until the browser is closed — but modern browsers with "session restoration" enabled can preserve session cookies across restarts. RFC 6265 deliberately leaves the definition of "session ends" to the user agent, so the answer varies by browser, by configuration, and by whether the user actively closed the browser or just shut the laptop lid.

What is the difference between a session cookie and a persistent cookie?

A session cookie has no Max-Age or Expires attribute, so the browser stores it only in memory and deletes it at session end. A persistent cookie has one of those attributes, so the browser writes it to disk and keeps it until the specified expiration. The only difference is lifetime — the format, transmission, and behaviour on the network are identical.

Are session cookies safe?

Session cookies that include the HttpOnly, Secure, and SameSite=Lax attributes are the safe modern default. HttpOnly blocks JavaScript access (preventing XSS exfiltration). Secure ensures the cookie travels only over HTTPS. SameSite=Lax blocks most CSRF attacks. Without all three, a session cookie can be stolen via XSS, leaked over HTTP, or abused in cross-site request attacks.

Do I need cookie consent for session cookies under GDPR?

Only if they are not strictly necessary. Login cookies, shopping cart cookies, and CSRF tokens are strictly necessary and exempt from consent requirements under GDPR Article 5(3) of the ePrivacy Directive. Session cookies used for analytics, tracking, or advertising still require consent — the legal distinction is the purpose, not the technical lifetime.

Why do anti-bot vendors use session cookies?

Because the trust score they assign to a client builds up across multiple requests. Storing that score in a session cookie means it follows the client around the site without re-running the full fingerprint check on every request. _abck, cf_clearance, datadome, reese84, and _px3 are all session cookies precisely so they can carry session-bounded trust without persisting beyond it.

Can I read a session cookie from JavaScript?

Only if it does not have the HttpOnly flag. Cookies with HttpOnly are invisible to document.cookie and any client-side script — they exist only at the HTTP protocol layer. This is by design, to protect session IDs from XSS-based exfiltration. If you control the server and want a session ID, set HttpOnly and read it server-side; never trust client-side JavaScript to handle authentication tokens.

What happens to my session cookie if I clear browser cookies?

It is deleted immediately, just like any other cookie. The next request to that site arrives without a session cookie, so the server treats you as a fresh visitor — you are logged out, your cart is empty, and any session-scoped state is gone. This is the user-side equivalent of restarting the server-side session, with the same effect.

Last updated: 2026-05-26