We just completed our annual penetration test as part of our PCI DSS compliance, and we ran it with our AWS WAF (on CloudFront) fully active and in block mode. I wanted to share what we learned, because it was a real eye-opener about the difference between theory and practice.
Our setup uses the AWS Managed Rules for common threats (OWASP Core, known bad inputs, etc.) plus a few custom rules for our specific application logic. We felt pretty confident going in.
The testers still found several issues. Most were not direct "bypasses" of the WAF, but paths it simply doesn't cover:
* **Business logic flaws:** The WAF won't catch a flaw where you can manipulate internal IDs to access another user's data, as the requests look normal.
* **Rate limiting on specific endpoints:** Our global rate limits were good, but the testers hammered a costly API endpoint we hadn't considered, causing resource exhaustion.
* **Information leakage in error messages:** Some application errors bubbled up stack traces with internal info. The WAF allows valid requests that trigger these errors.
* **A sneaky parameter pollution case:** They used a combination of query parameters and body parameters with the same name to confuse our app. The request structure itself was valid, so the WAF didn't block it.
The main takeaway for our team was that the WAF is a critical, powerful filter for known attack patterns, but it's not an application security layer. It won't protect you from flaws in your own business logic.
Has anyone else been through this? I'm particularly curious:
* Did your testers find any *actual* WAF rule bypasses, or was it similar to our experience?
* What custom rules have you added post-test to close gaps?
* How do you structure your testing scope—do you test *against* the WAF or *with* it as part of the environment?
- h
Data is sacred.
Your point about parameter pollution is a classic example of where generic WAF rules fail. The managed rule sets look for specific, known malicious payloads in a single location, but they often don't analyze the combined semantics of a request where a parameter is defined in both the query string *and* the body. Your application might take the first or last instance, and an attacker can exploit that mismatch.
We saw something similar where the WAF passed a request because the SQLi attempt was split across a URL-encoded POST parameter and a plain-text JSON field in the same body. The individual pieces looked benign. You need to build a custom rule that examines parameter consolidation, but even that's a rabbit hole of application framework logic.
It reinforces that a WAF is just a filter, not a security model. Your pen test findings are basically a checklist for where you need actual application-level controls.
FinOps first, hype last
You've hit on such a crucial nuance. That scenario where attack payloads are split across different parts of a single request is a perfect, thorny example.
It reminds me of a case where our app accepted batch operations via JSON. The WAF inspected the individual JSON objects just fine, but an attacker nested a malicious payload across two separate objects where one provided the syntax opening and the other the closing exploit. Each piece was harmless alone. The WAF, seeing discrete objects, passed it through.
Building custom rules for this gets complex fast because you're essentially trying to reverse-engineer the application's parsing order and concatenation logic in a generic WAF rule. It often ends up being more practical to treat these findings as direct inputs for strengthening the app's own validation layers. The WAF can then act as a second, more generic line of defense for the simpler stuff.
Architect first, buy later