← Back to glossary

Denial of Service (DoS)

security CWE-400 OWASP A5:2021 CVSS 7.5 PHP 5.0+ Beginner

debt(d9/e7/b7/t7)

d9 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'silent in production until users hit it' (d9). The detection_hints list Cloudflare, Nginx, and AWS Shield — these are reactive/mitigating infrastructure layers, not proactive static-analysis or linting tools that catch the vulnerability at development time. Missing rate limiting, unbounded input sizes, and absent timeouts produce no compiler warning, no default linter signal, and no SAST flag in normal PHP tooling; the absence of a defence only becomes visible when real traffic exhausts the server.

e7 Effort Remediation debt — work required to fix once spotted

Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix explicitly states 'layer defences: Cloudflare/WAF at the edge, Nginx rate limiting, PHP-FPM queue limits, and circuit breakers — no single layer stops all DoS; depth of defence matters.' This is not a single-line patch; it requires coordinated changes across infrastructure configuration, web-server config, PHP runtime settings, and application-layer code (rate limiting middleware, timeouts, memory limits on every expensive endpoint), touching multiple layers and files.

b7 Burden Structural debt — long-term weight of choosing wrong

Closest to 'strong gravitational pull' (b7). The term applies_to web and API contexts broadly (php_min 5.0, meaning nearly any PHP web application). Every public endpoint, every expensive operation, every external call must be designed with DoS in mind. Tags include availability, rate-limiting, and infrastructure — all of which impose an ongoing design tax on architecture decisions, endpoint design, and operational setup. Every new feature or endpoint requires re-evaluation of rate limiting and resource bounding.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap' (t7). The misconception field states: 'Only large volumetric attacks cause denial of service. A single attacker sending requests that trigger expensive regex (ReDoS) or deeply nested JSON parsing can exhaust server memory just as effectively.' This directly contradicts the intuitive mental model most developers hold — that DoS requires a flood of traffic from many sources. The application-layer single-request exhaustion vector contradicts how developers who know about network-layer DDoS expect the concept to behave.

About DEBT scoring → scored by claude-sonnet-4-6 · 2026-05-07 · reviewed by human

Also Known As

Denial of Service DoS DDoS service disruption

TL;DR

An attacker overwhelms a system with requests or exploits resource-exhaustion bugs to make it unavailable to legitimate users.

Explanation

Denial of service attacks range from volumetric floods (UDP amplification, HTTP floods) to application-layer attacks that exploit expensive operations — complex regex matching, deeply nested JSON parsing, or cryptographic operations. PHP applications are vulnerable to application-layer DoS through unbounded file uploads, regex with catastrophic backtracking, or expensive database queries triggered without rate limits. Mitigations include rate limiting, input size restrictions, request timeouts, and caching computed results.

Common Misconception

✗ Only large volumetric attacks cause denial of service. A single attacker sending requests that trigger expensive regex (ReDoS) or deeply nested JSON parsing can exhaust server memory just as effectively.

Why It Matters

A successful DoS renders a service unavailable to legitimate users — application-layer DoS can achieve this with far fewer requests than a network flood by exploiting expensive operations.

Common Mistakes

No rate limiting on computationally expensive endpoints (PDF generation, image resizing, complex reports).
Unbounded input sizes — parsing a 1GB JSON body exhausts memory on a single request.
No timeout on external HTTP calls or database queries — a slow downstream service blocks all threads.
Missing set_time_limit() and memory limits on user-triggered batch operations.

Code Examples

✗ Vulnerable

// Unbounded XML parsing — billion laughs / memory exhaustion:
$xml = file_get_contents('php://input'); // No size limit
$doc = new DOMDocument();
$doc->loadXML($xml); // No entity protection or memory limit

✓ Fixed

// Rate limiting per IP — Redis token bucket
public function handle(Request \$req): Response {
    \$key   = 'rate:' . \$req->ip();
    \$limit = 100; // per minute
    \$count = \$redis->incr(\$key);
    if (\$count === 1) \$redis->expire(\$key, 60);

    if (\$count > \$limit) {
        return response('Too Many Requests', 429)
            ->header('Retry-After', \$redis->ttl(\$key));
    }

    // Resource limits per request
    set_time_limit(30);
    ini_set('memory_limit', '128M');

    return \$next(\$req);
}

// ReDoS — avoid catastrophic backtracking:
// Bad:  /^(a+)+\$/ — exponential on 'aaaaaab'
// Good: /^a+\$/    — linear