Application-Layer Denial of Service (DoS) Guide

An application can be taken offline by a few hundred well-chosen requests that a network DDoS service never notices, because each one looks legitimate and the damage happens inside the code. Application-layer denial of service exploits work the application has to do: an expensive search, a deeply nested GraphQL query, a compressed upload that expands to gigabytes, a regular expression that backtracks for minutes, a connection held open byte by byte, or a paid SMS sent on every request. This guide explains how these attacks differ from volumetric DDoS, catalogues the main classes with the specific limits that stop each one, and gives a rollout plan, detection signals and metrics. It is for developers, architects and platform engineers who own web applications and APIs, and for the security teams who test them. Network-layer protection is covered in the DDoS Protection Guide.

Key takeaways

Asymmetry is the attack. Application DoS works when one cheap request makes the server do expensive work; the fix is to bound the work per request, not only the number of requests.
Every resource needs an explicit limit. OWASP API4:2023 lists the limits that are usually missing: execution timeouts, memory, file descriptors, processes, upload size, operations per request, records per page and third-party spending limits.
Validate cheaply first. Reject oversized, malformed and unauthenticated requests before any expensive parsing, decompression, database query or downstream call.
Edge rate limiting is necessary but not sufficient. It stops floods; it does not stop a single request that runs a regex for minutes or a query that scans a table.
Design to degrade, not to fall over. Bulkheads, queues, timeouts and circuit breakers keep one exhausted function from taking the whole service with it.

How application-layer DoS differs from network DDoS

The OWASP Denial of Service Cheat Sheet, following the CERT-EU classification, separates three attack surfaces: application attacks that exhaust resources or make functions unusable, session or protocol attacks that consume server or intermediary state (firewalls, load balancers), and network or volumetric attacks that saturate bandwidth. It stresses that application attacks "do not have to consume the network bandwidth to be effective".

Characteristic	Volumetric and protocol DDoS	Application-layer DoS
What is exhausted	Bandwidth, packet processing, connection tables	CPU, memory, threads, database connections, disk, paid third-party quota
Traffic volume	Very high	Can be low; sometimes one request
Request validity	Often malformed or spoofed	Well-formed, often authenticated
Where it is stopped	Upstream scrubbing, CDN, ISP, RTBH and Flowspec	In the application, the gateway and the data tier
Who owns the fix	Network and platform teams, providers	Developers and application owners
ATT&CK	T1498 Network Denial of Service	T1499.002 Service Exhaustion Flood, T1499.003 Application Exhaustion Flood, T1499.004 Application or System Exploitation

The two overlap in protocol attacks that target web servers. HTTP/2 Rapid Reset (CVE-2023-44487), added to the CISA Known Exploited Vulnerabilities catalog on 10 October 2023, abused request cancellation in the protocol itself; the fix was a server software patch and configuration, not more bandwidth.

Attack classes and the limits that stop them

Class	Mechanism	Primary control	Reference
Expensive queries	Search, filter, sort or export parameters that force full scans or huge result sets	Maximum page size, mandatory pagination, indexed filters only, query timeouts at the database	API4:2023; ASVS V2.4.1
GraphQL nesting and batching	Deep or wide queries, aliases and batched operations multiplying resolver work	Depth limit, amount limit, query cost analysis, persisted query allowlist, resolver timeouts	ASVS V4.3.1; OWASP GraphQL Cheat Sheet
Decompression and parser bombs	Small archives or documents that expand enormously (zip bombs, XML entity expansion such as the billion laughs attack)	Check uncompressed size and file count before extracting; disable DTDs and entity expansion	ASVS V5.2.3; CAPEC-197
Large uploads and bodies	Oversized files or request bodies filling memory or disk	Body size limit at the edge and in the framework; streaming uploads to bounded storage	ASVS V5.2.1
ReDoS	Backtracking regex engines taking exponential time on crafted input	Review patterns for nested or overlapping repetition, linear-time engines, input length limits, match timeouts	ASVS V1.3.12; CAPEC-492
Slow HTTP	Headers or bodies sent very slowly to hold connections open	Header and body read timeouts, minimum data rate, per-client connection limits	CAPEC-469; OWASP DoS Cheat Sheet
Costly side effects	Each request triggers SMS, email, voice, biometric checks or LLM calls billed per use	Per-user and per-flow quotas, provider spending caps, step-up challenges	API4:2023 scenario 1
Algorithmic complexity	Inputs that hit worst-case behaviour in sorting, hashing or image processing	Bound input sizes and dimensions, use hardened libraries, sandbox heavy processing	CAPEC-130
Security feature abuse	Deliberate failed logins to lock out real users	Progressive delays and risk-based challenges instead of hard lockout	OWASP DoS Cheat Sheet (user lockout)

Deeper treatment of individual classes lives in sibling guides: the Regular Expression Denial of Service Guide, the GraphQL Security Guide, the XXE Guide and the File Upload Security Guide.

Bounding the work per request

