Cookie Security Cheat Sheet

Audit and attack HTTP cookies: HttpOnly/Secure/SameSite flags, domain/path scoping, __Host-/__Secure- prefixes, session fixation, cookie injection & tossing, and jar overflow eviction. (35 payloads)

Try it interactively with the HTTP Request Parser

Cookie Flags & Attributes

(7)

Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax; Path=/

Baseline secure session cookie. HttpOnly blocks JS access, Secure restricts to HTTPS, SameSite=Lax stops most cross-site sends. Treat any missing attribute as a finding.the secure default

Missing HttpOnly on session cookie

Without HttpOnly the cookie is readable via document.cookie, so any XSS becomes full session theft. Verdict: confirm with `console.log(document.cookie)` in the page context.XSS impact amplifier

Missing Secure flag

A cookie without Secure is transmitted over plain HTTP, exposing it to network sniffing and active MITM (sslstrip). Critical for any auth cookie.transport exposure

SameSite=None; Secure (cross-site send enabled)

Cookie is attached on cross-site requests. If the endpoint mutates state and lacks a CSRF token, this re-opens classic CSRF. Browsers reject SameSite=None without Secure.CSRF reachability

Set-Cookie with no SameSite (browser default = Lax)

Modern Chromium/Firefox default unset cookies to Lax, but top-level GET navigations still send them — exploitable for CSRF on state-changing GET handlers and during the 2-minute Lax+POST grace window.implicit-default trap

Expires/Max-Age far in the future on auth cookie

Long-lived session cookies widen the window for a stolen token. Session cookies (no Max-Age) die on browser close; persistent ones survive — flag overly long lifetimes.token-lifetime review

SameSite=Strict on the session, separate Lax read cookie

Strict breaks inbound links (you arrive logged out). A common pattern is a Strict session + a Lax 'logged-in' hint cookie; review the hint cookie for over-trust.Strict usability tradeoff

Cookie Prefixes & Hardening

(6)

Set-Cookie: __Host-sid=...; Secure; Path=/

The __Host- prefix is browser-enforced: requires Secure, Path=/, and forbids a Domain attribute. Browsers reject any Set-Cookie that violates these, defeating subdomain tossing and path scoping tricks.strongest cookie binding

Set-Cookie: __Secure-sid=...; Secure; Domain=example.com

The __Secure- prefix requires the Secure flag but still allows Domain. Weaker than __Host- because it can be set by/shared with subdomains, so it does NOT stop tossing.weaker prefix

Strip a __Host- cookie's Secure flag and replay

Test that the server/browser actually enforces the prefix invariants — a non-compliant Set-Cookie (e.g. __Host- with Domain set) must be silently dropped by the client.prefix enforcement check

Set-Cookie: sid=...; Path=/admin (path scoping)

Path is NOT a security boundary — same-origin pages on other paths can read it via document.cookie, and an iframe to /admin/x leaks it. Never rely on Path for isolation.path is not a boundary

Compare cookie set on HTTPS vs accessible on HTTP

Even with Secure set, a misconfigured app or downgrade can echo cookies in error pages or logs. Verify the cookie never appears in any HTTP response or referer.leakage audit

Partitioned (CHIPS): Set-Cookie: id=...; Secure; SameSite=None; Partitioned

CHIPS binds a cross-site cookie to the top-level site that loaded it, so a third-party tracker can't link a user across sites. Absence on embedded third-party cookies is a privacy/tracking finding.third-party isolation

Cookie Scoping & Domain Abuse

(6)

Set-Cookie: id=...; Domain=.example.com

A leading-dot / parent-domain cookie is sent to every subdomain. A single vulnerable or takeover-able subdomain (e.g. blog.example.com) can read or overwrite the parent's session cookie.overly broad scope

Host-only cookie (no Domain attribute)

When Domain is omitted the cookie is host-only and sent ONLY to the exact host that set it — the safer choice. Confirm sensitive cookies are host-only unless cross-subdomain auth is truly required.least-privilege scope

Set cookie on example.com from sub.example.com

A subdomain can set a cookie scoped to the parent (Domain=example.com) but NOT to an unrelated sibling's host-only scope. Use this to assess blast radius of a compromised subdomain.upward scoping rule

Attempt Domain=com / Domain=co.uk (public suffix)

Browsers block cookies scoped to entries on the Public Suffix List (eTLD), preventing 'supercookies' across all .com or .co.uk sites. Verify the browser rejects such Set-Cookie headers.PSL / supercookie defense

Shared cookie between app.example.com and login.example.com

SSO-style shared parent-domain cookies mean a flaw in any sibling app exposes the session everywhere. Map every host that can read the auth cookie and treat them as one trust zone.trust-zone mapping

host:1.example.com vs 2.example.com cookie isolation

Ports do NOT scope cookies (example.com:80 and :8443 share them) and host-only cookies don't cross siblings — verify multi-tenant subdomains can't read each other's cookies.isolation verification

Session Fixation

(5)

Capture sid pre-login, authenticate, compare sid

The session identifier MUST be regenerated on privilege change (login). If the pre-auth and post-auth values match, an attacker who planted the ID rides the authenticated session.core fixation test

