What is Cookie Bomb? Ways to Exploit, Examples and Impact

In the landscape of web security, most discussions revolve around data exfiltration, such as SQL injection or credential harvesting. However, there is a specific category of attacks designed not to steal data, but to deny service to legitimate users. One of the most intriguing yet often overlooked techniques in this category is the Cookie Bomb. A Cookie Bomb is a client-side Denial of Service (DoS) attack that leverages the way web browsers and servers handle HTTP cookies to render a website inaccessible to a specific user.

Understanding the Cookie Bomb requires a deep dive into the mechanics of HTTP headers, browser cookie storage limits, and server-side configurations. For beginners, it might seem like a harmless prank, but for technical professionals managing large-scale infrastructure, it represents a significant availability risk that can be difficult to debug without the right tools like Jsmon.

Understanding the Foundation: How HTTP Cookies Work

Before we can dissect the "bomb," we must understand the "fuse"—the HTTP cookie. Cookies are small pieces of data that a server sends to a user's web browser. The browser may store this data and send it back with later requests to the same server. Typically, cookies are used to tell if two requests came from the same browser—keeping a user logged in, for example.

When a server wants to set a cookie, it sends a Set-Cookie header in the HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; SameSite=Lax

The browser then includes this cookie in the Cookie header of every subsequent request to that domain:

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abc123xyz

Most modern browsers allow up to 4KB of data per individual cookie and roughly 50 to 180 cookies per domain. Crucially, web servers (like Apache, Nginx, or Node.js) have a maximum limit for the total size of all HTTP request headers. This limit is often set between 8KB and 16KB. If a request exceeds this limit, the server will reject the request with an error, typically an HTTP 431 (Request Header Fields Too Large) or HTTP 400 (Bad Request).

What is a Cookie Bomb Attack?

A Cookie Bomb attack occurs when an attacker finds a way to force a user's browser to store a massive number of cookies or cookies with very large values. Once these cookies are set, every subsequent request the user makes to the target domain will include these bloated headers. Because the total size of the Cookie header now exceeds the server's maximum allowed header size, the server will refuse to process any requests from that user, effectively locking them out of the site.

This is a "client-side" DoS because it doesn't crash the server for everyone; it only crashes the experience for the specific user who has been "bombed." However, if an attacker can automate this process across many users, or target administrators, the impact can be devastating.

The Technical Mechanism of the Attack

The core of the attack lies in JavaScript's ability to manipulate cookies via document.cookie. An attacker needs a way to execute a script in the context of the target domain. This is often achieved through a Cross-Site Scripting (XSS) vulnerability or by hosting a malicious script on a shared subdomain.

The Payload

A simple JavaScript payload to create a Cookie Bomb looks like this:

// Function to explode the cookie bomb
function triggerCookieBomb() {
    const cookieSize = 4000; // Aiming for just under the 4KB limit per cookie
    const longString = "A".repeat(cookieSize);
    
    // Loop to create multiple large cookies
    for (let i = 0; i < 20; i++) {
        document.cookie = `bomb_${i}=${longString}; Domain=.example.com; Path=/; Max-Age=31536000`;
    }
    console.log("Cookie bomb planted successfully.");
}

triggerCookieBomb();

In this example, the script generates 20 cookies, each approximately 4KB in size. This results in a total cookie payload of roughly 80KB. When the browser attempts to send a request to example.com, it will try to pack all 80KB into the HTTP headers. Since most servers cap headers at 8KB or 16KB, the server will instantly reject the request.

Common Ways to Exploit Cookie Bombs

There are several vectors an attacker might use to deliver a Cookie Bomb. Understanding these is vital for developers using tools like Jsmon to monitor their attack surface.

1. Reflected XSS Vector

If a website has a reflected XSS vulnerability, an attacker can craft a URL that, when clicked, executes the cookie-bombing script. The victim clicks a link, their browser sets the massive cookies, and suddenly they can no longer access the site.

2. Subdomain-Based Attacks