OWASP API4:2023 Unrestricted Resource Consumption says an API is vulnerable if at least one limit is missing or set inappropriately. Turning that list into concrete settings is most of the work.

Execution timeouts: set them at every layer, and make the inner timeout shorter than the outer one: database statement timeout, then resolver or handler timeout, then upstream proxy timeout. A gateway that gives up at 30 seconds while the database keeps running the query for five minutes has not protected anything.
Request size: cap bodies at the edge (nginx client_max_body_size defaults to 1 MB and returns 413 when exceeded) and again in the framework, with larger limits only on the routes that accept uploads.
Records per response: enforce a server-side maximum page size and ignore or reject client requests for more; use cursor pagination for exports.
Operations per request: limit GraphQL batch size and aliases, bulk API item counts and the number of IDs accepted in a single filter.
Decompression: ASVS V5.2.3 requires checking compressed files (zip, gz, docx, odt) against a maximum uncompressed size and maximum number of files before uncompressing. Count bytes as they are written rather than trusting the archive header, and apply the same rule to Content-Encoding: gzip request bodies.
Regular expressions: ASVS V1.3.12 requires regexes free of exponential backtracking. The OWASP ReDoS page describes the "evil" shape: a repeated group that contains another repetition, or an alternation whose options overlap. Where untrusted input is matched, prefer a linear-time engine (such as RE2-style engines), cap input length before matching, and never build a pattern from user input.
Process limits: container CPU and memory limits, worker counts, file descriptor limits and database connection pool sizes. ASVS V13.1.2 (Level 3) asks that each service's maximum concurrent connections and behaviour at that limit are documented.
Spending limits: set hard caps with SMS, email, voice and AI providers, and per-user quotas inside the application, so abuse costs a capped amount rather than an open-ended bill. See the Denial-of-Wallet and AI Agent Cost Runaway Guide.

Rate limiting, timeouts and connection controls

Rate limiting caps how often a client can ask; the controls above cap what each ask costs. Both are needed. The OWASP DoS Cheat Sheet's network-side list applies at the reverse proxy: a minimum ingress data rate with request-read timeouts against slow HTTP, an absolute connection timeout, a maximum ingress rate, a total bandwidth limit and a load limit on concurrent users per resource.

Concern	nginx directive (default)	Effect
Request rate per key	`limit_req_zone` and `limit_req` with `burst`; `limit_req_status` (503)	Leaky-bucket limiting per client address, API key or user; set the status to 429 for APIs
Safe rollout	`limit_req_dry_run` (off)	Counts would-be rejections without enforcing them
Slow headers	`client_header_timeout` (60s)	Ends the request with 408 if headers do not arrive in time
Slow bodies	`client_body_timeout` (60s)	Timeout between two successive reads, so tune it with a body size limit
Body size	`client_max_body_size` (1m)	Returns 413 above the limit
Header size	`large_client_header_buffers` (4 8k)	Returns 414 or 400 for oversize request lines and headers
Idle connections	`keepalive_timeout` (75s)	Releases idle keep-alive connections

Choose the key carefully: per-IP limits fail behind carrier-grade NAT and are trivially spread across botnets; per-user, per-API-key and per-tenant limits on authenticated routes are more precise. Use both.
Weight expensive endpoints: a search or report endpoint should have a much lower limit than a static read. Some gateways support cost-based limits where each request spends tokens proportional to its expected cost.
Return useful signals: 429 with Retry-After lets well-behaved clients back off instead of retrying immediately and making the overload worse.

See the Rate Limiting and API Abuse Guide and the WAF and WAAP Buyer's Guide for edge capabilities.

Designing for graceful degradation

The OWASP DoS Cheat Sheet's software design concepts are the resilience half of the problem: do cheap validation first, degrade gracefully, remove single points of failure, avoid CPU-heavy operations on the request path, handle exceptions so overload does not crash processes, and use asynchronous processing for long tasks.

Bulkheads: give expensive functions (search, export, image processing, report generation) their own worker pools, queues or services, so exhausting them leaves login, checkout and core reads working.
Queues with bounded depth: move heavy work off the request thread and reject new jobs with a clear error when the queue is full, rather than accepting work that will never finish.
Circuit breakers and load shedding: when a dependency slows down, fail fast and shed low-priority traffic so threads do not pile up waiting.
Caching: cache expensive, non-personalised responses so repeated identical requests cost almost nothing.
Authentication before cost: the cheat sheet notes that least privilege helps by denying anonymous users access to damaging functions. Put expensive operations behind authentication and per-user quotas.
Lockout design: hard account lockout after failed logins lets an attacker lock out real users at will; use progressive delays and risk-based challenges. See the Password Spraying and Credential Stuffing Defence Guide.

Choosing controls: small and large organisations

Small teams on managed platforms: start with the platform's request size limits, timeouts and rate limiting, set provider spending caps, add framework-level page size and upload limits, and run one load test against the most expensive endpoints. This removes most single-request DoS risk at low cost.
Large estates and public APIs: standardise limits in the API gateway per route class, require resource limits in the API design review, use cost-based GraphQL limits, isolate heavy functions into separate services, and run DoS test cases in CI against a staging environment.
Edge versus application: edge controls (CDN, WAF, gateway) are best for floods, slow HTTP, size limits and known protocol attacks. Only the application can bound query cost, regex time, decompression ratio and business side effects.

