Quick answer
When a WAF receives a body larger than it can inspect, it has two options: fail-open (pass it without inspection, the juicy case) or fail-closed (block it). But there's a third, far less documented behavior: if the attacker can force the server's response to land in the cache with a malicious payload reflected in a cookie, you turn the oversize bypass into a persistent per-victim DoS — every future request from the victim carries the cookie payload, the WAF blocks it, and the app is inaccessible to them for the cookie's TTL (1 day to 1 month). Combined with XSS for remote delivery → mass DoS + selective targeting.
1. The core concept
Setup: a WAF (Cloudflare/Akamai/AWS) protects a site. The WAF has an inspection limit:
| WAF | Inspection limit |
|---|---|
| Cloudflare Free | ~8 KB |
| Cloudflare Pro/Business | low default, up to 1 MB with support |
| Cloudflare Enterprise | 128 KB |
| AWS WAF (ALB) | 8 KB |
| AWS WAF (CloudFront) | 16-64 KB |
| Akamai | ~16-32 KB typically |
| Imperva/Incapsula | configurable, default ~24 KB |
If the body exceeds that limit and the WAF is configured with fail-open (default in Cloudflare/AWS WAF) → the inspection is skipped, the origin receives the full request.
This, on its own, is already a bypass for classic SQLi/XSS. The DoS-via-WAF twist: if the payload is reflected in a cookie that the app returns in the Set-Cookie, the user's future requests carry that cookie and the WAF does inspect them (Headers/Cookies typically have another limit, usually lower). Once a malicious cookie is detected → the WAF blocks → the app is inaccessible.
2. The attack's components
| Component | Function |
|---|---|
| POST endpoint with tolerated padding | Payload carrier (body inspection bypass) |
| Parameter the server reflects into a cookie | Persistence vector |
| Missing CSRF protection | Allows delivery via the attacker's HTML |
| WAF that inspects cookies on every request | The engine of the subsequent DoS |
| Long cookie TTL | Duration of the per-victim DoS |
Real-world: parameters like tracking_id, last_search, marketing_source, user_preference that the app stores in a persistent cookie for analytics or personalization.
Keep reading the full chain
The remaining part includes the step-by-step PoC, exploitation code and the full chain that led to impact. Available to subscribers.
Practice this in a lab
Dos Via Waf Size
Keep learning · free account
Save your progress, unlock advanced payloads and rank your flags.
Related articles
Client-side admin bypass — boolean manipulation + BAC in a modern SPA
Real Quora report: SPA with an isAdmin boolean in localStorage that controls the UI + a backend that doesn't validate server-side. How to chain a boolean flip with BAC for admin takeover.
Cloudflare WAF — payload size bypass, oversized body, plan-specific limits
Bypassing the Cloudflare WAF by exploiting body size limits per plan (Free 100kb, Pro 100kb, Business 500kb, Enterprise 1mb): oversize payload trick + chunked transfer encoding.
Headless browsers — SSRF and RCE in endpoints that render URLs
Endpoints that accept URLs for screenshots/PDF (Puppeteer, Playwright, wkhtmltopdf) are an SSRF goldmine: cloud metadata, file://, gopher://, JS injection with XSS-to-RCE in the chromium sandbox.