Understanding WAF False Positives

A false positive is a legitimate request that the web application firewall treats as an attack. In Blocking mode, that means a real user or API client gets an error page instead of what they asked for.

False positives are normal, especially after a policy is first enforced or after an application changes. The goal isn't to eliminate them by switching protection off. It's to resolve each one as narrowly as possible.

Why false positives happen

• Generic attack signatures. Signatures look for patterns associated with attacks. Some legitimate content contains those patterns too, such as a search for a phrase containing SQL keywords or a rich-text editor that submits HTML.
• Application changes. New URLs, parameters, file types or API fields that the policy doesn't know about can trigger violations after a release.
• Strict parameter or length settings. A field that legitimately contains special characters, or longer values than expected, can trip a policy built on narrower assumptions.
• Structured content. JSON or XML payloads that don't match the configured content profile can raise violations.
• Unusual clients. Some clients, integrations and older libraries send requests that aren't strictly HTTP-compliant.

Investigating a block in BIG-IP ASM / Advanced WAF

1. Start with the support ID. The default blocking page shows a support ID. Ask the user for it, along with the time of the request.
2. Find the request in the event logs. In the configuration utility, the request log is under Security › Event Logs › Application › Requests. You can search by support ID.
3. Read the violations. Each request shows which violations it triggered, such as an attack signature, an illegal parameter, an illegal URL or file type, or an HTTP protocol compliance failure, along with the details that matched.
4. Note the violation rating. BIG-IP assigns a rating from 1 to 5 that estimates how likely the request is to be an attack. Low ratings on requests from known users often point to false positives, but the rating is a hint, not a verdict.
5. Confirm the request is legitimate. Check with the application owner. Can you reproduce it with normal use of the application? Is it one user, or everyone using a particular feature?

Fixing it narrowly

When a request is confirmed as legitimate, choose the smallest change that resolves it:

• Disable a signature only where it's needed. If a signature matches the legitimate content of one parameter, disable that signature for that parameter (or URL), not for the whole policy.
• Adjust the specific entity. Update the parameter, URL or content profile definition so it reflects how the application actually behaves.
• Avoid broad changes. Turning off a whole violation, removing a signature set, or putting the entire policy back into Transparent mode resolves one complaint by reducing protection for everything.
• Record every change. Note what was changed, why and for which request. Exceptions that nobody can explain later are difficult to remove safely.

Staging and learning

New signatures are often placed in staging. While in staging, matches are logged but not blocked, giving you a chance to see whether they would cause false positives before enforcing them. Review staged signatures and enforce them once you're confident, rather than leaving them in staging indefinitely.

The policy may also produce learning suggestions. Treat them as suggestions: accept the ones that reflect real application behaviour, and think carefully before accepting anything that would loosen the policy based on traffic you haven't verified.

When it's not a false positive

Sometimes the request really is malicious, or comes from a misbehaving integration. Then the right fix is in the client or the application, not the policy.

This article is general educational material. Menu locations and feature names can differ between BIG-IP versions, so check F5's documentation for your version.