Application Layer DDoS Attacks | NOC.org

What Are Application Layer DDoS Attacks?

Application layer DDoS attacks (also called Layer 7 attacks) target the application itself rather than the network infrastructure. While volumetric DDoS attacks overwhelm bandwidth and protocol attacks exploit network protocol weaknesses, application layer attacks exhaust server resources — CPU, memory, database connections, and disk I/O — by sending requests that appear legitimate but are designed to be expensive for the server to process.

These attacks are the most challenging type of DDoS attack to mitigate because each individual request looks exactly like a legitimate user's request. A volumetric attack sending 100 Gbps of UDP traffic is obvious and can be filtered at the network edge. An application layer attack sending 10,000 HTTP GET requests per second for a complex search query is far harder to distinguish from 10,000 legitimate users doing the same thing.

Layer 7 vs Layer 3/4 Attacks

The asymmetry is what makes application layer attacks so effective: a single HTTP request that costs the attacker a few hundred bytes can trigger a database query, template rendering, file I/O, and API calls that consume significant server resources. An attacker with a modest botnet can take down a powerful server.

Types of Application Layer DDoS Attacks

HTTP Flood

An HTTP flood is the most common application layer DDoS attack. The attacker sends a high volume of HTTP GET or POST requests to the target. Because each request uses a valid TCP connection (completing the three-way handshake), it cannot be filtered by SYN flood protections.

HTTP floods come in several variants:

• GET floods: Request resource-intensive pages — search results, product listings, reports, or any page that requires database queries and server-side processing.
• POST floods: Submit forms, API endpoints, or upload handlers that consume server resources processing the input.
• Randomized floods: Vary URLs, parameters, headers, and user agents to evade pattern-based detection. Each request looks unique.
• Cache-busting floods: Add random query parameters (?rand=12345) to bypass CDN and server-side caches, forcing every request to hit the origin server.

Slowloris

Slowloris is a low-bandwidth attack that holds connections open by sending partial HTTP requests. The attacker opens many connections to the target and sends HTTP headers slowly — one byte at a time, or one header line every few seconds. The server keeps each connection open while waiting for the complete request, eventually exhausting its maximum connection pool.

Slowloris is effective because:

• It requires very little bandwidth (a single laptop can take down an unprotected Apache server).
• It does not send complete requests, so it does not appear in application logs.
• Apache's default configuration (with prefork or worker MPM) is particularly vulnerable because each connection consumes a server process or thread.

Nginx is inherently more resistant to Slowloris because its event-driven architecture handles connections without dedicating a thread per connection.

RUDY (R-U-Dead-Yet)

RUDY targets web application forms by submitting POST requests with an extremely long content-length header, then sending the body data one byte at a time. The server allocates resources to handle the expected large POST body and waits for the data that trickles in over minutes or hours. Like Slowloris, RUDY requires minimal bandwidth and exploits the server's patience in waiting for complete requests.

API Abuse

Modern web applications expose APIs that can be targeted with high volumes of legitimate-looking requests. API abuse attacks target:

• Search endpoints: Complex search queries that scan large databases or invoke expensive full-text search operations.
• Report generation: Endpoints that produce PDFs, CSV exports, or complex aggregations consuming significant CPU and memory.
• Authentication endpoints: Repeated login attempts that trigger password hashing (bcrypt/scrypt are intentionally CPU-intensive), account lookups, and session creation.
• GraphQL endpoints: Deeply nested queries that cause exponential database joins or recursive resolution.

Login Floods

Login floods target authentication systems with massive volumes of login attempts. Each attempt triggers password hashing (designed to be computationally expensive), database lookups, session management, and potentially notification systems. Even if every attempt fails, the processing cost can overwhelm the authentication infrastructure. This overlaps with brute force attacks, but the goal here is denial of service rather than credential discovery.

Search and Query Abuse

Attackers identify pages or API endpoints that trigger expensive backend operations — database queries with complex JOINs, full-text search across millions of records, or dynamically generated content that cannot be cached. By flooding these specific endpoints, a relatively small number of requests can exhaust database connections, max out CPU, or fill server memory.

Ecommerce sites are particularly vulnerable: product search, filtering by multiple attributes, and "sort by" operations that require full table scans are all expensive operations that attackers can abuse.

Why Application Layer Attacks Are Hard to Detect

Traditional DDoS detection looks for anomalous traffic volumes — a sudden spike in packets per second or bits per second triggers mitigation. Application layer attacks evade this detection because:

• Low traffic volume: The attack may generate only a few megabits per second of traffic, well below volumetric detection thresholds.
• Valid TCP connections: Every request uses a properly established TCP connection, passing SYN cookie and connection-level protections.
• Legitimate request format: Requests use valid HTTP methods, headers, and parameters that match normal traffic patterns.
• Distributed sources: Attacks from botnets use thousands of unique IP addresses, each sending only a few requests per minute — below any per-IP rate limit.
• Browser-like behavior: Sophisticated bots use real browser user agents, accept cookies, execute JavaScript, and mimic human browsing patterns.

