Home / Attacks & tests / Denial of Service Testing Vulnerabilities
8 test cases
Denial of Service Testing Vulnerabilities
Denial of service testing at the application layer examines whether a small amount of caller effort can consume a disproportionate amount of the application's resources. It is not volumetric flooding, which is a network concern; it is a single well-chosen request costing far more to serve than to send.
What an attacker is trying to achieve
The attacker wants the application unavailable, or one specific account unavailable, at a cost they can sustain. The most useful findings are the asymmetric ones: an input that makes the server allocate, iterate, write or wait far beyond what the request itself cost to make.
Test cases
8 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-DOS-01 SQL Wildcard and Expensive Query Abuse
Objective — Determine whether a caller can submit a search that costs the database disproportionately more to answer than it costs to request.
How it is tested — Identify search and filter parameters that reach a database query. Submit leading wildcards, patterns forcing full scans, and repeated wildcards that make matching expensive, and measure response time against a normal query. Test unbounded result sets by requesting very large page sizes, and sorting or grouping on unindexed columns where the parameters permit it. Establish whether any query timeout or result cap applies.
Prerequisites — A non-production environment with a representative data volume; explicit permission; database timing or metrics visible.
Indicators — Response time growing by orders of magnitude from a small input change; no cap on page size or result count; no query timeout; concurrent expensive queries exhausting the connection pool.
Coverage — V11.1.4CWE-1176CWE-405
Depth — Manual Confirmation degrades the service, so it is run deliberately and bounded rather than swept.
WEB-DOS-02 Locking Customer Accounts
Objective — Determine whether a third party can render a known account unusable by deliberately triggering its protective lockout.
How it is tested — Using a known identifier, submit failed authentication attempts until the lockout threshold is reached, and establish whether the legitimate holder is then prevented from signing in. Determine whether the lock is applied to the account or to the source, and whether recovery requires administrative action. Repeat immediately after unlock to establish whether the state can be sustained indefinitely at trivial cost.
Prerequisites — A disposable account whose identifier is known; a non-production environment; explicit permission, since the account becomes unusable.
Indicators — A known account rendered unusable by a third party; lockout applied to the account rather than the source; the locked state sustainable by repetition; unlock requiring manual intervention.
Coverage — WSTG-ATHN-03V2.2.1CWE-645CWE-307
Depth — Manual This is the trade-off in the lockout control tested from the other direction, and judging the balance requires knowing who the users are.
WEB-DOS-03 Buffer Overflows Causing Service Failure
Objective — Determine whether oversized input causes a component to terminate rather than to reject the input, making a crash reachable by any caller.
How it is tested — Submit values substantially beyond expected lengths to every entry point, concentrating on native components and protocol parsers. Increase length progressively to find the threshold at which behaviour changes, and distinguish a clean rejection from a termination by observing whether the service restarted. Include headers and structured fields, which are frequently parsed by different code than body parameters.
Prerequisites — A non-production environment; explicit permission; visibility of process restarts; an agreed stop condition.
Indicators — A worker or service restarting after an oversized input; a threshold at which rejection becomes termination; a crash reachable without authentication.
Coverage — V5.4.1CWE-120CWE-400
Depth — Manual Applies to native components; confirmation is a crash, so it is bounded and run once rather than swept.
WEB-DOS-04 User-Specified Object Allocation
Objective — Determine whether a caller can dictate how much memory the application allocates for a single request.
How it is tested — Identify parameters that influence allocation: counts, sizes, dimensions, page sizes, batch lengths and declared content lengths. Submit values far beyond intended ranges and observe memory behaviour. Include structured input that expands on parsing — deeply nested or highly repetitive documents, and compressed payloads whose expanded size greatly exceeds their transmitted size. Establish whether any bound is applied before allocation rather than after.
Prerequisites — A non-production environment with memory metrics visible; explicit permission; the parameter inventory.
Indicators — Memory use scaling with a caller-supplied number; a compressed payload expanding disproportionately; allocation performed before validation; no upper bound on a count or size.
Coverage — V12.1.1CWE-789CWE-409
Depth — Manual Requires observing the server's resource use, not just its responses.
WEB-DOS-05 User Input as a Loop Counter
Objective — Determine whether a caller-supplied value controls how many times the application iterates, turning a small request into a long computation.
How it is tested — Identify parameters plausibly used as counts, repetitions, ranges, depths or precision. Increase each and measure response time, looking for growth that is more than linear. Include indirect cases: pattern-matching input that causes catastrophic backtracking, iteration counts in cryptographic or hashing parameters, and pagination that recomputes rather than seeks. Establish whether any ceiling is enforced server-side.
Prerequisites — A non-production environment; explicit permission; timing measurement; the parameter inventory.
Indicators — Response time growing faster than the input value; no server-side ceiling on a count; pattern input causing disproportionate processing; a single request occupying a worker for a sustained period.
Coverage — V11.1.4CWE-1050CWE-1333
Depth — Manual The parameters that drive loops are rarely named as such; finding them is the work.
WEB-DOS-06 Writing User-Provided Data to Disk
Objective — Determine whether a caller can cause the application to consume storage without bound, degrading it for everyone.
How it is tested — Identify every path by which caller input reaches persistent storage: uploads, exports, caches, generated documents, temporary processing files and log entries. Establish whether size and count are bounded per request, per account and in total, and whether temporary artefacts are removed after use or accumulate. Test whether a request that fails part-way leaves its artefacts behind.
Prerequisites — A non-production environment with storage metrics visible; explicit permission and an agreed volume ceiling; access to observe the storage location.
Indicators — No quota per account or in total; temporary artefacts surviving the request; failed requests leaving files behind; verbose logging driven by caller input.
Coverage — V12.1.1V12.1.3CWE-400CWE-770
Depth — Manual Requires observing the filesystem over time rather than reading responses.
WEB-DOS-07 Failure to Release Resources
Objective — Determine whether resources acquired to serve a request are reliably released, including when the request fails or is abandoned part-way.
How it is tested — Issue requests that fail at various stages — rejected by validation, failing downstream, abandoned by disconnecting mid-response — and observe whether connections, file handles, threads and locks return to their pools. Repeat at volume to establish whether a slow leak exists. Test operations that acquire a lock and then fail, since these can block other callers indefinitely.
Prerequisites — A non-production environment with pool and handle metrics visible; explicit permission; the ability to disconnect mid-response.
Indicators — Pool utilisation rising and not recovering; handles or threads growing with failed requests; a lock retained after a failure; the service degrading over sustained ordinary use.
Coverage — V11.1.4CWE-404CWE-772
Depth — Manual The finding appears over time under load, which is a shape of test a scanner does not run.
WEB-DOS-08 Storing Too Much Data in Session
Objective — Determine whether a caller can cause the application to accumulate unbounded per-session state, exhausting memory across many sessions.
How it is tested — Identify features that add to session state rather than replacing it: baskets, comparison lists, wizard progress, search history, uploaded drafts. Add entries repeatedly and establish whether any limit applies. Then create many sessions, each carrying substantial state, and observe aggregate memory. Establish whether anonymous visitors can create sessions freely and whether idle sessions expire promptly enough to matter.
Prerequisites — A non-production environment with memory metrics; explicit permission; the ability to create sessions in volume.
Indicators — No cap on entries added to session state; sessions creatable without authentication in volume; memory scaling with session count and not recovering; long idle expiry combined with large per-session state.
Coverage — WSTG-SESS-01V11.1.4CWE-770CWE-400
Depth — Manual Needs many sessions and server-side memory observation, neither of which is part of a scan.
What we need from you
A non-production environment sized comparably to production, and explicit written permission, since every confirming result in this category degrades the service; visibility of resource metrics and logs so that effects can be observed rather than inferred; and an agreed stop condition.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- V11.1.4 — Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.
- CWE-1176 — Inefficient CPU Computation
- CWE-405 — Asymmetric Resource Consumption (Amplification)
- WSTG-ATHN-03 — Testing for Weak Lock Out Mechanism
- V2.2.1 — Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.
- CWE-645 — Overly Restrictive Account Lockout Mechanism
- CWE-307 — Improper Restriction of Excessive Authentication Attempts
- V5.4.1 — Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.
- CWE-120 — Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
- CWE-400 — Uncontrolled Resource Consumption
- V12.1.1 — Verify that the application will not accept large files that could fill up storage or cause a denial of service.
- CWE-789 — Memory Allocation with Excessive Size Value
- CWE-409 — Improper Handling of Highly Compressed Data (Data Amplification)
- CWE-1050 — Excessive Platform Resource Consumption within a Loop
- CWE-1333 — Inefficient Regular Expression Complexity
- V12.1.3 — Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.
- CWE-770 — Allocation of Resources Without Limits or Throttling
- CWE-404 — Improper Resource Shutdown or Release
- CWE-772 — Missing Release of Resource after Effective Lifetime
- WSTG-SESS-01 — Testing for Session Management Schema
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.