What is an Application-Layer DDoS Attack?

What is an application-layer DDoS attack?

An application-layer DDoS attack, also called a Layer 7 or L7 attack, floods a web application or API with requests that look like normal users. Instead of filling the network pipe, it exhausts what the app needs to answer: worker threads, CPU, database connections and memory. Each request is small, so traffic volume alone barely shows the attack.

It is the quiet cousin of volumetric attacks, which saturate bandwidth at Layer 3 and 4. See the DDoS overview for the wider picture and the HTTP flood entry for the most common L7 form.

How application-layer attacks work

The attacker controls a botnet of compromised devices or rented cloud machines. Each bot sends requests that are cheap to send and expensive to answer. Common patterns:

• HTTP flood: a high rate of GET or POST requests to costly endpoints such as search, login or a dynamic homepage.
• Slowloris: many connections opened and kept alive by sending request headers very slowly, until the server has no free connection slots.
• RUDY (R-U-Dead-Yet): the same idea for POST bodies, sent a few bytes at a time.
• Cache busting: a unique query string on every request (?x=8841) so a CDN cannot answer from cache and every request reaches your origin.
• API abuse: repeated calls to expensive endpoints such as reports, exports or aggregations that no real user would call that often.

Example: a search endpoint

Say /search?q=... runs an uncached database query that takes 200 ms, and your app has 20 workers. That is roughly 100 searches per second at best (illustrative numbers). A botnet that sends 150 searches per second never touches your bandwidth limit, yet the worker pool is full, the queue grows, and real visitors see timeouts and 503 errors. The traffic chart looks unremarkable; the latency chart does not.

Why Layer 7 is harder to defend than Layer 3/4

• Every request is valid. Nothing malformed, nothing to drop at the network edge.
• Bots look like browsers. Realistic user-agent strings make UA blocking weak.
• The sources are spread out. Botnets use many addresses, so blocking IPs one by one is whack-a-mole.
• Normal depends on your app. You need to know your usual request rate per session and per endpoint to spot abnormal.

How to defend against it

• Rate limit at the edge and in the app. A web application firewall (WAF) can limit per IP, session and endpoint. Keep an app-level limit too, in case traffic bypasses the edge. Answer with 429 Too Many Requests and a Retry-After header. The API rate limiting guide covers the causes and fixes.
• Challenge suspicious clients. A CAPTCHA or JavaScript challenge filters simple bots before they reach expensive code.
• Cache what you can. Cache anonymous GET responses and keep cookies out of the cache key for pages that are not personalised.
• Make costly endpoints cheaper. Add indexes, pagination limits and timeouts so one request cannot hold a worker for long.
• Watch latency, not only traffic. Alert on p95 latency, error rate and worker saturation. The full checklist is in how to stop DDoS attacks.

Common mistakes

• Relying on IP blocking alone against a distributed botnet.
• Rate limiting only the login page and leaving search, export and API routes open.
• Rate limiting behind a proxy or CDN on the proxy's address instead of the real client address, so everyone shares one bucket.
• No baseline of normal traffic, so nobody can say what abnormal looks like.
• Assuming the CDN absorbs everything while uncacheable endpoints hit the origin directly.

How load testing and monitoring fit in

A load test is not a DDoS simulation, and LoadFocus does not simulate DDoS attacks. What a load test does is show how your own application behaves at a traffic level you choose, from known cloud regions, and only against systems you are authorised to test. That is useful defensively: you learn how many requests per second your costly endpoints survive and whether your rate limits answer with 429 instead of timeouts. Read load testing vs stress testing for how to plan that, then run it with LoadFocus load testing. Pair it with API monitoring so slow or failing endpoints raise an alert (free checks run every 5 minutes).

FAQ: Application-layer DDoS

How big does an L7 attack have to be?

Smaller than most people expect. The limit is how much work your app does per request, not bandwidth. An endpoint that needs a heavy database query can be exhausted by a modest request rate.

What is the difference between an L7 DDoS and an HTTP flood?

An HTTP flood is one kind of L7 DDoS and the most common. Slowloris, RUDY, cache busting and API abuse are other kinds at the same layer.

Does a CDN stop application-layer attacks?

It helps with cacheable pages and often includes rate limiting and bot rules. It does not help with uncacheable requests such as logins, searches or API calls, which still reach your origin unless they are rate limited.

Should I rate limit by IP, by session, or both?

Both. IP limits catch simple bots. Session or account limits catch distributed attacks where each address sends only a few requests.

How do I tell an attack from a traffic spike?

Compare against your baseline: which endpoints are hit, from which regions, with which user agents, and how errors behave. Attacks tend to be uniform (same paths, same user agent), while real spikes are varied and follow a cause such as a campaign or a launch.