Effective detection requires understanding normal application behavior and identifying deviations: unusual request rates to specific URLs, abnormal geographic distribution of requests, missing referrer headers, or clients that do not load page resources (CSS, images, JavaScript) after requesting HTML pages.

Mitigation Strategies

Web Application Firewall (WAF)

A WAF is the primary defense against application layer DDoS attacks. Unlike network-level DDoS mitigation that operates on packets and flows, a WAF understands HTTP semantics and can inspect, classify, and filter requests based on content, behavior, and reputation:

• Request inspection: Analyze headers, parameters, cookies, and request bodies for attack signatures.
• Bot detection: Identify automated tools by their behavior, TLS fingerprint, JavaScript execution capability, and interaction patterns.
• Virtual patching: Block exploitation of known application vulnerabilities without modifying the application code.

NOC.org's WAF provides application-aware DDoS protection that distinguishes legitimate traffic from attacks in real time.

Rate Limiting

Rate limiting restricts the number of requests a client can make within a time window. Effective rate limiting for application layer attacks requires granularity beyond simple per-IP limits:

• Per-endpoint rate limits: Set different limits for different URLs. A login page might allow 5 requests per minute, while a static page allows 100.
• Progressive rate limiting: Start with warnings (CAPTCHA), then throttle, then block. This reduces false positives against legitimate users.
• Sliding window limits: Use sliding time windows rather than fixed intervals to prevent burst attacks at window boundaries.
• Token bucket or leaky bucket algorithms: Allow short bursts while enforcing sustained rate limits.

CAPTCHA Challenges

When suspicious traffic is detected, challenge the client to prove it is human rather than blocking outright. This avoids blocking legitimate users who may share an IP with attackers (corporate NATs, VPNs, mobile carriers). Modern CAPTCHA systems use invisible challenges that analyze browser behavior rather than requiring users to solve puzzles.

Behavioral Analysis

Behavioral analysis identifies attackers by how they interact with the application rather than what they request:

• Session behavior: Legitimate users navigate a site with page views, clicks, scrolling, and mouse movements. Bots often request a single URL repeatedly without any human interaction.
• Request timing: Human requests have natural variance in timing. Automated requests often arrive at mathematically precise intervals.
• Resource loading: Real browsers load CSS, JavaScript, images, and fonts after an HTML page. Bots typically request only the target URL.
• Cookie and session handling: Legitimate clients maintain sessions and send cookies. Many attack tools do not handle cookies or sessions correctly.

CDN and Content Caching

A CDN absorbs application layer attacks by serving cached content from edge servers, preventing attack traffic from reaching the origin. This is effective for attacks targeting cacheable content but less effective against dynamic endpoints. Strategies include:

• Cache aggressively: increase TTLs and cache more content types.
• Normalize query parameters to prevent cache-busting with random parameters.
• Serve stale content when the origin is under stress (stale-while-revalidate and stale-if-error cache directives).

Application-Level Hardening

• Optimize expensive operations: Add database indexes, implement query result caching, set query timeouts.
• Implement connection limits: Limit maximum concurrent connections from a single IP at the web server level.
• Set request timeouts: Configure aggressive timeouts for incomplete requests (mitigates Slowloris and RUDY).
• Queue heavy operations: Move expensive operations (report generation, search, exports) to background queues with concurrency limits.

Real-World Attack Scenarios

Ecommerce During Peak Sales

Attackers target online retailers during peak shopping events (Black Friday, flash sales) when the line between legitimate traffic spikes and DDoS is thinnest. Application layer attacks against search and checkout endpoints cause outages at the moment when revenue loss is highest.

Financial Services Login Floods

Banking and financial applications with strong password hashing (bcrypt with high cost factors) are vulnerable to login floods. Each failed login attempt consumes significant CPU time. A distributed login flood from a botnet can exhaust the authentication infrastructure while each individual IP stays below rate limits.

API-First Applications

SaaS applications and mobile backends expose APIs that process JSON payloads, run database queries, and return structured data. Without per-endpoint rate limiting, a single malicious API consumer can monopolize database connections and CPU resources, degrading service for all users.

Defend Against Application Layer Attacks

Application layer DDoS attacks exploit the inherent cost asymmetry between sending a request and processing it. Defense requires application-aware security that understands HTTP semantics, user behavior, and your application's normal traffic patterns. A web application firewall provides this intelligence — inspecting every request, detecting anomalies, challenging suspicious clients, and absorbing attack traffic before it reaches your application. Explore NOC.org's DDoS protection and WAF plans to keep your applications online under attack.