Cybersecurity glossary
What is a Cookie Bomb?
Learn what a cookie bomb is, how oversized or numerous cookies can deny service or break proxies, which application flaws enable it, and how to limit Cookie header size safely.
Definition
A cookie bomb is an attack or failure mode in which an attacker causes a browser to store excessively large or numerous cookies for a site so that subsequent requests become too large for servers, proxies, or application parsers—often resulting in errors, lockouts, or denial of service for the victim.
Why cookie bombs matter
Every authenticated request may carry a Cookie header. If that header grows past infrastructure limits, the user cannot load pages, log in, or log out cleanly. A cookie bomb turns cookie storage into a denial-of-service primitive against a specific victim—or against fragile parsers shared by many users.
These bugs often hide in “harmless” preference cookies, tracking experiments, or debug endpoints that echo input into Set-Cookie.
How a cookie bomb unfolds
Find an unbounded Set-Cookie sink
An endpoint sets cookies from query params, headers, or other attacker-influenced input without size checks.
Fill the victim’s cookie jar
Large values, many names, or repeated sets push stored cookies toward practical limits.
Victim browses normally
The browser attaches the oversized Cookie header on subsequent requests.
Infrastructure rejects the request
CDN, proxy, or app returns 431/400 or drops the connection.
User appears locked out
Recovery may require manually clearing cookies for the site.
Impact patterns
Per-user lockout
Only the bombed browser profile fails, which can look like intermittent customer support mysteries.
Support and trust damage
Users blame the product for “broken login” after a single malicious visit.
Security control bypass attempts
Some designs fail open or skip checks when Cookie parsing throws.
Cross-subdomain amplification
Broad Domain cookies let one weak host bomb many applications.
Limits that collide
| Layer | Typical issue |
|---|---|
| Browser | Per-cookie and per-domain storage caps still allow large Cookie headers |
| Reverse proxy / CDN | Header size limits trigger 431 before the app runs |
| Application server | Parser memory pressure or hard request failures |
| Shared Domain apps | One product’s cookies inflate requests to siblings |
Prevention checklist
- Never write unbounded user input directly into Set-Cookie values.
- Enforce maximum cookie value length and total Set-Cookie budget per response.
- Prefer server-side session storage over stuffing state into cookies.
- Avoid Domain=.parent for cookies that are not strictly required everywhere.
- Return clear recovery guidance on 431 pages (clear site cookies / retry).
- Rate-limit endpoints capable of setting novel cookie names.
- Monitor 431 rates by path as an abuse signal.
- Review related-host cookie tossing paths that can mass-plant cookies.
The practical takeaway
A cookie bomb abuses oversized or excessive cookies so legitimate requests become too large to process. Victims can be effectively locked out until cookies are cleared.
Keep cookies small, few, and tightly scoped—and treat any endpoint that sets cookies from untrusted input as a denial-of-service footgun.
Related security terms
Cookie
HTTP cookie fundamentals that cookie bombs abuse through size and count.
Cookie Tossing
Related technique that can plant many cookies from related hosts.
Rate Limiting
Complementary control for abusive Set-Cookie or account flows.
HTTP Status Code
Includes 431 responses commonly seen when headers grow too large.
Frequently asked questions
What is a cookie bomb in simple terms?
It is when so many or such large cookies are stored for a site that normal requests stop working because the Cookie header is enormous.
Who is affected by a cookie bomb?
Usually the victim user (or browser profile) whose jar was filled. In some designs, shared caches or backends can also degrade.
How do attackers create cookie bombs?
By abusing endpoints that reflect input into Set-Cookie, by tossing many cookies from a related subdomain, or by tricking users into visiting pages that set huge cookies.
What HTTP status appears?
Servers and reverse proxies often respond with 431 Request Header Fields Too Large or 400 Bad Request when headers exceed limits.
Can a cookie bomb lock a user out?
Yes. Every request may fail until the user clears site cookies, which can look like a permanent outage for that person.
How do you prevent cookie bombs?
Cap Set-Cookie sizes, avoid writing unbounded user input into cookies, limit cookie count, reject oversized Cookie headers gracefully, and avoid shared Domain that lets one host flood another.
Are browser cookie limits enough protection?
Browsers enforce per-cookie and per-domain limits, but those limits can still exceed what your reverse proxy or app server accepts.
References
Explore authoritative guidance and frameworks related to cookie bomb.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.