Beyond the Bug Bounty: Practical DoS Exploitation for High-Impact Findings

TLDR: Denial of Service is often dismissed as low-impact, but when targeted at specific business logic, it can cripple entire production environments. This post breaks down how to weaponize N+1 query patterns, client-side crashes, and cache poisoning to turn "informative" bugs into high-severity findings. We also cover a new Burp Suite extension designed to automate the discovery of these high-latency bottlenecks.

Most bug bounty programs treat Denial of Service as a second-class citizen. It is the "out of scope" default, usually because programs fear researchers will just run a script to flood their load balancers. But there is a massive difference between a blunt-force volumetric attack and a surgical strike against business logic. If you can force a backend to hang or crash by sending a single, well-crafted request, you have found a vulnerability that matters.

Weaponizing the N+1 Query Problem

The N+1 query problem is a classic database anti-pattern, but it is also a goldmine for researchers. It happens when an application executes one initial query to fetch a list of items, followed by N additional queries to fetch details for each item. In a development environment with ten records, this is invisible. In a production environment with ten thousand records, it is a disaster.

To find these, look for endpoints that return lists of objects—users, posts, or transactions—and check if the API supports pagination. If you see a limit or page_size parameter, push it to the extreme. If the response time scales linearly with the number of items requested, you have found a potential DoS vector.

The goal is to trigger enough database calls to exhaust the connection pool or lock up the application thread. During a test, you can use the Burp Suite Intruder to send concurrent requests with null payloads. If the backend starts timing out or returning 500 errors, you have demonstrated a clear business impact.

Client-Side Crashes and Malformed Data

Sometimes the vulnerability isn't in the database, but in how the frontend handles malformed data returned by the server. We have seen cases where sending a specific, malformed JSON payload—like one containing escaped characters or invalid syntax—causes the frontend to crash during the parsing phase.

This is particularly effective when the backend validates the data but the frontend does not. If you can force a user's browser or a mobile app to crash every time they load a specific page, you have effectively denied service to your target. This is a great way to demonstrate impact on OWASP Injection vulnerabilities where the input is reflected in a way that breaks the client-side parser.

Cache Poisoning: The Silent Service Killer

Cache Poisoning Denial of Service (CPDoS) is arguably the most dangerous of these techniques because it is persistent. By manipulating headers or input parameters, you can trick a caching layer—like a CDN or a reverse proxy—into caching an error page or a blank response for a legitimate resource.

The methodology is straightforward:

1. Identify how the cache key is constructed.
2. Find an input that causes the backend to return an error (like a 404 or 500).
3. Ensure that the error response is cached by the intermediary.

Once the error page is cached, every subsequent user who requests that resource will receive the cached error instead of the actual content. This can take down a site without ever touching the origin server again. For those interested in the mechanics of these attacks, the PortSwigger research on CPDoS remains the gold standard for understanding how these systems fail.

Automating Discovery with TryDoS

Finding these bottlenecks manually is tedious. To speed up the process, we developed TryDoS, a Burp Suite extension that monitors your traffic and flags any request that exceeds a specific latency threshold. By setting a threshold—we recommend three seconds—you can passively identify endpoints that are struggling under load while you perform other testing. It provides an immediate, visual alert, allowing you to pivot from standard testing to targeted DoS research the moment you see a performance dip.

Defensive Considerations

Defending against these attacks requires a shift in how you view performance. Rate limiting is a start, but it is not a silver bullet. You must implement strict input validation on all API endpoints to prevent malformed data from reaching the frontend. For database-heavy applications, use tools to monitor query performance and identify N+1 patterns before they reach production. Finally, ensure your cache configuration is robust, specifically by validating that error pages are never cached by your CDN.

The next time you are on an engagement, do not ignore the slow endpoints. They are not just "poorly optimized"—they are often the most fragile parts of the infrastructure. A little bit of pressure in the right place can reveal a lot about how a system handles stress. Keep digging, keep testing, and always make sure you have explicit permission before you start pushing the limits of a production environment.