This is perhaps the most common and dangerous vector. Cookies set on a subdomain can be configured to be sent to the base domain and all other subdomains. If an organization allows users to host content on subdomains (e.g., user-content.example.com), a malicious user can host a script that sets cookies for the entire .example.com domain.

document.cookie = "malicious=data; Domain=.example.com; Path=/";

Because the Domain attribute starts with a dot, the browser will send this cookie to api.example.com, dashboard.example.com, and the main www.example.com site.

3. Log-out or Profile Pages

Sometimes, applications have features that reflect user input into a cookie without proper length validation. For example, a "language preference" feature might take a string from a URL parameter and save it as a cookie. An attacker could provide a massive string in that parameter, causing the application to "bomb" itself.

Real-World Impact and HTTP Status Codes

When a Cookie Bomb is successful, the user is met with a cryptic error page. The specific HTTP status code depends on the server software:

• HTTP 431 Request Header Fields Too Large: This is the most accurate response and is commonly seen in Node.js and modern Nginx/Apache configurations.
• HTTP 400 Bad Request: Some older servers or load balancers use this generic error when headers are malformed or too long.
• HTTP 413 Payload Too Large: While usually reserved for the request body (POST data), some misconfigured proxies might return this for large headers.

The impact is a total loss of availability for the victim. For an e-commerce site, this means a lost customer. For an internal corporate tool, it means a locked-out employee. Because cookies persist in the browser, the "attack" remains active until the cookies expire or the user manually clears their browser cache—something many non-technical users don't know how to do.

How to Detect Cookie Bomb Vulnerabilities

Detection requires looking at both the client-side behavior and server-side logs.

Client-Side Inspection

If you suspect a Cookie Bomb, open your browser's Developer Tools (F12), go to the "Application" tab, and look at the "Cookies" section. If you see dozens of cookies with long, repetitive strings of characters, you are likely looking at a Cookie Bomb.

Server-Side Monitoring

Monitor your server logs for a spike in 431 or 400 error codes. If a specific IP address is suddenly receiving 431 errors for every request, it's a strong indicator that their Cookie header has been bloated. Infrastructure monitoring platforms like Jsmon can help identify exposed subdomains that might be used as staging grounds for these attacks.

Prevention and Mitigation Strategies

Preventing Cookie Bombs involves a combination of strict input validation and smart infrastructure configuration.

1. Set Strict Cookie Limits

On the server side, you should validate the length of any data you are about to place into a Set-Cookie header. If a user tries to set a "theme" preference that is 5,000 characters long, reject it.

2. Use the __Host- Prefix

To prevent subdomain-based cookie tossing, use the __Host- prefix for sensitive cookies. Cookies with this prefix are restricted to the domain that set them and cannot be overwritten by subdomains.

Set-Cookie: __Host-session=123; Secure; Path=/

3. Configure Server Header Limits Wisely

While it might be tempting to simply increase the server's header limit to 64KB to "fix" the issue, this actually makes you more vulnerable to other types of DoS attacks (like Slowloris). Keep header limits at a reasonable level (8KB-16KB) and focus on preventing the cookies from being set in the first place.

4. Implement a Client-Side "Clearance" Script

If you detect a 431 error, you can potentially serve a custom error page that includes a small piece of JavaScript to clear all cookies for your domain. This allows the user to "self-heal" by simply refreshing the page.

// Simple script to clear cookies
function clearAllCookies() {
    const cookies = document.cookie.split(";");
    for (let i = 0; i < cookies.length; i++) {
        const cookie = cookies[i];
        const eqPos = cookie.indexOf("=");
        const name = eqPos > -1 ? cookie.substr(0, eqPos) : cookie;
        document.cookie = name + "=;expires=Thu, 01 Jan 1970 00:00:00 GMT;path=/;domain=.example.com";
    }
    location.reload();
}

Conclusion

The Cookie Bomb is a clever exploitation of the trust relationship between the browser and the server. While it doesn't result in data theft, its ability to disrupt services and lock out users makes it a credible threat. By understanding how cookies propagate across subdomains and how servers enforce header limits, developers can build more resilient applications.

Proactive monitoring of your external assets is the best defense against these types of vulnerabilities. To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.