AWS WAF and Edge Protection: Testing What It Really Blocks

A web application firewall inspects the traffic that passes through it, which makes two questions worth answering. Does it block the attacks you care about, and can somebody reach your application without going through it at all? Managed rule groups give reasonable coverage of common patterns, and neither the vendor nor the OWASP Core Rule Set they draw from claims to be a substitute for fixing the application.

Reaching the origin directly

This is the first thing a tester checks and the most common finding. If the load balancer or server behind the firewall has a public address, an attacker who discovers it can request the application directly and every rule becomes irrelevant. Origin addresses leak through historic DNS records, certificate transparency logs, email headers and error pages. The fix is to restrict the origin so it accepts traffic only from the edge service, using a security group tied to the managed prefix list or a shared secret header the origin requires.

Where the rules stop applying

Inspection has limits worth knowing. Request bodies are only examined up to a size limit, so a large payload can carry an attack past inspection unless you configure the oversized handling deliberately. Content types the firewall does not parse receive less scrutiny than a form post, which matters for applications taking JSON or XML. Encoding variations, unusual character sets and parameter pollution all exist to defeat signature matching. None of these are exotic, and a tester will work through them methodically to find the one that gets through.

“The most useful test is the one where we ask you to allowlist us and then test without the firewall as well. You learn two things: what the application does when unprotected, which is the truth about its security, and how much your rules actually stop. Clients who only test through the firewall are measuring the firewall, not the application.”

William Fieldhouse, Director, Aardwolf Security Ltd

Tuning without breaking the site

Run new rules in counting mode first and read the results before enforcing, since managed groups block legitimate traffic in every application with a search box or a rich text editor. Look at what was counted, add exceptions narrowly by rule and path rather than disabling whole groups, then switch to blocking. Keep rate-based rules for the endpoints that matter, particularly login and password reset, and log everything to a destination you can query, because the logs are the only way to tell whether a spike is an attack or a broken integration.

What it is genuinely good for

Buying time is the honest answer. When a vulnerability is published in a framework you use, a firewall rule can hold the line for the days it takes to patch and deploy, and that is worth real money. It also blunts automated scanning and reduces noise. Treat it as a control that supports remediation rather than replaces it, confirm the origin restriction during AWS security penetration testing, and keep web app penetration testing focused on the application itself where the underlying flaws live.

Frequently asked questions about web application firewalls

These questions come up whenever edge protection is being configured.

Does a firewall satisfy a compliance requirement to fix a vulnerability?

Sometimes as a temporary compensating control, with documentation and a deadline. As a permanent answer it rarely survives an assessor’s question about what happens if the rule is bypassed.

Should the same rules apply to APIs?

Not the same rules. API traffic looks different from browser traffic, so managed groups tuned for web pages generate noise and miss API-specific abuse. Use rules built for the content type and rely on authorisation in the API itself.