Implementing the programme

Inventory costly functions: the cheat sheet recommends analysing components by functionality, architecture and performance to find single points of failure. List endpoints that query large data sets, parse files, decompress, call paid providers, run regexes on user input or start background jobs.
Measure the cost: profile each with realistic worst-case input (largest page, deepest query, biggest permitted file) in a test environment you own, and record CPU time, memory and duration.
Set limits in report mode: deploy gateway rate limits in dry-run mode, add logging for requests that would exceed size, page or cost limits, and collect a baseline for at least one business cycle.
Enforce by risk: enable limits on anonymous expensive endpoints first, then authenticated ones, then internal APIs.
Test regularly: include DoS cases in security testing (ReDoS pattern scanning in static analysis, oversized and deeply nested inputs, decompression ratio tests, slow-client tests) and load test before major releases. Test only systems you own or are authorised to test.
Roll back safely: keep limits in configuration, not code, so a limit that blocks a legitimate customer can be relaxed per route or per tenant without a deploy.

Detection and measurement

Application DoS often shows up first as latency, not errors. Monitor per-endpoint latency percentiles (p95 and p99), CPU and memory per process, database active queries and their duration, worker pool and connection pool saturation, queue depth, 408, 413, 429 and 503 rates, and third-party API spend. Alert on a small number of clients or keys responsible for a large share of server time, which is the signature of an asymmetric attack.

Limit coverage: percentage of public endpoints with explicit timeout, size and page limits (target 100%).
Worst-case cost: maximum server time consumed by a single request in the last 30 days, per endpoint.
Resilience: availability of core functions (login, checkout) during load tests that saturate a non-core function.
Abuse cost: third-party spend per active user, with alerts when it exceeds an agreed ceiling.
Testing: number of ReDoS and resource-limit findings open past their remediation deadline.

Framework mapping

Framework	Reference	Relevance
OWASP API Security Top 10 2023	API4:2023 Unrestricted Resource Consumption	Missing limits on APIs
OWASP ASVS 5.0	V1.3.12; V2.4.1; V4.3.1; V5.2.1; V5.2.3; V13.1.2	ReDoS, anti-automation, GraphQL cost, upload and decompression limits, connection limits
MITRE ATT&CK	T1499.002; T1499.003; T1499.004	Service exhaustion, application exhaustion and exploitation for DoS
MITRE CAPEC	CAPEC-492; CAPEC-197; CAPEC-469; CAPEC-130	Regex blowup, data expansion, HTTP DoS, excessive allocation
NIST SP 800-53 Rev. 5	SC-5 Denial-of-service Protection; SI-10 Information Input Validation	Limiting effects of DoS; bounding input
NIST CSF 2.0	PR.IR-04; DE.CM-09	Adequate capacity for availability; monitoring runtime for adverse events

Where identity fits

Per-user and per-key limits only work if every caller has a distinct identity. Shared API keys used by many integrations, or one service account behind a whole partner, make it impossible to throttle the abuser without cutting off everyone. Issue a separate credential per client and per integration so limits, attribution and revocation are precise. See the OWASP API Top 10 API4 Unrestricted Resource Consumption Guide.

Common failure patterns

Relying on the CDN alone: volumetric protection is in place, but a single unauthenticated export request still runs a full table scan.
Mismatched timeouts: the proxy times out and the client retries, while the original query keeps running, so retries multiply the load.
Trusting archive headers: decompression limits checked against the declared size rather than the bytes actually written.
Client-controlled page size: a limit or pageSize parameter accepted without a server-side maximum.
Copied validation regexes: patterns from online repositories with nested quantifiers, run on unbounded input in a backtracking engine.
Unpatched protocol handling: web servers and proxies left on versions affected by protocol attacks such as HTTP/2 Rapid Reset (CVE-2023-44487).

Practitioner checklist

Inventory endpoints that query large data, parse or decompress files, run regexes on user input or call paid providers.
Set and test timeouts at the database, handler and proxy layers, inner shorter than outer.
Enforce request body, upload, header and page size limits at the edge and in the framework.
Check uncompressed size and file count before extraction, and disable XML entity expansion.
Scan regexes for exponential backtracking and use linear-time engines or match timeouts for untrusted input.
Apply GraphQL depth, amount and cost limits or persisted query allowlists.
Rate limit per user, per key and per address, weighted by endpoint cost, returning 429 with Retry-After.
Isolate expensive functions with bulkheads and bounded queues, and set provider spending caps.
Monitor latency percentiles, pool saturation and per-client server time, and alert on asymmetric consumers.
Patch web servers and proxies promptly for protocol DoS vulnerabilities listed in the KEV catalog.

Denial of Service at Application Layer Guide: Limits, Timeouts and Costly Endpoints