Application-layer and “low-and-slow” DDoS attacks explained by DDoS defence professionals
Application-layer (L7) and “low-and-slow” DDoS attacks are among the most insidious forms of denial-of-service threats. Rather than saturating bandwidth, they burn server CPU, memory, and database resources by forcing expensive operations—TLS handshakes, header decompression, routing, authentication, or cache misses—while looking deceptively like normal client traffic. This article explains how these attacks work, the modern vectors (HTTP/2, HTTP/3, GraphQL, gRPC, WebSockets), and how defenders can detect and mitigate them.
This article is part of our ongoing series on DDoS classification. If you’re new here, start with our DDoS taxonomy to see how L7 attacks fit within the wider threat landscape.
What Are Application-Layer & Low-and-Slow Attacks?
Application-layer DDoS attacks operate at Layer 7 of the OSI model, targeting the actual applications and APIs that users rely on. Unlike volumetric attacks, their aim is to force disproportionate work on servers, proxies, and databases.
- Application-Layer Floods generate high request rates (GET, POST, GraphQL, gRPC, etc.) that bypass caches and drive load on dynamic backends.
- Low-and-Slow Attacks keep many connections alive with minimal traffic—trickling headers or body data—tying up sockets, threads, and memory buffers without consuming significant bandwidth.
The unifying theme is cost asymmetry: attackers expend little bandwidth or CPU, while defenders spend far more per request or connection.
What makes application layer attacks dangerous?
- Stealth: Traffic often mimics legitimate clients, staying below volumetric detection thresholds.
- Cost asymmetry: TLS handshakes, JSON parsing, template rendering, and cache misses are expensive for servers but cheap for attackers.
- Modern protocol abuse: HTTP/2 Rapid Reset and gRPC cancellation churns, or WebSocket floods, exploit protocol features to amplify impact.
- Low bandwidth, high pain: Attacks like Slowloris succeed with sub-Mbps traffic by exhausting per-connection resources.
Common Attack Vectors and Their Impact
Below we summarise common application-layer and low-and-slow attack vectors, their mechanics, peak observations, and primary targets.
| Attack Type | Layer | Description | Notable Peak Impact | Resource Targeted |
|---|---|---|---|---|
| HTTP GET/POST Flood with Cache-Busting | 7 | Random query strings/headers force cache misses, driving load to origin | 10M+ rps seen at CDNs | Origin CPU, DB/cache |
| HTTP/2 Rapid Reset (CVE-2023-44487) | 7 | Opens many streams then cancels with RST_STREAM, overwhelming state machines | 201–398M rps (2023) | Proxy thread pools, CPU |
| Slowloris / RUDY | 7 | Dribbles partial headers/bodies just above timeout thresholds | Effective <1 Mbps | Sockets, worker threads |
| GraphQL Deep Recursion | 7 | Nested/aliased queries explode resolver and DB work | Exploitable at low RPS | DB pools, CPU |
| WebSocket Floods | 7 | Many concurrent upgrades plus idle/junk frames | 1M+ concurrent conns possible | Sockets, memory |
| gRPC Ping/Metadata Abuse | 7 | Excessive keepalives, SETTINGS, metadata churn | Reported since 2019 | Thread pools, per-conn streams |
| Login Spray / Credential Stuffing | 7 | Distributed low-rate auth attempts bypass per-IP limits | Widely reported | Auth CPU, DB, session store |
| Prefix Scatter (Carpet Bombing at L7) | 7 | Spreads small RPS across many endpoints | Ongoing (2024–2025) | Endpoint budgets, detection systems |
How These Attacks Work: Floods vs. Low-and-Slow
- Floods: Cache-busting HTTP floods, Rapid Reset, and GraphQL recursion generate enormous request or stream churn, hammering CPU, databases, and thread pools.
- Low-and-Slow: Attacks like Slowloris or RUDY tie up sockets and worker threads by sending headers or bodies extremely slowly. Bandwidth stays low, but per-connection state and file descriptors get exhausted.
- Protocol exploitation: HTTP/2 and gRPC enable multiplexing and metadata, which attackers abuse to create churn without breaching simple concurrency limits.
Real-World Examples
- HTTP/2 Rapid Reset (2023, 2025): Record floods of 201M–398M rps against hyperscalers; required urgent patches across CDNs, proxies, and gRPC servers. More recent variation of this attack vector is MadeYouReset (2025)
- Slowloris: Still effective against unprotected Apache deployments, consuming threads with minimal bandwidth.
- GraphQL recursion: Exploited by adversaries to drive high CPU and DB calls from only a handful of queries.
- WebSocket floods: Seen in gaming and chat services, overwhelming per-IP connection limits where WAF inspection stops after upgrade.
Key Differences: L7 Floods vs. Low-and-Slow
Although both application-layer floods and low-and-slow techniques target Layer 7, they differ significantly in how they apply pressure on infrastructure. The table below highlights the main contrasts.
| Aspect | Floods | Low-and-Slow |
|---|---|---|
| Primary Target | Application endpoints, APIs | Connections, sockets, threads |
| Attack Mechanism | High RPS, cache-busting, stream churn | Long-lived idle/slow connections |
| Traffic Volume | Moderate to very high | Very low bandwidth |
| Detection Difficulty | High (mimics clients) | High (low traffic signature) |
| Resource Impact | CPU, DB, cache, proxy pools | File descriptors, memory, worker threads |
Mitigation Strategies for Application-Layer & Low-and-Slow Attacks
Defending against L7 and low-and-slow attacks is very different from handling volumetric floods. These threats don’t just overwhelm pipes; they exploit how your applications and infrastructure are built. That means the right defence strategy depends heavily on your own environment—your CDN setup, reverse proxies, application servers, APIs, and databases.
In this chapter, we’ll highlight the main defensive methodologies available. Not all will apply to every stack, but together they form a comprehensive toolbox. The best results come from layering these measures across the edge, proxy, application, and backend.
1. Edge, CDN, and WAF Protections
The edge is your first line of defence, filtering and rate-limiting traffic before it hits origin servers.
- Patch known protocol issues: Ensure your CDN, reverse proxies, and origin servers are patched against HTTP/2 Rapid Reset (CVE-2023-44487) and gRPC advisories. Track cancellation rates and abusive patterns, not just concurrent stream counts.
- Composite-key rate limiting: Go beyond IP-only rules. Rate-limit based on a mix of factors—IP + TLS fingerprint (JA3/JA4) + cookie + endpoint—to resist botnets and prefix-scatter attacks.
- Cache hardening: Normalise or ignore non-essential query parameters in cache keys so attackers can’t force origin hits with randomised URLs. Configure “cache everything” rules for safe static pages.
- Bot management: Use device fingerprints, behavioural signals, and action-point challenges (e.g. CAPTCHAs or Turnstile on login) to stop credential stuffing and scripted floods.
2. Reverse Proxy and HTTP Server Hardening
Tuning your reverse proxies and web servers helps cut off abusive connections early.
- Timeouts for slow attacks:
- Apache: mod_reqtimeout with RequestReadTimeout for headers/bodies.
- Nginx: client_header_timeout and client_body_timeout.
These kill Slowloris-style attacks by refusing to hold sockets open indefinitely.
- Apache: mod_reqtimeout with RequestReadTimeout for headers/bodies.
- Connection and stream limits: Cap concurrent streams (max_concurrent_streams) and header/metadata sizes in HTTP/2/3. Monitor RST_STREAM or PING abuse and close abusive connections quickly.
- WebSocket controls: Require authentication before upgrade, cap per-IP connection counts, enforce idle timeouts, and apply size limits on frames. Remember that many WAFs stop inspecting after the initial handshake.
3. Application- and API-Specific Safeguards
Different application protocols have unique risks that need targeted countermeasures.
- GraphQL:
- Disable or restrict introspection in production.
- Enforce query depth/complexity limits.
- Use persisted or allow-listed queries only.
- Add timeouts and execution budgets per identity.
- Disable or restrict introspection in production.
- gRPC:
- Set conservative keepalive policies (minimum intervals, no pings without calls).
- Cap concurrent streams and metadata sizes.
- Apply circuit breakers in Envoy/meshes to bound pending requests.
- Keep gRPC libraries patched against Rapid Reset vulnerabilities.
- Set conservative keepalive policies (minimum intervals, no pings without calls).
- Login and transactional endpoints:
- Apply per-user/session rate limits, not just per IP.
- Detect anomalies like credential stuffing via leaked-credential checks and fingerprinting.
- Place challenges at the action point (login/checkout), not just on page load.
- Apply per-user/session rate limits, not just per IP.
4. Backend and Database Resilience
Even with strong edge and application defences, some traffic will hit your backends. Resilience here prevents total collapse.
- Backpressure and load shedding: Enforce maximum queue lengths and return 429 or 503 when circuits trip. Serve stale content where possible instead of hammering databases.
- Database and cache guardrails:
- Limit pool sizes per instance.
- Protect “hot keys” and isolate critical queries (e.g. logins, payments) into dedicated pools.
- Limit pool sizes per instance.
- Autoscaling with limits: Allow scaling to absorb legitimate surges, but prevent runaway autoscaling that simply shifts bottlenecks onto the database layer.
5. Operational Playbook
Finally, effective defence means preparation and practice.
- Before an attack: Patch protocol stacks, tune cache keys, set basic timeouts, and run canary drills that simulate floods and login sprays.
- During an attack: Drop abusive connections early (e.g. high RST_STREAM ratios), tighten rate limits on hot endpoints, enable managed challenges, and serve stale responses to protect backends.
- After an attack: Review dashboards, refine rate limits, adjust keepalive/stream policies, and harden high-risk APIs (GraphQL, login).
Conclusion
Application-layer and low-and-slow attacks are complex and highly infrastructure-dependent. The right mix of mitigations will differ between, say, an e-commerce platform with dynamic cart endpoints and a gaming backend running WebSockets. The goal is to build layered defences: edge filtering and bot management, proxy and server tuning, protocol-specific safeguards, and backend guardrails. When combined, these controls give you a realistic chance of withstanding attacks that bandwidth-only tools can’t stop.
For a full understanding of DDoS attack types and defence strategies, continue reading our full DDoS taxonomy.
About FastNetMon
FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.
For more information, visit https://fastnetmon.com