https://app.example.com/?sessionid=KNOWN

Apps that accept a session ID from the URL/query let an attacker fix it via a crafted link. The app should ignore non-cookie session sources entirely.URL-based fixation delivery

document.cookie='sid=KNOWN' from XSS on a subdomain

Plant a known session value in the victim's browser before they log in. After they authenticate on the same value, replay it from your machine.XSS-assisted fixation

Test fixation after step-up / re-auth, not just login

ID rotation is also required after MFA completion, password change, and role elevation. A session that keeps its ID through step-up is still fixable.privilege-boundary rotation

Set a second cookie that shadows the real session

Combine fixation with cookie tossing: set a duplicate-name cookie at a different scope so the server/browser picks the attacker's value (see scope precedence below).fixation via tossing

Cookie Injection & Tossing

(6)

document.cookie='session=evil; domain=.example.com; path=/'

Cookie tossing: from a sibling or takeover-able subdomain, write a parent-domain cookie to overwrite or shadow the victim's. Browsers send duplicate-name cookies without origin info, so the server may trust the wrong one.subdomain trust abuse

Set duplicate-name cookie at more specific Path to win precedence

RFC 6265 orders cookies by longest path first; a tossed cookie with Path=/checkout precedes Path=/. The server reading the first Cookie value gets the attacker's value.scope precedence trick

Inject via header: param=val%0D%0ASet-Cookie:%20admin=1

If user input is reflected into a Set-Cookie response header without sanitization, CRLF injection forges arbitrary cookies (CR=%0D, LF=%0A). Test redirect/location and language/theme handlers.CRLF cookie injection

name=val; injected=value (semicolon/comma in cookie value)

Unescaped ; , space or = in a reflected cookie value can split it into multiple cookies or attributes — smuggle extra name/value pairs or flags the server later parses.value delimiter injection

__Host- prefix to block tossing

Remediation/verification: a __Host- cookie can only be set host-only over HTTPS with no Domain, so a subdomain cannot toss a competing parent-scoped value. Confirm the app uses it for the session.the hardening fix

Compare server parsing of multiple same-name cookies

Different stacks pick first/last/concatenated when a name repeats. Send `sid=good; sid=evil` and observe which the app honors — inconsistency enables shadowing and WAF/auth bypass.parser ambiguity probe

Cookie Jar Overflow & Eviction

(5)

Set 180+ junk cookies for a domain to evict the real one

Browsers cap cookies per domain (~180 in Chrome, ~150 in Firefox). From a subdomain, flood the jar so the legitimate parent cookie is evicted (oldest/LRU), forcing re-auth or a security downgrade.per-domain cap abuse

Evict a __Host-CSRF token, leaving a stale tossed one

Jar overflow + tossing: push out the real CSRF/double-submit cookie, then the only remaining value is your planted one — the server's double-submit check now compares your value to your value.double-submit defeat

Exceed the ~4KB per-cookie size limit

A cookie over 4096 bytes (name+value+attributes) is dropped. Bloating a victim's request with junk can also trigger 400/431 'Request Header Fields Too Large', a cookie-bomb DoS.size-limit DoS

Overflow then observe whether the session falls back insecurely

After eviction, check if the app re-issues a guessable session, downgrades to URL-based sessions, or treats the user as a fresh anonymous session with elevated trust.fallback-behavior test

Cookie bomb across shared subdomain to break victim's site

Persistent oversized/overflow cookies on a parent domain are resent on every request, causing 400/413/431 until cleared — a targeted denial of service that survives reloads.persistent DoS

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

CSRF Cheat Sheet JWT Attacks Cheat Sheet CORS Misconfiguration Cheat Sheet Session & Cookie Attacks Cheat Sheet

Frequently asked questions

What is the Cookie Security Cheat Sheet?+

It's a quick-reference collection of 35 Cookie Security payloads for testing Cookie Security vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these Cookie Security payloads?+

Copy any payload straight into your authorized test, or use the HTTP Request Parser to apply them interactively. Only test systems you have explicit permission to assess.

Are these Cookie Security payloads free to use?+

Yes — this cheat sheet and all Cookie Security payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the Cookie Security Cheat Sheet?+

How do I use these Cookie Security payloads?+

Copy any payload straight into your authorized test, or use the HTTP Request Parser to apply them interactively. Only test systems you have explicit permission to assess.

Are these Cookie Security payloads free to use?+

Yes — this cheat sheet and all Cookie Security payloads are completely free, with no account required. Everything runs in your browser.

Cookie Security Cheat Sheet

Cookie Flags & Attributes

Cookie Prefixes & Hardening

Cookie Scoping & Domain Abuse

Session Fixation

Cookie Injection & Tossing

Cookie Jar Overflow & Eviction

Related Tools

Related Cheat Sheets

Frequently asked questions

Cookie Security Cheat Sheet

Cookie Flags & Attributes

Cookie Prefixes & Hardening

Cookie Scoping & Domain Abuse

Session Fixation

Cookie Injection & Tossing

Cookie Jar Overflow & Eviction

Related Tools

Related Cheat Sheets

Frequently asked questions