Anatomy of a modern L7 DDoS attack

What changed in 2026

Volumetric L3/L4 attacks are now a solved problem for any defender behind a credible scrubbing provider. Cloudflare, AWS Shield Advanced, and Akamai Prolexic absorb terabit-class floods as a routine product feature. The 2.3 Tbps Yandex attack of 2021 was once notable; today, similarly-sized events are mitigated without an SLA incident report.

What we still see succeed against well-resourced targets — casinos, exchanges, financial APIs, ticketing platforms — is L7 application-logic abuse, not raw bandwidth.

The pattern looks like this:

1. Adversary studies the application for one to two weeks. They register accounts, browse, watch JS bundles for hidden endpoints, hit the OpenAPI spec if it leaks.
2. They identify a small number of endpoints that perform a non-trivial server-side action with no rate limit beyond a generous per-IP quota.
3. They distribute moderate request volume (10–100k rps) from a botnet that passes provider bot checks — residential proxies, real browsers, real TLS fingerprints, real cookies.
4. The endpoint becomes the bottleneck. The database connection pool exhausts. Queues back up. The rest of the application degrades alongside.

Provider defaults don't catch this. They catch the volume signature, not the request-shape signature.

A concrete example we encountered

A licensed European online casino was hit during a sponsored stream — peak audience, peak revenue moment. The attack:

• Volume: ~28,000 rps from ~6,400 residential proxies
• Target: POST /api/bonus/claim — a per-user-once endpoint that, before claiming, checked eligibility against three database tables and wrote to a fourth
• Effect: Within 90 seconds, the DB connection pool was at 100%. The streaming page loaded but the cashier flow timed out. Conversion dropped 84% during the 47-minute attack window.

Cloudflare saw normal-looking HTTPS requests with real user-agents and valid TLS. Their default rate limit was per-IP, set generously enough that no single residential IP tripped it. The aggregate effect at the application layer was what hurt.

Where defenders fail

Most teams we work with have one or more of these gaps:

1. Per-IP rate limits as the only L7 control

A residential botnet is below the per-IP threshold by design. Per-IP is necessary but radically insufficient. You need limits that aggregate across:

• IP — for the trivial case
• ASN — residential proxies often cluster
• TLS fingerprint (JA3/JA4) — bots reuse fingerprints
• Session / cookie — even if the bot rotates IPs
• Behavioural anomaly — request cadence, mouse-event absence, accept-language mismatch

2. Treating cost-asymmetric endpoints as ordinary

Find the endpoints where client cost is cheap but server cost is expensive. Login, search, sign-up, cart, checkout, bonus-claim, withdrawal-initiate. These need:

• Stricter rate limits than read-only endpoints
• Proof-of-work or captcha only under stress (not always — that hurts UX)
• Queueing with priority for authenticated, low-risk sessions
• Graceful degradation: serve a 429 with a real "try again in N seconds" header rather than 503

3. No tabletop exercise for an active L7 attack

When the attack starts, the most expensive minutes are the first 10. You need a runbook that names which engineer logs into which dashboard, what to escalate to the provider, when to enable challenge mode, and how to communicate with customers. Most teams have no runbook. They improvise. They lose 30 minutes of decision time.

4. Provider lock-in dressed as protection

Premium tier DDoS features from cloud providers are real, but their incentives are aligned with feature gating, not your specific application. If your bonus-claim endpoint can be hit through a path that bypasses their WAF, no premium tier matters.

What we look for during stress tests

When we run a DDoS stress test, L7 is where we spend most of the time. We probe:

Surface	Why it's brittle
Login	Auth backend often calls user store + audit log + MFA validator. Three round-trips per attempt.
Search	Often database-bound and un-cached. Bonus points if it joins to a recommendation engine.
Cart + checkout	Write-heavy, transactional, often hits payment processors with rate limits of their own.
Account creation	Write + email side-effects. Some teams trigger Stripe customer creation here.
Bonus / promo claim	High-value, per-user-once, validated against multiple tables.
Sign-out	Often forgotten. Writes to session store.

The "winning" attack pattern is almost always against one of these, not against GET /.

What you should do this quarter

1. Audit your provider's L7 rules. Defaults are tuned for the average site, not your site. Read the actual rule expressions, not the marketing.
2. Identify your top 5 cost-asymmetric endpoints. Rank them by (server cost) ÷ (client cost). The top 2-3 need session- and fingerprint-aware rate limiting, not just per-IP.
3. Pre-stage degradation behaviours. Queueing, proof-of-work, and challenge pages should be ready to flip on. Don't write them under fire.
4. Run a synthetic load test against those endpoints with realistic bot traffic. Without that data, you're guessing. This is what our DDoS stress test delivers.
5. Write the runbook. Five pages, named owners, decision tree, communication templates. Tabletop it once per quarter.

If you want help with any of this, book a 30-minute scoping call — we run these projects end-to-end, including the validation test. No engagement, no charge for the call.