Symptoms
When F5 ASM starts blocking legitimate traffic, the symptoms can range from obvious to maddeningly subtle. The most common signal is users receiving an HTTP 403 Forbidden response with an F5 support ID embedded in the body — something like "Your support ID is: 14396929317839226498". That support ID is your golden ticket. Write it down immediately, because it maps directly to an event log entry that tells you exactly what the ASM flagged, why it flagged it, and which part of the request triggered the block.
Beyond the 403, you'll see HTTP 400 responses for API clients that have no idea what a WAF is, intermittent blocks affecting only specific geographic regions, or blocks that appeared immediately after a policy push or scheduled signature update. In my experience, the "it worked yesterday" complaint almost always points to one of two things: a signature database update that introduced a new false positive, or a policy change with an unintended side effect on traffic patterns the engineer didn't anticipate.
Other symptoms worth looking for include specific form fields or query parameters causing blocks while the rest of the application works fine, mobile app clients failing while browser traffic succeeds (or vice versa), API traffic rejected for specific content types or HTTP methods, and bulk traffic from CDN or proxy edge nodes being dropped entirely. The Event Logs in Security > Event Logs > Application > Requests give you the violation name, support ID, source IP, URI, and the exact string or pattern that triggered the block. Start there every single time.
Root Cause 1: Signature False Positive
Why It Happens
ASM attack signatures are pattern-based rules that match known attack strings — SQL injection patterns, XSS payloads, command injection sequences, path traversal strings. The problem is that legitimate application traffic can contain strings that look identical to those attack patterns. A product description field that contains the word SELECT or UNION will trip SQL injection signatures. A JavaScript-heavy single-page app that sends script tags inside JSON API payloads will trigger XSS signatures. This is one of the most common causes of false positives across every F5 ASM deployment I've worked on.
How to Identify It
In the ASM Event Logs, look for violations with the type Attack signature detected. Click into the blocked request and you'll see which signature fired, along with the matched content highlighted in the request body or parameter. The violation detail will look like this:
Violation: Attack signature detected
Signature Name: SQL-INJ and (select|update|insert|delete|drop|create) (2020502)
Matched parameter: item_description
Matched value: ...SELECT a premium product from our catalog...You can query signature information from the CLI on sw-infrarunbook-01:
tmsh show security shared-objects attack-signatures | grep -A 3 "2020502"To see which signatures are currently in blocking mode on your policy:
tmsh list security asm policy solvethenetwork_asm_policy signaturesHow to Fix It
The fix depends on how confident you are that the content is legitimate. If you're certain, create a signature exception scoped to the specific parameter or URL — never disable a signature globally at the policy level unless you have an extremely compelling reason. A global disable is a security hole waiting to be exploited.
To disable a specific signature for a named parameter via the CLI:
tmsh modify security asm policy solvethenetwork_asm_policy \
parameters modify {
item_description {
signature-overrides disable {
"SQL-INJ and (select|update|insert|delete|drop|create)"
}
}
}A better approach in production is to put the policy in transparent mode temporarily while you tune. This lets you observe what would be blocked without actually blocking it, giving you the data you need to build accurate, targeted exceptions before switching back to blocking mode.
Root Cause 2: Parameter Value Violation
Why It Happens
ASM learns about parameters over time — their names, expected value types (integer, string, email, date), and expected value lengths. When you enforce learned parameters, any value that falls outside those learned boundaries triggers a violation. This works great for catching unexpected input, but it breaks things fast when the application legitimately changes behavior. A new feature adds a longer text field, a parameter that was always numeric now sometimes carries a UUID, or a developer changes an integer field to accept decimal values. The WAF policy didn't get the memo.
How to Identify It
The event log violation will say Illegal parameter value or Parameter value does not comply with the defined constraint, with the parameter name, received value, and the constraint that was violated. Example:
Violation: Illegal parameter value
Parameter Name: order_qty
Received Value: 1500
Configured Maximum Numeric Value: 999To list all enforced parameters and their current constraints on the policy:
tmsh list security asm policy solvethenetwork_asm_policy parametersYou can also pull this via the iControl REST API if you prefer JSON output for scripting or comparison:
curl -sk -u infrarunbook-admin:AdminPass1! \
-X GET \
"https://192.168.10.245/mgmt/tm/asm/policies?\$select=name,id" \
-H "Content-Type: application/json"How to Fix It
Update the parameter definition to match the actual application behavior. Work with the developers to establish real boundaries — not what the policy learned from a week of traffic in staging — and enforce those. Don't leave constraints set to stale learned values and expect the application to conform.
tmsh modify security asm policy solvethenetwork_asm_policy \
parameters modify {
order_qty {
value-type user-input
maximum-value 9999
minimum-value 1
}
}After modifying parameters, apply the updated policy:
tmsh modify security asm policy solvethenetwork_asm_policy apply-policyRoot Cause 3: HTTP Protocol Violation
Why It Happens
HTTP protocol violations fire when ASM detects requests that deviate from the HTTP/1.1 or HTTP/2 specification — or from what the policy considers acceptable protocol behavior. Common causes include malformed headers, requests that include both Content-Length and Transfer-Encoding headers simultaneously, oversized headers, non-standard HTTP methods, or header values containing characters the policy flags as illegal. Mobile SDKs, custom HTTP clients written by developers who didn't read the RFC, and legacy enterprise applications are frequent offenders because they often make non-standard requests that a browser would never generate.
How to Identify It
The event log violation category will show as HTTP protocol compliance failed with a specific sub-violation. The ones I've seen most often in production:
Violation: HTTP protocol compliance failed
Sub-violation: Bad HTTP version
Violation: HTTP protocol compliance failed
Sub-violation: Chunked request with Content-Length header
Violation: HTTP protocol compliance failed
Sub-violation: Multiple Host headers
Violation: HTTP protocol compliance failed
Sub-violation: Unparsable request contentTo check which HTTP compliance checks are currently enforced on the policy:
tmsh list security asm policy solvethenetwork_asm_policy http-protocolsThe output will show each check with its alarm and block state:
security asm policy solvethenetwork_asm_policy http-protocols {
bad-http-version {
alarm enabled
block enabled
}
body-in-get-or-head-requests {
alarm enabled
block disabled
}
chunked-request-with-content-length-header {
alarm enabled
block enabled
}
multiple-host-headers {
alarm enabled
block enabled
}
}How to Fix It
If the violation is caused by a legitimate client behavior you can't change, disable the blocking action for that specific check while keeping the alarm active. Don't silence the alarm — you still want visibility into the traffic, you just don't want to block it.
tmsh modify security asm policy solvethenetwork_asm_policy \
http-protocols modify {
chunked-request-with-content-length-header {
alarm enabled
block disabled
}
}If the offending client is internal — a microservice, an internal tool, a monitoring agent — fix the client. Sending both Content-Length and Transfer-Encoding: chunked in the same request is a genuine HTTP specification violation and has been exploited in request smuggling attacks. Disable the check only as a last resort for traffic you genuinely cannot fix on the client side.
Root Cause 4: Geolocation Blocking
Why It Happens
F5 ASM can block traffic based on the geographic origin of the source IP address using MaxMind geolocation data bundled with BIG-IP. This is often configured intentionally — the business wants to block traffic from countries the application isn't licensed or authorized to serve. But it creates false positives when legitimate users travel, when corporate VPN or remote-access solutions egress from unexpected countries, or when the geolocation database has stale or incorrect data for a given IP range. I've also seen this break things when third-party SaaS services — payment processors, webhook providers, monitoring platforms — have infrastructure geolocated to a blocked country even though the service itself is entirely legitimate.
How to Identify It
In the event log, the violation will be Access from disallowed geolocation with the detected country listed alongside the source IP:
Violation: Access from disallowed geolocation
Source IP: 198.51.100.47
Detected Country: Netherlands
Allowed Countries: United States, Canada, United Kingdom
Action: BlockTo check which countries are currently blocked on the policy:
tmsh list security asm policy solvethenetwork_asm_policy geolocationTo verify how a specific IP is being resolved by the BIG-IP geolocation engine:
geoip_lookup 198.51.100.47The output includes the country, region, city, and ISP as the BIG-IP database sees them. If the geolocation data is wrong for that IP, that's a database accuracy issue, not a configuration issue, and it requires a database update rather than a policy change.
How to Fix It
If the geolocation database has stale data, update it:
tmsh install sys geoip-updateIf the IP is correctly geolocated but the country is on your block list and the traffic is legitimate, add the specific IP or subnet to an exception list that bypasses geolocation enforcement:
tmsh modify security asm policy solvethenetwork_asm_policy \
ip-exceptions add {
198.51.100.47 {
ignore-ip-reputation enabled
block-geo-location disabled
}
}For corporate VPNs that egress from multiple countries, add the VPN egress IP ranges to the exception list rather than opening entire countries in the block policy. That's a much narrower and safer change. The goal is to unblock the specific IP ranges you trust, not to weaken the geolocation policy across the board.
Root Cause 5: IP Reputation Blocking
Why It Happens
ASM's IP reputation feature uses a dynamically updated feed of known malicious IP addresses — Tor exit nodes, botnet command-and-control infrastructure, open proxies, scanners, spam sources — maintained by F5 and updated on a regular schedule. The feed is generally accurate, but it's not perfect. Shared hosting environments, cloud provider NAT gateway ranges, CDN edge nodes, and large corporate egress IPs can all end up on reputation lists if any previous tenant or user of that IP range engaged in malicious activity. I've personally dealt with a CDN edge IP flagged as a Tor exit node, and an AWS NAT gateway flagged as a known scanner — both caused production incidents because the IP reputation block fired on legitimate application traffic.
How to Identify It
The event log violation will read Access from IP address with bad reputation with the specific reputation category listed:
Violation: Access from IP address with bad reputation
Source IP: 203.0.113.85
Reputation Category: Tor Proxy
Action: BlockTo check which reputation categories are currently enabled for blocking on your policy:
tmsh list security asm policy solvethenetwork_asm_policy ip-intelligenceTo verify the current state of the IP Intelligence feed — version, last update time, and record counts:
tmsh show sys ip-intelligence statusThe output will tell you when the feed was last updated. If it's more than 48 hours stale, the subscription or the download schedule may have an issue worth investigating separately from the false positive itself.
How to Fix It
For a specific IP that's incorrectly flagged, add it to the ASM IP exception list with reputation checks disabled:
tmsh modify security asm policy solvethenetwork_asm_policy \
ip-exceptions add {
203.0.113.85 {
ignore-ip-reputation enabled
}
}For an entire IP range — a CDN's edge node subnet, for example — add the full CIDR block as an exception. Then apply the policy:
tmsh modify security asm policy solvethenetwork_asm_policy \
ip-exceptions add {
203.0.113.0/24 {
ignore-ip-reputation enabled
}
}
tmsh modify security asm policy solvethenetwork_asm_policy apply-policyAlso consider whether every reputation category actually warrants a hard block. Tor exit nodes are a reasonable block in most consumer-facing apps. But categories like spam-sources or scanners can be overly broad and will false-positive more often in environments with shared or cloud egress IPs. Tune these categories to alarm-only mode if blocking is causing false positives and you can't justify the breadth of the rule:
tmsh modify security asm policy solvethenetwork_asm_policy \
ip-intelligence modify {
categories modify {
spam-sources {
block disabled
alarm enabled
}
}
}Root Cause 6: Cookie Violation
Why It Happens
ASM can enforce cookie integrity by tracking which cookies the application sets and flagging any cookie in a request that wasn't issued by the server or that appears to have been modified in transit. This is a solid security control for detecting session tampering, but it breaks things when browsers have cached cookies from a previous application version, when the application changes its cookie names or structure without a corresponding WAF policy update, or when third-party services — analytics platforms, A/B testing tools, tag managers — inject cookies that ASM doesn't recognize.
How to Identify It
Violation: Illegal cookie
Cookie Name: _ab_test_variant_3
Violation Detail: Cookie not defined in policy
Action: BlockList all cookies currently defined in the policy:
tmsh list security asm policy solvethenetwork_asm_policy cookiesHow to Fix It
Add the missing cookie to the policy as an allowed cookie. For third-party cookies with dynamic naming conventions, use a wildcard match so you don't have to add each variant individually:
tmsh modify security asm policy solvethenetwork_asm_policy \
cookies add {
_ab_test_variant_* {
enforcement-type allow
type wildcard
}
}
tmsh modify security asm policy solvethenetwork_asm_policy apply-policyRoot Cause 7: File Type Violation
Why It Happens
ASM policies can maintain an explicit allowlist of permitted file types based on URL extensions. If the policy is set to allow only specified file types and the application starts serving a new type that isn't in the list — a
.wasmfile for WebAssembly modules,
.avifimages, or a new
.graphqlendpoint path — those requests are blocked. This almost always happens when a developer deploys a new feature or technology without looping in whoever manages the WAF policy.
How to Identify It
Violation: Illegal file type
Requested URL: /static/bundle/app.wasm
File Type: wasm
Allowed File Types: html, js, css, png, jpg, gif, ico, json, xml, svg
Action: BlockCheck the policy's current file type configuration:
tmsh list security asm policy solvethenetwork_asm_policy file-typesHow to Fix It
Add the new file type to the allowed list and apply the policy:
tmsh modify security asm policy solvethenetwork_asm_policy \
file-types add {
wasm {
allowed enabled
check-post-data-length disabled
}
}
tmsh modify security asm policy solvethenetwork_asm_policy apply-policyPrevention
Most false positive incidents are preventable with disciplined operational habits. The most important one is change management alignment: whenever the application changes — new endpoints, new parameters, new file types, new cookies — the WAF policy review should happen in the same change window. Developers shouldn't be deploying new features on Friday afternoon and discovering the WAF is blocking them on Monday morning because nobody updated the policy.
Put new ASM policies and significant policy changes through a transparent mode period before switching to blocking. Set the policy to transparent, let it absorb real production traffic for a few days, review the event logs for false-positive patterns, tune them out, then flip to blocking. This is especially critical after F5 signature database updates, which ship new signature IDs that can introduce false positives for content patterns that were perfectly fine the day before.
tmsh modify security asm policy solvethenetwork_asm_policy enforcement-mode transparent
# Review event logs for several days, tune exceptions, then:
tmsh modify security asm policy solvethenetwork_asm_policy enforcement-mode blockingSet up automated alerting for spikes in blocked request counts. A sudden 10x increase in blocked events right after a deployment is almost certainly a false positive situation, not a coordinated attack. BIG-IP emits syslog and SNMP traps for ASM violation thresholds — wire these into your monitoring stack so on-call engineers see the spike before users start calling.
Maintain a documented IP exception list for known-good infrastructure: CDN edge node ranges, corporate VPN egress IPs, monitoring system source IPs, partner API gateway IPs. Review this list quarterly. Don't just add IPs and forget — if those IP ranges change or are reallocated, you want to catch that before it becomes either a security gap or a false positive.
Finally, build a regular habit of reviewing ASM's Learning Suggestions. The learning engine watches real traffic and flags patterns that look like legitimate application behavior — it'll propose adding parameters, file types, URLs, and cookies to the policy. A weekly review and selective acceptance of these suggestions keeps the policy current without requiring manual intervention for every application change:
tmsh show security asm learning-suggestions policy solvethenetwork_asm_policyWhen a support ID shows up in a user complaint, resolve the event log entry within the hour. Log entries age out, and if you wait too long, the context is gone. Every resolved false positive should feed back into your tuning process — if it happened once, it will happen again unless you fix the underlying policy gap, not just the immediate block.