AWS WAF & Shield Support
AWS WAF false positive tuning.
Managed rule groups protect well but will sometimes block real traffic, such as a rich-text editor, a JSON API or a legitimate partner. We find the exact rule that fired, test changes safely in Count mode and narrow only that rule, keeping protection everywhere else.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Customers report 403 errors on forms, uploads or API calls
- A new managed rule group was added and traffic dropped
- Blocked requests spike after a release
- You left rules in Count mode out of fear and never moved to Block
- Your own scanners or partners are being blocked
What you get
- The list of rules causing false positives with evidence
- Web ACL changes in infrastructure as code
- A tuning log documenting each exception
- Alarms on blocked request rate per rule
How we do it
A clear, safe process you can follow along with.
1. Confirm WAF is the cause
We match the user's 403 to WAF logs by request ID or timestamp, or check sampled requests in the web ACL, and confirm which rule and rule group terminated the request.
2. Identify the exact rule and field
Logs show terminatingRuleId, the rule group and which part of the request matched, such as body, cookie or a header. Knowing the field, not just the rule, lets us narrow the exception.
3. Switch the culprit to Count
Instead of removing a rule group, we override only the offending rule's action to Count, so every other rule keeps blocking and we can measure the effect.
4. Add precise exceptions
We prefer a scope-down statement or a rule placed before the group that allows a specific path, method or header, over disabling the rule everywhere. Labels added in Count mode let a later rule decide.
5. Test with real traffic
We replay the failing request and normal traffic patterns in a staging web ACL or watch Count results for a full business cycle before returning rules to Block.
6. Document and monitor
We record each exception and why it exists, set alarms on blocked request rates by rule and review them after application releases.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Disabling a whole rule group
That removes protection for everything. Override only the rule at fault.
Allowing by IP only
Source IPs change and are often shared. Scope exceptions by path and rule too.
Leaving rules in Count forever
Count is for testing. A rule left in Count does not protect you.
Skipping logging
Without logs you are tuning blind.
Frequently Asked Questions
How do I stop AWS WAF blocking legitimate traffic?
Find the rule from logs or sampled requests, change that rule to Count, add a narrow exception for the specific path or field, then test and keep other rules in Block.
What is Count mode in AWS WAF?
A rule in Count mode matches and records requests but does not block them, so you can see its effect before enforcing it.
Why are file uploads or large bodies blocked by WAF?
Body inspection has a size limit and some rules inspect the body. Uploads can trigger size or pattern rules, so we scope exceptions to the upload path.
Want Help With AWS WAF false positive tuning?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required