Peakhour.IO - WAF

How to Tune F5 BIG-IP Advanced WAF

2026-07-29T10:15:00+10:00

An F5 policy has three separate controls between a signature match and a blocked request.

The policy has an enforcement mode. Each violation has Learn, Alarm and Block settings. Each signature or policy entity can also be in staging.

Record all three before changing the policy.

Start a new policy in Transparent mode

Set a new policy, a major policy revision or a newly protected application to Transparent under Security > Application Security > Policy Building > Learning and Blocking Settings.

Transparent mode allows requests through while the policy records violations. F5 normally generates a learning suggestion when the violation has Learn enabled. Save the change and select Apply Policy.

Blocking mode behaves differently. A request is blocked only when the policy is in Blocking mode, the violation has Block enabled and the matching entity or signature has left staging. F5 documents the interaction between enforcement mode, violation actions and staging.

F5 calls the staging window the Enforcement Readiness Period. The default is seven days. During that period, the policy does not enforce staged signatures or entities. Configure learning and logging to capture their matches. The policy settings guide explains Transparent mode and enforcement readiness.

Seven quiet days prove only that the traffic seen during those days was quiet. Include month-end jobs, imports, account recovery, administration, checkout, API writes and other flows that ordinary browsing misses.

For an established blocking policy, stage the signatures or entities affected by a change. The rest of the policy can remain in force while those changes collect traffic.

Log staged signature matches

The default logging profile records illegal requests. A staged attack-signature match can be allowed and therefore needs an explicit logging choice.

Create or edit an application-security logging profile under Security > Event Logs > Logging Profiles. Set the request filter to Illegal requests, and requests that include staged attack signatures. Associate the profile with the virtual server that runs the security policy.

F5 supports local and remote logging profiles. Local logging competes for resources on the BIG-IP system; remote logging can send CSV, key-value or CEF records to a reporting system. F5 documents the logging destinations, staged-signature filter and virtual-server association.

Keep these fields for each investigation:

security policy and virtual server;
support ID and event time;
hostname, URL and method;
violation name;
attack-signature ID and attack type;
parameter, cookie, header or request area that matched;
matched data;
violation rating;
enforcement mode and staging state;
application response.

The support ID ties a user-facing block page to the stored request. The violation rating runs from 1 to 5. F5 describes 1 as most likely a false positive and 5 as most likely an attack. Use the rating to order the work, then read the request and ask the application owner what the input means. F5 lists the request details and explains violation ratings.

Group events by policy, violation, signature ID, URL, method and named request field. A signature firing in comment on POST /api/tickets needs a different review from the same signature firing in an authentication parameter.

Request logs may contain credentials, personal information and customer text. Mark account numbers, tokens and other secrets as sensitive parameters so F5 masks their stored values. F5 documents the sensitive-parameter setting and log masking.

Read the request behind each learning suggestion

Traffic Learning turns observed violations and new entities into proposed policy changes. Open Security > Application Security > Policy Building > Traffic Learning, select the policy and inspect the requests attached to each suggestion.

Accept Suggestion changes the policy. Treat it like any other configuration change.

Manual learning waits for an operator to accept a suggestion. Automatic learning can apply most suggestions after F5 has seen enough traffic, sessions, time and source addresses. Manual learning keeps each relaxation visible while a new or sensitive application is being tuned. F5 describes Manual, Automatic and Disabled learning modes.

A busy suggestion can still describe a busy attack. Confirm that the requests reached the expected application path, parsed successfully and produced the expected business result.

Ask the developer who owns the endpoint:

what values the field accepts;
how the application parses them;
whether the value is stored, rendered or executed;
which server-side validation protects it;
whether the field has the same meaning on every URL;
which test request reproduces the legitimate match.

Accept a suggestion only after its scope matches the application behaviour. Ignore removes a suggestion from the normal Traffic Learning view; it does not repair a false positive. F5 lets operators accept, delete or ignore suggestions and inspect the requests behind them. The Traffic Learning guide documents those actions.

Check how F5 parsed the body

A JSON request treated as unparsed content produces different signature targets from a JSON request split into named parameters.

Check the allowed URL and its Request Body Handling setting. F5 can parse form data, JSON or XML, or scan an unparsed payload with content and value signatures. A JSON or XML setting also names the content profile used for validation. F5 lists the request-body handling modes in its allowed-URL documentation.

Match the profile to the content type the application accepts. Associate the profile with the correct URL or parameter. Reproduce malformed bodies with the same bytes because the application and F5 may recover from parser errors differently.

Use explicit parameters for fields that need their own policy. F5 supports global, URL and flow parameters, and applies the most specific definition first: flow, then URL, then global. A free-text comment field on one endpoint usually belongs at URL level.

The Ignore value parameter type removes parameter-based signature checks from that value while leaving other relevant signature checks active. A one-signature override removes less inspection. Reserve Ignore value for data the application genuinely does not interpret.

Put the exception on the field or URL that needs it

F5 exposes several scopes for an attack-signature override:

one signature on one URL parameter;
one signature on one named cookie;
one signature in a content profile;
one signature on an allowed URL;
one signature across the security policy.

Choose the scope that matches the application.

For a false positive in comment on /api/tickets, define comment as a URL parameter and disable the signature for that parameter. The same signature continues to inspect other parameters and other URLs.

F5 also allows a signature override on an allowed cookie. Use that control when a named analytics or session-related cookie carries the legitimate value. Cookie names and values have their own configuration, so record which part produced the match.

A content-profile override applies wherever that JSON, XML or plain-text profile is associated. Check every URL and parameter using the profile before changing it. F5 documents signature overrides and associations for JSON profiles.

An allowed-URL override disables the selected signature for the whole URL. Every request field on that URL receives the exception. F5 describes URL-level signature overrides as a common operation and marks overridden signatures in the policy list. The allowed-URL and cookie procedures describe their attack-signature overrides.

Disabling a signature at policy level removes it from the whole application-security policy. Use that scope only when the signature is irrelevant to every request covered by the policy.

Record the signature ID, signature revision, URL, parameter or cookie, matched examples, application owner and protections that remain.

Apply, synchronise and test the policy

Saving an edit does not put it into the active policy. Select Apply Policy, wait for the operation to finish and confirm that the virtual server still has the intended application-security and logging profiles.

Synchronise the change to the peer device when the BIG-IP pair uses manual ConfigSync. F5 can display a sync reminder after policy changes in a high-availability configuration. The Advanced WAF preferences guide describes Apply Policy confirmation, change logging and the ConfigSync reminder.

Replay:

the original legitimate request;
the same value in another parameter;
the same value on another URL;
a safe signature test in the excluded field;
the safe test in a neighbouring field;
malformed and oversized versions of the request;
normal application traffic.

The legitimate request should complete without the false-positive event. The safe test in the excluded scope shows the inspection removed by the exception. Neighbouring fields and URLs should still produce the expected signature event.

Check the support ID, signature ID, staging state and application response after every replay.

Compare and export the policy

Use Security > Application Security > Security Policies > Policy Diff to compare the tuned policy with the earlier policy or a staging copy. F5 can compare active, inactive and exported policies.

Export the policy before a large tuning session, signature update or BIG-IP upgrade. A readable XML export supports review and version control; a binary policy archive preserves a restorable copy.

Compact XML omits attack-signature staging state and omits some settings that remain at their defaults. Use the full XML format when the review needs to show staging. Export user-defined attack signatures separately because a policy export contains their sets without the signatures themselves. F5 documents Policy Diff and the export-format limits.

Stage signature updates and application releases

F5 Live Update places newly added attack signatures in staging. Updated signatures follow the policy's Updated Signature Enforcement setting. Review that setting before installing an attack-signature update. F5 documents the post-update staging behaviour.

Keep signature staging enabled during the observation period. Review each high-volume match, then enforce the signatures that have clean traffic and tested application flows.

Run the same process after an application release that changes:

public URLs or methods;
parameter names or value types;
JSON, XML, GraphQL or multipart bodies;
cookies and headers;
uploads;
authentication and account flows.

Tell the application team which policy changes are waiting in staging. The application team knows whether a new field belongs in the release.

Keep rate limiting in the DoS profile

F5 application-security policies inspect individual requests. BIG-IP Layer 7 DoS protection measures transaction rates and server latency through a separate DoS profile attached to the virtual server.

Configure rate limiting under the DoS profile when repeated traffic is the problem. F5 can rate limit suspicious source addresses, countries, URLs or a site under attack. Transparent and Blocking modes for the DoS profile control whether those conditions are reported or mitigated. F5 documents TPS-based detection, stress-based detection and request rate limiting.

Track WAF signature blocks and DoS rate limits as separate outcomes. A false-positive signature needs a policy exception. The application owner must set an acceptable rate and response for excessive legitimate traffic.

Move the policy to Blocking

Switch the policy from Transparent to Blocking after:

normal and infrequent application flows have run;
every repeated legitimate match has been classified;
each exception has the smallest supported scope;
staged entities and signatures have been reviewed;
Learn, Alarm and Block settings match the intended response;
the replay tests pass;
the active and standby devices have the same applied policy.

Move a small application or virtual server first when the deployment supports it. Watch blocked requests, application errors and business transactions together.

The blocking response includes a support ID. Keep the event long enough for support staff to find the exact request without storing customer content in the exception record.

Review the policy after each application release and signature update. Remove an override when the field, parser or application behaviour that required it has gone.

How to Tune Google Cloud Armor WAF Rules

2026-07-29T10:00:00+10:00

Cloud Armor evaluates security-policy rules by priority. The request log shows the preview rule that matched and the enforced rule that decided the request.

An allow rule at priority 100 accepts the request before a SQL injection rule at priority 1000 can inspect it. A WAF rule in preview records the action it would have taken while an enforced rule decides the request.

Preview one WAF rule

Cloud Armor preview belongs to individual security-policy rules. The configured action is recorded while policy evaluation continues to an enforced rule. Both results appear in the request log when the preview rule takes priority. Google documents this evaluation behaviour and the --preview flag.

The commands below use a global service-level security policy. Add --region=REGION to each command when working with a regional policy.

Create or update the WAF rule with a deny action and preview enabled:

gcloud compute security-policies rules create 1000 \
    --security-policy app-policy \
    --expression "evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})" \
    --action deny-403 \
    --preview \
    --description "SQLi v4.22 sensitivity 1"

Sensitivity 1 is a sensible starting point for most applications. It enables the higher-confidence signatures and usually produces less noise than higher levels. Google recommends starting new preconfigured WAF rules at sensitivity 1 and validating them in preview. The current Cloud Armor best-practices guide gives both recommendations.

Read both policy results in the request log

Cloud Armor adds its policy results to the load balancer’s per-request log. Request logging is disabled by default for new backend services, so enable it before starting the preview. Look for previewSecurityPolicy to see the preview match and enforcedSecurityPolicy to see the enforced result. The preconfiguredExprIds array contains every WAF signature that triggered the matching policy rule. Google lists the logging prerequisite and policy fields in the Cloud Armor request-logging reference.

A Logs Explorer query can isolate the preview rule:

resource.type="http_load_balancer"
jsonPayload.previewSecurityPolicy.name="app-policy"
jsonPayload.previewSecurityPolicy.priority=1000

Group the results by:

preconfiguredExprIds;
request path and method;
preview rule priority;
enforced outcome;
client or application flow;
time and release version.

Use our general WAF tuning guide to classify those repeated matches and choose the smallest safe exception.

Enable verbose logging for a short investigation when the ordinary log shows the signature but omits the input. It adds matchedFieldType, matchedFieldName and a short matchedFieldValue snippet for requests matching preconfigured WAF rules. Those snippets can contain customer or personal data. Google recommends disabling verbose logging during normal operation. The verbose-logging guide describes the extra fields and privacy risk.

Match the signature ID to the ruleset version

The name sqli-v422-stable identifies the SQL injection ruleset built from CRS 4.22. A signature inside it has the same version in its ID, such as:

owasp-crs-v042200-id942350-sqli

Use the ID written by the policy log. Cloud Armor requires an opted-out signature ID to match the ruleset version, and rejects mismatched versions. Google shows the versioned naming and requirement in its WAF tuning guide.

A ruleset upgrade can add or change signatures. Put the new version in preview, compare its matches with the enforced version and promote it after reviewing the result.

Google also publishes canary rulesets. Its recommended arrangement runs the canary at a higher priority in preview and the stable ruleset at a lower priority in enforcement. The canary records the requests it would deny while the stable rule protects the service. Google describes this stable-and-canary arrangement in its best practices.

Choose the sensitivity level first

Sensitivity levels run from 0 to 4. Choosing level 2 enables signatures at levels 1 and 2. Higher levels inspect for more patterns and tend to produce more false positives. Level 0 enables no signatures unless you explicitly opt them in. Google maps Cloud Armor sensitivity to CRS paranoia levels in the tuning documentation.

Choose a level that fits the application and the time available to investigate. A public marketing site with conventional inputs may run cleanly at a higher level. An API accepting templates or query fragments may need more work.

Keep the chosen sensitivity and exclude the named field from the affected signature.

Opt out one noisy signature

If a signature is irrelevant wherever the policy rule applies, list its versioned ID in opt_out_rule_ids:

evaluatePreconfiguredWaf(
  'sqli-v422-stable',
  {
    'sensitivity': 2,
    'opt_out_rule_ids': [
      'owasp-crs-v042200-id942350-sqli'
    ]
  }
)

The WAF rule runs every SQL injection signature enabled at sensitivity 1 and 2 except the named signature.

Use an opt-out after reviewing where the policy rule applies. A rule matching every request to a shared backend gives the exception the same reach.

Enable selected signatures at sensitivity 0

Set sensitivity to 0 when the rule needs only a few named signatures:

evaluatePreconfiguredWaf(
  'xss-v422-stable',
  {
    'sensitivity': 0,
    'opt_in_rule_ids': [
      'owasp-crs-v042200-id941150-xss'
    ]
  }
)

Cloud Armor permits opt_in_rule_ids only at sensitivity 0. Google recommends this approach when you want fewer signatures than you would otherwise opt out. The setup guide documents the constraint and provides current CLI examples.

An opt-in rule enables only the named signatures for the traffic matched by that policy rule. Record why each signature was selected and when to review the set.

Exclude the field that carries legitimate content

A request-field exclusion keeps a signature active and removes a selected input from its inspection.

Cloud Armor can exclude named header values, cookie values, query-parameter values and URIs from an entire preconfigured ruleset or selected signatures. Header, cookie and query-parameter names remain inspected when their values are excluded. URI exclusions remove the matching URI from inspection for the selected target. Google documents each field’s behaviour and available match operators.

Suppose the cookie analytics_id repeatedly triggers signature 942100. Add an exclusion to the existing SQLi policy rule:

gcloud compute security-policies rules add-preconfig-waf-exclusion 1000 \
    --security-policy app-policy \
    --target-rule-set sqli-v422-stable \
    --target-rule-ids owasp-crs-v042200-id942100-sqli \
    --request-cookie-to-exclude "op=EQUALS,val=analytics_id"

The signature continues to inspect the cookie name and every other request field, excluding only the value of analytics_id.

Request query parameters need one extra check. Cloud Armor rebuilds the URI and request line after removing an excluded query parameter. A signature that inspects the entire REQUEST_BODY continues to inspect it, so the same parameter can trigger a body-wide signature. Google calls out this behaviour in the query-parameter exclusion documentation.

A policy rule with request-field exclusions cannot use the allow action. Use the WAF’s deny action and let unmatched requests continue through the policy. This restriction appears in the current preconfigured WAF limitations.

Apply the tuned WAF rule to one route

Cloud Armor uses Common Expression Language expressions for advanced matches. Combine the route condition and WAF evaluation in one rule when an exception belongs to one application area:

request.path.startsWith('/api/messages') &&
evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})

Create a separate SQLi rule for the rest of the application and exclude /api/messages from its expression. The route is then evaluated once under the tuned rule.

!request.path.startsWith('/api/messages') &&
evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})

Priority decides which matching rule takes effect. A smaller number has higher priority. An earlier allow rule ends evaluation for the matching request, so later WAF rules never see it. Google explains the evaluation order and demonstrates the effect of an early allow.

Replay three requests when testing route logic:

a legitimate request containing the known false-positive value;
an attack string in the excluded field;
an attack string in another field.

The legitimate request should pass. The attack string in the excluded field shows the exposure created by the exception. The attack string in another field should still trigger the WAF rule.

Set the request-body inspection limit

Cloud Armor inspects a configurable prefix of the request body: 8, 16, 32, 48 or 64 kB. The limit applies across the preconfigured WAF rules in the policy, and 64 kB is the maximum. Content after the limit can reach the backend without WAF body-signature inspection. Google documents the available sizes and provides the policy update command.

Choose the size from the requests the application accepts. Check uploads, GraphQL, JSON APIs and form submissions separately. Google supports parsed URL-encoded and JSON bodies; other content and encodings, including XML, gzip, UTF-16 and multipart form data, receive rules over raw data. The security-policy overview describes the current body parsing behaviour.

Verbose logs include inspectedBodySize, which helps confirm the active limit. Decide how the application handles larger bodies. Google suggests a separate content-length rule when the application can safely reject requests beyond the inspection limit, though Content-Length deserves the same validation you would apply to any client-supplied header.

Identify who manages the policy

Service-level backend security policies attach to backend services. Send their false positives to the team that manages the backend policy.

Hierarchical policies attach at the organization, folder or project level and flow down to projects. Send inherited false positives to the team that manages the hierarchical policy.

Creating a hierarchical security policy requires Cloud Armor Enterprise Paygo and can enrol the project automatically. Google documents the commercial requirement and ownership model in the hierarchical policy guide.

Include the matched policy name and priority in each false-positive report. Give the policy team the field, route and application behaviour needed to review the exception.

Hierarchical and service-level policies support different feature sets. Check the current feature table before moving a tuned rule between them. Google maintains the comparison in its security-policy overview.

Disable preview after reviewing the matches

Run normal traffic, scheduled jobs and important application flows through the preview rule. Classify each recurring signature and field, then disable preview:

gcloud compute security-policies rules update 1000 \
    --security-policy app-policy \
    --no-preview

Cloud Armor rule changes usually take several minutes to propagate. Watch the enforced policy outcome after the change and replay the requests used during tuning. Google lists propagation time among the preconfigured WAF limitations.

Keep the previous expression and exclusions in version control. Record the policy, priority, ruleset version, sensitivity, signature IDs, excluded fields and test requests.

How to Tune Cloudflare WAF When Rule 949110 Blocks a Request

2026-07-29T09:45:00+10:00

Rule 949110 blocked the request.

In Cloudflare's OWASP managed ruleset, 949110: Inbound Anomaly Score Exceeded checks the total score produced by earlier detections. The rules that raised the score explain the block.

Cloudflare puts that answer in Additional logs.

Start with the blocked event

Open Security > Events in the Cloudflare dashboard and filter to the hostname, path, action and time of the request.

Security Events shows traffic that Cloudflare acted on or flagged. Its top-level views group events by fields such as action, host, country and service. The sampled log beneath them contains a subset of individual security events, so a busy time range may hide the request you need. Narrowing the time range reduces sampling. Cloudflare documents the Security Events views and sampling behaviour.

Capture the details that identify the request:

Ray ID;
timestamp;
hostname and path;
method;
WAF service and action;
displayed rule ID and description;
the application result reported by the user.

One request can produce more than one security event. Keep the Ray ID and timestamp together while you follow the detections.

If the displayed description is 949110: Inbound Anomaly Score Exceeded, open Additional logs. Cloudflare places the OWASP rules triggered by that request there. The Security Events documentation describes those contributing OWASP records.

Additional logs deserve a manual check in the dashboard. Cloudflare says triggered OWASP rules shown there are absent from exported Security Events JSON. A log export containing only the final event can therefore leave out the detections that built the anomaly score. The Security Events documentation records that export limitation.

Find the rule that raised the score

Additional logs may show one contributing rule or several. Record each rule's description and Cloudflare rule ID.

The description may begin with a familiar CRS-style number. Cloudflare's API and exception controls use Cloudflare's opaque rule ID. Use the identifier displayed by Cloudflare when you configure the rule.

Group repeated matches by rule, field and route, then review each group with the application owner. A single support message containing SQL syntax may be legitimate. Different paths or different rules belong in separate investigations. The general WAF tuning guide explains how to classify each group and record an exception.

Ask the developer who owns the route:

what input the endpoint accepts;
whether the request was parsed successfully;
where the matching value is stored or rendered;
which validation runs at the application;
whether the field can carry executable syntax by design.

Choose an override or an exception

An override changes the configuration of a managed rule or ruleset across that deployment. You can change an action, disable selected rules or adjust settings such as the OWASP anomaly score threshold and paranoia level.

An exception matches a set of requests and skips selected managed rules for those requests. Its expression can use the host, URI path, method and other Cloudflare Rules language fields.

Use an override when the rule itself needs a different action across the deployment. Use an exception when a known application route needs different treatment.

Cloudflare allows exceptions to skip:

every remaining managed rule;
one or more managed rulesets;
one or more rules inside managed rulesets.

Select the contributing rule. A whole-ruleset exception removes far more inspection from the matching request. Cloudflare documents the three exception types and their order of precedence.

For a false positive confined to message creation, the expression could be:

http.host eq "api.example.com"
and http.request.uri.path eq "/v1/messages"
and http.request.method eq "POST"

Choose the Cloudflare rule ID found in Additional logs as the rule to skip.

Cloudflare skips that rule for the complete matching request. Another field on POST /v1/messages can trigger the same rule and receive the same exception. Record that consequence.

Place the exception before the managed ruleset

An exception works only on managed-ruleset execution rules listed after it in the same phase. Put the skip rule before the rule that executes the OWASP managed ruleset. Cloudflare's API documentation states that skip rules affect only later execute rules.

Cloudflare can run managed rulesets at account level on Enterprise plans and at zone level. Account-level rulesets execute before zone-level rulesets. An account-level exception affects account-level rules, while a zone-level exception affects zone-level rules. A zone exception cannot prevent an account-level rule from matching first. Cloudflare documents this scope and evaluation order.

Find the execute rule that produced the event. Add the exception at that level and before that execution. If the OWASP ruleset runs at both levels, inspect both deployments and decide which one needs the exception.

Exceptions take priority over overrides. Cloudflare records that precedence in its managed-ruleset documentation.

Test the exception through Cloudflare

Send the original legitimate request through the hostname proxied by Cloudflare. An origin-only replay bypasses the configuration you are testing.

Use a small test set:

the legitimate request on the exempt route;
the same input on another route;
a safe request that triggers the contributing rule on the exempt route;
the same test outside the exception;
normal traffic that should pass unchanged.

Check Security Events after each request. Confirm the Ray ID, action, contributing rules and final result.

The safe trigger on the exempt route shows what the exception allows. The same trigger outside the exception should still raise the contributing rule and reach 949110.

Cloudflare evaluates security products and rules in a defined sequence, and a terminating action stops later evaluation. An earlier custom-rule Block or Managed Challenge can determine the result before Managed Rules run. Cloudflare's WAF concepts guide describes this rule execution behaviour.

Set the anomaly threshold from real traffic

The OWASP anomaly threshold is the cumulative request score at which 949110 applies the configured action. Raising it moves the block point for every request covered by that deployment.

Use Security Events to see which rules contribute to normal requests before changing the threshold. A repeated false positive from one rule and one endpoint points towards an exception. A broad pattern of low-confidence detections may justify a threshold or paranoia-level review.

Cloudflare supports overrides for the full ruleset, rule tags and individual rules. Tag and ruleset overrides can also affect future rules that Cloudflare adds under those selections. Individual rule overrides target the rule IDs you chose. The managed-ruleset documentation explains these override levels.

Test a threshold change with the same care as a rule exception. It changes when 949110 acts across all covered traffic.

Record the exception and its rule IDs

Document:

the Ray IDs and event times reviewed;
the contributing Cloudflare rule IDs and descriptions;
the anomaly threshold and paranoia level;
the exception expression;
the account or zone deployment it belongs to;
its position before the managed-ruleset execute rule;
what the selected rule stops inspecting;
the developer who confirmed the application behaviour;
the requests used for verification;
the review date.

Recheck the exception after application changes and Cloudflare managed-rule updates. A new route can need different conditions. A revised rule can remove the original false positive.

Rule 949110 applies the configured action when the anomaly score crosses the threshold. Tune the rules that supplied the false-positive score.

How to Tune Azure Application Gateway WAF

2026-07-29T09:30:00+10:00

An Azure WAF false positive usually arrives as a 403 and a complaint.

Treat the 403 as the start of the investigation. The firewall log identifies the rule, the relevant part of the request and the policy that applied.

Put new policies into Detection mode

Use Detection mode while introducing a WAF policy, upgrading its managed ruleset or placing an existing application behind Application Gateway. The WAF records rule matches while every request continues to the application.

Microsoft suggests reviewing one to two weeks of traffic before returning the policy to Prevention mode. Plan and supervise that period because attacks also continue to the application. Microsoft documents this rollout in its Application Gateway WAF troubleshooting guide.

Before changing the mode, save the complete policySettings block:

az network application-gateway waf-policy show \
    --name "$WAF_POLICY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --query policySettings \
    --output json

The Azure CLI command az network application-gateway waf-policy policy-setting update rewrites the policy settings. Microsoft warns that omitting --request-body-check silently resets the setting to false. Supply the current value when switching modes, then read the policy back and verify it. The warning and corrected commands appear in Microsoft’s current troubleshooting procedure.

For a policy that already inspects request bodies:

az network application-gateway waf-policy policy-setting update \
    --policy-name "$WAF_POLICY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --state Enabled \
    --mode Detection \
    --request-body-check true

Use the value returned by the first command.

Send the firewall log to Log Analytics

Application Gateway produces access and firewall logs through Azure Monitor. Microsoft recommends the resource-specific Log Analytics tables for new diagnostic settings. WAF events then appear in AGWFirewallLogs; the older Azure Diagnostics mode writes them to AzureDiagnostics. Microsoft explains both collection modes and recommends the resource-specific tables.

Check which table receives your data before borrowing a query from another subscription.

For a resource-specific table, start here:

AGWFirewallLogs
| where TimeGenerated > ago(7d)
| where Action in ("Detected", "Matched")
| summarize
    Events = count(),
    Requests = dcount(TransactionId),
    Paths = make_set(RequestUri, 20)
  by RuleId, Message, PolicyScope, PolicyScopeName
| order by Events desc

For a workspace using the older shared table:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s in ("Detected", "Matched")
| summarize
    Events = count(),
    Requests = dcount(transactionId_s),
    Paths = make_set(requestUri_s, 20)
  by ruleId_s, ruleGroup_s
| order by Events desc

The current AGWFirewallLogs schema records the policy ID, policy scope and transaction ID. The transaction ID joins several rule events produced by one request.

Open the highest-volume group first. Inspect several transactions and compare each rule message with the input the application expects.

Find the field that caused the match

Suppose rule 942100 appears on POST /api/messages. The endpoint accepts customer support text, and messages containing database errors trigger the SQL injection rule.

The general WAF tuning guide explains how to classify the match. The Azure log supplies the rule, field and policy.

Confirm four things before adding an exception:

the same field causes the repeated matches;
the application expects free text in that field;
the requests complete normally in Detection mode;
other fields on the endpoint still need SQL injection inspection.

The development team supplies the application context behind the WAF event. Ask how the field is parsed, validated, stored and rendered. Keep the request examples needed for the investigation, then remove any customer content from the exception record.

Exclude one field from one rule

Azure exclusion lists remove selected request attributes from managed-rule inspection while the WAF evaluates the rest of the request. Application Gateway v2 can exclude request headers, cookies, form fields, JSON entities and query-string arguments. Exclusions can apply globally or to selected managed rules. Microsoft’s exclusion-list guide describes the supported fields and per-rule configuration.

For the message example, select RequestArgValues with the selector message, then limit the exclusion to rule 942100 in the deployed CRS or DRS version. Replay the original request and a second request that places SQL injection text in another field. The support message should pass. The second field should still trigger the rule.

Azure now skips message for rule 942100 and inspects the other request fields.

Per-rule exclusions require the next-generation WAF engine with CRS 3.2, DRS 2.1 or a later ruleset. Microsoft currently recommends DRS 2.2. A global exclusion applies across the web application covered by the policy, so reserve it for a field that has the same meaning everywhere. Microsoft lists these version requirements and exclusion behaviour in the Application Gateway WAF documentation.

Give one site or path its own policy

A policy-level exclusion may cover more applications than the exception requires.

Application Gateway can associate WAF policies globally, with a listener, or with a path-based rule. The most specific policy takes precedence. A listener policy can therefore tune one hostname, while a path policy can tune one URL area. Microsoft documents global, per-site and per-URI policy associations.

Use that layout when message is free text on /api/messages and a structured identifier elsewhere. Put the exclusion in the policy attached to the relevant path. Other listeners and paths keep their existing policy.

Record the association alongside the exception. A future routing change can move traffic under a different policy without changing the exception itself.

Use request exceptions to skip a rule

Azure Application Gateway WAF also has request exceptions. They match a request attribute such as a URI, header or client address, then bypass a selected rule, rule group or ruleset for the matching request.

Use a request exception when one rule cannot inspect any part of a known request safely. The selected rule stops evaluating the matching request, so describe the inspection removed and limit the exception to that rule where possible.

As of July 2026, Application Gateway WAF request exceptions are in preview. They require Application Gateway v2 and the next-generation engine with CRS 3.2, DRS 2.1 or later. Each WAF policy supports up to 60 exceptions, subject to gateway and per-exception limits. Confirm availability, deployment tooling and support expectations before using them in production. Microsoft publishes the current status, supported scopes and limits on the request-exceptions page.

An Allow rule bypasses the managed WAF

When that rule matches, Azure skips the managed DRS, CRS and Bot Protection rulesets for the request. HTTP DDoS rules still run. Microsoft documents the exact consequence of a custom Allow action.

Reserve an Allow rule for a tightly defined, trusted integration. Every matching request bypasses DRS, CRS and Bot Protection, including requests sent after an allowed client is compromised.

Write the trust assumption into the rule description and the exception register. Include the owner, source, listener or path, expiry or review date, and the protections that remain.

Return to Prevention mode

Run the Detection policy until ordinary traffic and important manual flows produce no unexplained matches. Include login, password reset, checkout, file upload, API writes, administration and scheduled integrations.

Then:

save the current policy settings;
change the mode to Prevention while preserving requestBodyCheck;
read the policy back;
replay the requests used during tuning;
monitor Blocked events and 403 responses;
keep a quick rollback procedure ready.

Enable Prevention in stages when separate listeners or applications have different risk. The first application may be clean while a monthly import on the second has never appeared in the logs.

Recheck the same Log Analytics groups after application releases and managed-ruleset upgrades. A new field, content type or route changes what the WAF sees. Record the request, excluded field and owning policy for every exception.

How to Tune AWS WAF with Count, Labels and Rule Priority

2026-07-29T09:15:00+10:00

An AWS managed rule blocks a real customer. You find the request, change the entire rule group to Count and promise to revisit it next week.

Six months later, it is still counting.

AWS WAF lets you change one rule inside a managed rule group to Count, keep the label it adds to matching requests and add a blocking rule immediately after the group. The other managed rules keep their configured actions throughout the investigation.

The general WAF tuning guide explains how to classify the request and document the exception. The AWS configuration begins with the managed rule that matched.

Put the rule in Count

Start with the named rule that caused the false positive.

AWS WAF lets you apply a rule action override to an individual rule inside a managed rule group. Set that rule to Count. The override changes how that rule handles matches in your web ACL; it leaves the managed rule group itself unchanged. AWS describes Count as a non-terminating action, so evaluation continues through the rules that follow. AWS documents individual rule action overrides and the behaviour of Count.

Use the individual override for this job. The older rule-group return override changes the result returned by the group after its internal evaluation. AWS recommends rule action overrides when you want the rules inside the group to count their matches.

Keep the change small:

Record the managed rule group, version and rule name.
Change that rule to Count.
Leave the remaining rules at their current actions.
Reproduce the legitimate request.
Check the Count match and the label added by the managed rule.

AWS Managed Rules add labels to matching requests, and later rules in the same web ACL can inspect those labels. AWS lists labels as the supported way to create exceptions for managed rule groups.

Read the request that matched

The sampled-requests view supports a quick investigation. Full WAF logs provide the history needed to compare matches across users, hosts or endpoints.

With the rule set to Count, look for:

the managed rule name;
its fully qualified label;
host, URI and method;
the matching request component, when AWS supplies it;
the final action taken on the request;
the number of clients and routes producing the same match.

AWS records Count matches from managed rule groups under ruleGroupList[].nonTerminatingMatchingRules. Labels added during evaluation appear in the top-level labels field. AWS populates ruleMatchDetails for SQL injection and cross-site scripting match statements. Other managed detections may provide less detail. The AWS WAF log-field reference describes these fields and their limits.

Treat request data as customer data. Query strings, headers and bodies may contain credentials or personal information. Logging redaction applies to the configured log destination. Web ACL data protection masks matching data before it reaches either logs or sampled requests. Disable sampled requests when they could expose a field that data protection does not cover. AWS explains the distinction in its logging and data-protection guidance.

Group repeated matches by rule name, label, host, path and method. Ask the developer who owns the route what the field means and how the application uses it. Investigate a JSON field containing source code separately from a malformed body that the application accepts.

Block the managed-rule label in the next rule

Suppose a managed SQL injection rule repeatedly matches legitimate messages sent to:

POST api.example.com/v1/messages

The managed rule now runs in Count and adds its documented label. Add a custom rule after the managed rule group. That custom rule should match:

the managed-rule label
AND NOT (
    host = api.example.com
    AND path = /v1/messages
    AND method = POST
)

Give the custom rule a Block action.

Requests that match the managed rule continue to be blocked everywhere except the route you reviewed. On that route, this particular managed-rule match can pass to the rules that follow and eventually to the web ACL's default action.

The order creates the behaviour. AWS WAF evaluates rules from the lowest numeric priority upwards. A later rule can see a label only after the managed rule has added it. Put the managed rule group first and the label-matching rule directly after it. AWS documents both priority order and when labels become available to later rules.

Check the rules that come before the group as well. An earlier Allow or Block action ends evaluation before the managed rule runs. AWS documents Allow and Block as terminating actions, while Count continues to later rules. The rule-action guide explains how actions and priority interact.

The exception covers every field on the exempt route

The label tells you that the managed rule matched. AWS applies the later rule action to that match for the whole request.

On the exempt route, the later Block rule ignores that label regardless of which request field caused the managed-rule match. A different field can trigger the same rule and receive the same exception.

Keep the condition tied to the smallest stable part of the application:

exact host;
exact path or a reviewed path family;
HTTP method;
another server-controlled distinction, when one exists.

A query parameter, header or cookie supplied by the client can narrow which requests match the exception. Confirm the matched request component from the event investigation.

AWS also supports a scope-down statement on a managed rule group. The statement selects which requests enter the group for inspection; every other request bypasses the whole group. Reserve that option for traffic the whole rule group should exclude. AWS describes this evaluation behaviour in its scope-down statement documentation.

Test the complete rule path

Replay this test set:

the original legitimate request on the exempt route;
the same harmless input on another route;
a safe security test that triggers the managed rule on the exempt route;
the same test on another route;
requests that match earlier terminating rules;
normal requests that should pass unchanged.

Then check the WAF logs. Confirm that the managed rule still counts and labels the request, the later rule blocks the label outside the exception, and the final action is the one you intended.

Run the configuration against production traffic in Count while you establish its normal match rate. AWS recommends monitoring metrics, sampled requests and logs, then repeating the tuning cycle until the web ACL behaves as intended. AWS also recommends completing the final stage with production traffic. Its testing guidance lays out that process.

Restore enforcement

The label rule can remain as the enforcement point when the application genuinely needs a route-specific exception. Document:

the managed rule group and version;
the original rule action;
the overridden rule name and label;
the hosts, paths and methods allowed through;
the application owner who confirmed the behaviour;
the requests used to test the change;
the logs and metrics that will reveal a regression;
the next review date.

If the development team removes the input that caused the false positive, remove the custom exception and return the managed rule to its original action. Test that change in Count first, then restore enforcement.

Review the exception after managed rule group updates and application releases. AWS managed groups can use versioned releases, and the label, traffic shape or rule behaviour you investigated may change with the deployed version. AWS publishes the available managed groups, their rules and their labels.

How to Tune Coraza on Caddy

2026-07-29T09:00:00+10:00

Coraza sits inside another server. The connector presents each request to Coraza, Coraza runs the rules and the connector applies the result.

Handler order decides whether Coraza sees the request in time. Body handling decides which fields the rules can inspect. The logging phase decides what you can investigate later.

The example deployment runs Coraza as Caddy middleware with OWASP Core Rule Set. The same CRS tuning principles apply to other Coraza connectors. Their installation, request handling and logging need their own tests.

Put Coraza in the request path

The official Caddy module is compiled into Caddy:

xcaddy build --with github.com/corazawaf/coraza-caddy/v2

The module documentation requires order coraza_waf first in the global options block, which places Coraza at the start of Caddy's HTTP handler order.

{
    order coraza_waf first
}

api.example.com {
    coraza_waf {
        load_owasp_crs
        directives `
            Include @coraza.conf-recommended
            SecRuleEngine DetectionOnly

            SecAuditEngine RelevantOnly
            SecAuditLog /var/log/coraza/audit.log
            SecAuditLogFormat JSON
            SecAuditLogType Serial
            SecAuditLogParts ABFHZ

            Include @crs-setup.conf.example
            Include @owasp_crs/*.conf
        `
    }

    reverse_proxy app:8080
}

The Caddy connector's load_owasp_crs option exposes the embedded Coraza CRS files. The three Include lines then load the recommended Coraza configuration, the CRS setup and the rules.

Coraza also supports CRS files installed on disk. A file-based installation loads the Coraza configuration first, crs-setup.conf second and the CRS rule files last. Choose one source for CRS and record its version so you can compare rule changes during an upgrade.

SecRuleEngine DetectionOnly runs the rules and suppresses disruptive actions such as deny, drop and redirect. Legitimate requests can complete while you collect matches. Coraza sets SecRequestBodyLimitAction to ProcessPartial in this mode. Watch INBOUND_DATA_ERROR because part of an oversized body may remain uninspected.

Test the Caddy configuration before reloading it. Then send a safe request that triggers a known CRS rule through the public listener. Confirm that the Coraza event appears and the request reaches the upstream in DetectionOnly.

Configure the Coraza audit log

The Caddy access log tells you that a request happened. The Coraza audit log tells you which WAF rule matched.

SecAuditEngine RelevantOnly records transactions that produced a warning or error, along with response statuses selected by SecAuditLogRelevantStatus. CRS rules normally carry the auditlog action, so their matches can enter the audit log.

The example uses Coraza's JSON audit format and leaves request-body part C out of SecAuditLogParts. Request bodies often contain passwords, personal information and customer text. Add body logging only for a controlled investigation, then remove it.

The serial audit log in the example is convenient during initial tuning. Coraza warns that serial logging can slow the server because transactions share one file.

Concurrent, HTTPS and syslog outputs suit deployments that need another destination. Send the records to a protected log system with rotation, retention limits and restricted access.

Start each investigation with these fields:

request time and transaction ID;
hostname, method and URL;
rule ID and message;
CRS tags such as attack-sqli or attack-xss;
matched variable name;
matched data;
request and response status.

The variable name identifies the input to investigate. ARGS:message identifies an application field. REQUEST_COOKIES:campaign identifies a cookie.

Handle matched data as customer data. Keep enough to reproduce the result, then retain the rule ID, field name and explanation in the permanent exception record.

Check what Coraza parsed

CRS can inspect only the fields Coraza extracted from the request.

SecRequestBodyAccess On enables body buffering and processing. The selected processor determines which collections phase 2 rules can inspect. URL-encoded forms, multipart forms, JSON and XML produce different variables.

For an unexpected body match, record:

the request Content-Type;
REQBODY_PROCESSOR;
REQBODY_ERROR and REQBODY_ERROR_MSG;
INBOUND_DATA_ERROR;
the matched variable name.

Coraza's current body-processing documentation shows processor selection by content type. The ctl:requestBodyProcessor reference still describes explicit phase 1 selection for JSON and XML. Check REQBODY_PROCESSOR on the Coraza version and connector you run, then select the processor explicitly when the expected processor is missing.

A parsing error deserves its own investigation. Coraza documents the risk plainly: the application may accept a body that Coraza's parser rejected. Compare the application's parser with Coraza using the same bytes. Fix a wrong content type or processor selection before writing a rule exclusion.

Body limits need the same care. SecRequestBodyLimitAction ProcessPartial inspects the bytes that fit within the limit and sets INBOUND_DATA_ERROR. Raise a limit when the application legitimately accepts larger bodies and the deployment can buffer them safely. Keep an alert for the limit condition so partial inspection remains visible.

Load exclusions in the correct order

CRS provides two places for local exclusions.

Use the general WAF tuning guide to classify the match and define the exception. Load that exception according to the CRS rule order below.

A runtime exclusion runs for matching transactions. Load it before CRS so it can change the transaction before the affected rule executes. CRS includes REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example for this purpose.

A configure-time exclusion changes a loaded rule. Load it after CRS so the rule already exists. CRS includes RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example for these changes.

Keep both files outside the CRS distribution. An upgrade can then replace CRS without replacing your application decisions.

The order in a Caddy deployment looks like this:

directives `
    Include @coraza.conf-recommended
    SecRuleEngine DetectionOnly
    Include @crs-setup.conf.example

    Include /etc/coraza/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
    Include @owasp_crs/*.conf
    Include /etc/coraza/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
`

With load_owasp_crs enabled, the Caddy connector merges the embedded CRS filesystem with the operating-system filesystem. The configuration can include embedded @ files and local /etc/coraza exclusion files.

The CRS tuning guide explains the before-and-after placement and the available exclusion actions.

Exclude the field that caused the match

Suppose POST /api/jobs accepts a JSON array. Rule 932125 repeatedly matches legitimate text in each jobDescription field. In this example, the audit log reports variable names such as ARGS:json.0.jobdescription and ARGS:json.1.jobdescription.

Coraza accepts a regular expression for the collection key in ctl:ruleRemoveTargetById:

# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
# Local rule ID 10010 must be unique in this deployment.
SecRule REQUEST_FILENAME "@streq /api/jobs" \
    "id:10010,phase:1,pass,nolog,t:none,chain"
    SecRule REQUEST_METHOD "@streq POST" \
        "t:none,ctl:ruleRemoveTargetById=932125;ARGS:/^json\.\d+\.jobdescription$/"

This local rule runs only for POST /api/jobs. Rule 932125 continues to inspect every other field in those requests and every field on other routes.

The /pattern/ form is a Coraza feature. The Coraza action reference states that collection-key matching is case-insensitive because Coraza lowercases variable names. Use an exact key such as ARGS:message when the application has one fixed field. A regular expression earns its place when the application produces a documented family of field names.

A field can trigger several rules in one attack class. Coraza also supports ctl:ruleRemoveTargetByTag, for example:

ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:message

The exception removes the named field from every rule carrying the literal attack-sqli tag. Record that scope and confirm that the application protects the field through parameterised queries and suitable validation.

Configure-time exclusions suit fields with the same meaning everywhere:

# RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
SecRuleUpdateTargetById 942100 "!REQUEST_COOKIES:campaign"

This removes one named cookie from rule 942100 throughout the configuration. A route-specific runtime exclusion is the better starting point for an application field.

Check where a chained rule reads the field

Some CRS detections are chained rules. The first rule starts the chain and later rules add conditions.

The CRS tuning documentation states that target exclusions by ID affect only the first rule in a chain. An exclusion will have no effect when the field is inspected by a later chain member. Removing the complete rule may be the available answer.

Find the rule in the CRS version you deployed. Check where the target appears in the chain. Then replay the request against that exact version. The rule source and replay result settle the question.

Replay the request before and after

Save the legitimate request that produced the false positive. Preserve its method, path, query string, content type, important headers and body bytes. Replace credentials and personal data with values that reproduce the same match.

For example:

curl --silent --show-error \
    --dump-header before.headers \
    --output before.body \
    --request POST \
    --header 'Content-Type: application/json' \
    --data-binary @false-positive.json \
    https://api.example.com/api/jobs

Run it once in DetectionOnly before adding the exclusion. Confirm that:

the application returns its normal response;
the audit log contains the expected rule ID;
the log names the expected field;
the request body has no parser or size error.

Add the exclusion, validate the Caddy configuration and reload it. Send the same request bytes again:

curl --silent --show-error \
    --dump-header after.headers \
    --output after.body \
    --request POST \
    --header 'Content-Type: application/json' \
    --data-binary @false-positive.json \
    https://api.example.com/api/jobs

The application response should stay the same. The false-positive match should disappear for the excluded field.

Now send a control request that places a known CRS test value in another field on the same route. Rule 932125 should still inspect that field. Send the original test value to another route as well. The rule should still inspect it there.

Expect these results:

the legitimate request works;
the rule still reads neighbouring fields;
the rule still runs on other routes.

Keep the request fixtures in a protected test repository. Run them after Coraza, CRS, Caddy or application upgrades.

Switch Coraza from DetectionOnly to On

Switch SecRuleEngine to On in a staging environment after the common legitimate flows run without unexplained matches. Repeat the false-positive replay, the neighbouring-field control and the application's critical user journeys.

Enable blocking for a limited production audience or hostname when the deployment allows it. Watch WAF responses, upstream errors and business transactions together. A clean audit log has little value when checkout or login has stopped working.

Document every exception beside the configuration:

who approved it;
the affected hostname, method and route;
the rule ID or tag;
the excluded field;
the request that reproduced the match;
the controls that still inspect or validate the field;
the date and CRS version tested.

How to Tune Your WAF Without Turning It Off

2026-07-28T10:30:00+10:00

The OWASP Core Rule Set has never seen your application.

Generic patterns let it recognise common signs of SQL injection, cross-site scripting and protocol attacks. Tuning teaches it that your application stores a search expression in JSON, accepts links in a message field or receives an analytics cookie full of punctuation.

So a new deployment will be noisy.

Faced with that noise, teams often leave the WAF in log-only mode forever or disable each rule that causes a complaint. Teams need a repeatable route from noisy alerts to safe blocking.

The work is repetitive and fairly unglamorous: observe real traffic, group related matches, understand the application field involved, write the narrowest safe exception and repeat until legitimate traffic no longer triggers unexplained alerts.

Start in detection-only mode

Introduce the full OWASP CRS to an existing production application in detection-only mode.

On ModSecurity or Coraza, set SecRuleEngine DetectionOnly. The engine records what the rules would have denied, dropped or redirected while allowing the requests through.

Both engines support this rollout. The ModSecurity FAQ recommends detection-only mode for a new ruleset, and Coraza implements the same setting.

Run it long enough to see the application's real shape. Allow at least a full week, and often one to two weeks, so the sample includes business days, a weekend and any less frequent jobs, imports or campaigns.

Exercise authenticated actions, checkout, password reset, messaging, file upload, API writes and administrative tools manually because ordinary browsing may never reach them.

Detection mode records rule matches while passing every request through, including attacks. Decide in advance what needs to be true before you enable blocking.

What changes between WAF products

The examples below use SecLang and OWASP CRS because they expose the rule ID, attack class and request field that caused a match. Managed WAFs record much the same information under different names, with varying precision for exceptions.

Coraza also runs CRS 4. It is a Go implementation of SecLang, and the CRS project recommends it for new CRS 4 deployments. The Coraza tuning guide covers its audit logging, connectors and runtime exclusions in more detail.

Body processors and chained rules can behave differently between engines and web-server connectors. Replay the requests that caused the false positive through the engine and connector that handle production traffic.

Tuning job	SecLang / CRS	Managed WAF examples
Observe without blocking	`SecRuleEngine DetectionOnly`	Azure Detection mode, AWS rule-action override to Count, Google Cloud Armor preview
Identify the detection	numeric rule ID and message	managed rule ID or name
Identify the class	CRS tag such as `attack-sqli`	rule group, category or emitted label
Identify the input	`REQUEST_COOKIES:name`, `ARGS:field`, header or body target	matched request component or exclusion selector
Narrow the exception	target removal by ID or tag, optionally limited to a route	field exclusion, per-rule exception, label-based follow-on rule or rule skip limited by request conditions

The last row is where the products differ most. ModSecurity and Coraza can stop one rule from inspecting one field on one route. Some managed WAFs can only skip the whole rule for requests matching that route. If that is the smallest exception available, write down exactly what the WAF will stop inspecting and decide whether the route is safe without that rule.

Group alerts before reviewing them

Reviewing WAF alerts one at a time hides repeated false positives.

The same harmless field may trigger the same rule across thousands of requests. Conversely, two alerts with the same rule ID may come from completely different application behaviours and need different decisions.

Group events using at least:

hostname and URL;
HTTP method;
CRS rule ID;
rule class or attack tag, such as attack-sqli or attack-xss;
matched-data variable, including its collection and exact name;
WAF action and response status;
event count, distinct clients and spread over time.

For example, REQUEST_COOKIES:analytics_id is much more useful than “SQL injection rule fired”. So is ARGS:message on POST /api/messages.

The rule ID tells you which detection fired. The attack class tells you which protection an exception would weaken. The matched variable identifies the request field that caused it. The URL and method show where the application uses that field.

Keep a few examples of the matched values long enough to investigate them, but handle them carefully. Request fields can contain credentials, personal information and customer content. The exception record usually needs the variable name and an explanation, not a permanent copy of the raw value.

Expect false positives in a few places

A few kinds of input generate most legitimate matches.

Request cookies

Marketing, attribution, experimentation and client-state cookies often contain encoded or structured values. A generic SQLi, PHP or local-file-inclusion rule may find a suspicious fragment even though the application never treats that cookie as executable input.

Keep inspection active for the REQUEST_COOKIES collection and exclude only the cookie that caused the false positive.

Identify the cookie name, the rules or attack classes it triggers, the routes where it appears, how often it occurs and whether those requests complete normally. If REQUEST_COOKIES:analytics_id repeatedly triggers the same attack class for legitimate requests, consider an exception for that cookie alone.

Cookie names need separate treatment. A rule matching REQUEST_COOKIES_NAMES inspects the names. Capture the exact name safely before writing the exclusion.

Unparsed or malformed request bodies

Parser errors deserve their own investigation.

When a selected body processor cannot parse a body, ModSecurity and Coraza set REQBODY_ERROR. Record the Content-Type and observed REQBODY_PROCESSOR because JSON and XML processor selection varies by engine, connector and version. Confirm that a processor ran before relying on the error flag.

A body that exceeds the configured inspection limit is a different case. It sets INBOUND_DATA_ERROR and may be inspected only partially. In either case, part of the body may go uninspected, and an attacker can deliberately probe that behaviour.

Ask the developer who owns the endpoint what it is meant to accept. Fix incorrect content types and body-processor configuration, reproduce the request, then check whether the application and WAF parse it the same way.

Keep request-body inspection active for the application. Limit any parser exception to the host, URL, method and body behaviour you investigated.

Free-text fields

Messages, descriptions, comments, support tickets and search boxes are expected to contain language that resembles attack syntax. A customer can discuss SQL without attempting SQL injection. A marketplace listing can contain shell characters. A support message can include a URL.

Exclude the named field on the affected route and keep inspection active for the rest of the request body.

For example, the SecLang rule below removes ARGS:message from every rule tagged attack-sqli on the messaging endpoint. That is appropriate only if you have decided that SQLi inspection is too noisy for this field across the whole class. Every other argument still receives SQLi inspection, and scam, malicious-link or other attack classes can continue inspecting the message.

Bring in the developer who owns the endpoint. They can confirm whether the field is genuinely free text, where it is stored or rendered, what server-side validation exists and which security checks still need to see it.

Application-specific structured fields

Some applications accept query languages, filters, templates, product metadata or nested JSON that naturally looks like code. The syntax may be legitimate, but these fields still deserve careful review before they are excluded.

Confirm the schema and business use before creating an exception. Check that MATCHED_VAR_NAME identifies one field, then use that exact named target. Nested JSON naming varies between engines and integrations. Keep SQLi inspection active for the rest of the API when one structured field needs an exception.

Make the smallest exception that works

Work down this list and stop as soon as the known false positive is fixed:

host, exact URL, method, rule ID or attack class, and exact named variable;
host, reviewed URL family, method, class, and named variable;
host, exact URL and rule ID;
host, rule ID;
global named-variable exclusion.

Start with the first option. Move further down only when the logs and the application design justify a wider exception.

A global exception can make sense for a named cookie or header that has no security meaning anywhere in the application. Before adding one, make sure the false positive appears across several routes and clients, and that those requests complete normally. Ask the development team to confirm that no backend interprets the field.

Even then, remove only that named field from the relevant rule or attack class. An exception for REQUEST_COOKIES:analytics_id removes one known input from SQLi inspection. An exception for the whole cookie collection removes every cookie.

Reserve global exceptions for logs that identify the matched field. Unknown body fields, unresolved cookie names and parser failures need manual investigation.

Keep your exceptions outside CRS

Put application-specific exceptions in local configuration and leave the Core Rule Set files unchanged. This keeps CRS upgrades separate from changes made for your application.

To stop one rule inspecting a named field everywhere, ModSecurity and Coraza support:

SecRuleUpdateTargetById 942100 "!REQUEST_COOKIES:analytics_id"

Load this directive after the CRS rules because the engine must load a rule before updating it.

For a route-specific exception, use a runtime control before the CRS rule executes:

# Load before CRS, normally from REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.
# Use this rule only for api.example.com.
# Confirm that local rule ID 10001 is unused.
SecRule REQUEST_FILENAME "@streq /api/messages" \
    "id:10001,phase:1,pass,nolog,t:none,chain"
    SecRule REQUEST_METHOD "@streq POST" \
        "t:none,ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:message"

With this exception, SQLi rules stop reading ARGS:message only on POST /api/messages. They still inspect other fields and routes, while other attack classes can continue inspecting the message.

The CRS false-positive tuning guide documents configure-time and runtime exclusions by rule ID or tag. The attack-sqli selector above is a literal tag that works with both ModSecurity and Coraza. ModSecurity runtime target selectors accept literal collection keys. Coraza also accepts regular expressions for collection keys, using /pattern/ syntax.

A target exclusion may affect only the first rule in a chained CRS detection. Test the exact rules and requests on your deployed engine before relying on the exception.

Use rule IDs or exact attack-class tags. Rule messages can change and may contain request data.

Managed WAFs expose different controls

Each managed provider expresses the exception differently.

AWS Managed Rules can emit a label while an offending rule runs in Count mode. A later custom rule can block that label everywhere except the route that produced the false positive. The exception affects enforcement for the whole managed rule on that route. How to Tune AWS WAF follows that evaluation path from the first counted request to restored blocking.

Azure Application Gateway WAF can exclude a named cookie, header or argument from a particular managed rule. Its request exceptions can instead skip a selected rule for matching traffic, and that feature is currently in preview. A custom Allow rule bypasses the managed CRS, DRS and bot rules for the request. How to Tune Azure Application Gateway WAF shows how to choose among those controls.

Cloudflare exceptions skip a selected managed rule for the whole matching request. Security Events may show rule 949110 as the blocking event because it checks the final anomaly score; Additional logs identify the rules that added that score. How to Tune Cloudflare WAF covers that investigation and the ordering of account-level and zone-level exceptions.

Google Cloud Armor can exclude a named request field from a versioned OWASP signature. Route-specific tuning also depends on the security-policy expression and rule priority, because a general WAF rule may inspect the same request later. How to Tune Google Cloud Armor covers preview, signature selection and field exclusions.

F5 BIG-IP Advanced WAF separates policy enforcement mode, violation actions and signature or entity staging. Its overrides can target a URL parameter, cookie, content profile, URL or the whole policy. How to Tune F5 BIG-IP Advanced WAF follows those controls from Transparent mode to tested blocking.

Provider interfaces, ruleset versions and preview features change. Record the rule name or versioned signature, the field or request being exempted and what the WAF will still inspect. Test the requests that led to the exception before enabling it.

Iterate until the false positives are gone

After adding an exception, group the alerts again. Check whether that false-positive pattern disappeared, whether a related rule started matching the same field and whether another route was affected. Look for legitimate flows that the first observation window missed.

Repeat the cycle:

collect detection-only traffic that covers normal application use;
group by route, method, rule ID, rule class and named variable;
classify abusive traffic separately from legitimate matches;
create or narrow exceptions;
rerun automated and manual application flows;
collect another window.

Aim for zero known false positives in the traffic you observed and the critical flows you tested. A new endpoint, cookie, client or release can produce fresh false positives tomorrow.

Use a higher anomaly threshold only during tuning because it can allow attacks that the normal threshold would have blocked. Write an exception for the rule and field causing the false positive, then return to the intended threshold.

Document every exception

Give every exception an owner, a reason and a review date.

Record:

hostname, URL or URL family, and HTTP method;
CRS version, rule IDs and attack-class tags;
matched collection and exact variable name;
sample event IDs and observation window;
why the traffic is legitimate;
which customer or application flow depends on it;
what protection is removed and what remains active;
developer and security approvers;
date introduced and next review date;
the release, incident or ticket associated with the change.

Keep the exception under version control. Give it a description that another engineer can understand without finding the original chat thread. Review it after CRS upgrades because rule IDs, paranoia levels and rule behaviour can change. The CRS project specifically recommends returning to detection mode long enough to exercise normal traffic after a major migration.

Remove an exception when the application no longer needs it. If the application changes its cookie, parser or validation, restore inspection.

Decide what a WAF hit should do

Security and application owners must decide which matches to log, block, rate limit, challenge or review.

With CRS anomaly scoring, an individual rule normally adds to a transaction score. The WAF blocks when the inbound score crosses the configured threshold, allowing several weak signals to add up before a customer is blocked.

Decide which outcomes you need:

Log: useful during tuning and for low-confidence signals.
Block: appropriate when several signals point to an attack and the affected flow has been tested.
Rate limit: useful for repeated behaviour across several requests.
Challenge or step up: where the product supports it, useful for browser and account flows where a hard block would be unnecessarily disruptive.
Review: appropriate for high-value actions where context matters more than a generic signature.

Respond to a single SQLi alert at the request level. Shared networks, mobile carriers and proxies make IP identity unreliable. Repeated WAF hits on the same route can inform a rate limit, but the limit should use the best available client, session or account key and have a clear window.

Track WAF blocks and rate limits separately. A ModSecurity or Coraza block commonly returns 403; a rate limit commonly returns 429. If the logs say the WAF blocked a request but the origin returned success, find out why before trusting the enforcement reports.

Recheck the WAF after application releases

A release may add an endpoint, rename a field, introduce GraphQL, change JSON shape, add a marketing cookie or move validation between services. Any of those changes can make an old exception too broad or cause a new legitimate field to trigger CRS.

Include the development team in the release process:

list new or changed public routes and methods;
identify free-text, upload and structured fields;
run staging traffic through the same CRS configuration;
test authenticated and high-value journeys;
watch the grouped detections during the production rollout;
give new or substantially changed routes an observation period before enforcing new rules on them;
review whether old exceptions can be removed.

For major CRS upgrades, treat the ruleset itself as a release. A ruleset upgrade can change rule IDs and anomaly-score behaviour while the application stays the same.

Know when tuning is complete

A traditional WAF is ready to enforce when:

normal production traffic, including the less common application flows, has been reviewed;
critical application flows have been tested with developers;
every high-volume legitimate match has a documented, narrow exception;
parser failures and unresolved matched variables have named owners and specific resolutions;
WAF blocks produce the expected response;
rate limiting is handled separately from payload detection;
exceptions are versioned, approved and reviewable;
new rules and releases can be observed before they start blocking.

Once those checks pass, enable blocking in stages and keep watching the same groups of alerts. Revisit the exceptions whenever the application or ruleset changes.

For the broader decision about where a WAF helps and where it does not, see When and Why to Use a WAF. You can also read about Peakhour's web application firewall.

When and Why to Use a WAF: A Guide for WAF Sceptics

2026-07-28T10:00:00+10:00

There are two popular opinions about web application firewalls.

The first is that every public application needs one. Turn it on, enable the managed rules and enjoy protection from the OWASP Top 10, zero-days, bots and DDoS attacks.

The second is that WAFs are expensive regex machines. They block customers, miss clever attacks and give management a green tick while the application remains vulnerable.

The second group has better jokes. Neither group has the whole answer.

A WAF is useful when it is given a job it can actually perform. It is disappointing when it is expected to understand an application better than the people who built it.

The practical question is not “do WAFs work?” It is: which risks can this WAF reduce, what will it never understand, and who will operate it when the application changes?

What a WAF can see

A traditional WAF sits in the HTTP request path. It inspects requests and applies managed or custom rules before passing allowed traffic to the application.

That position gives it a useful but limited view.

It can see paths, methods, headers, cookies, query strings and supported request bodies. Depending on the product, it may also have access to IP reputation, network characteristics, bot signals, rate history and API schemas.

It cannot naturally see the full business meaning of the request.

The WAF may know that a customer requested /api/invoices/123. The application knows whether that customer owns invoice 123. The WAF may see 200 valid checkout requests. The application knows whether they represent a wholesaler, a scalper or a broken integration.

That boundary explains both the value and the frustration.

The criticism is mostly fair

WAF sceptics are right about several things.

A determined attacker can bypass generic detection. Differences in encoding and HTTP parsing can cause a WAF and an application to interpret the same request differently. A 2024 study found 311 protocol-level evasion cases across 14 WAFs and 20 web frameworks.

False positives are real too. Legitimate HTML, JSON, support messages or product descriptions may resemble an attack signature. Microsoft recommends introducing a WAF in detection mode, reviewing logs and tuning it before blocking. It says this process may take several weeks.

A WAF also cannot fix insecure application logic. It cannot repair broken object-level authorisation, make password recovery safe or decide whether a valid-looking transaction is fraudulent. Those controls belong in the application.

And, yes, putting anything inline creates another dependency. A poor rule can block real customers. A provider can have an outage. A self-hosted appliance can fail open or fail closed.

These are reasons to be precise about the job. They are not reasons to send every internet request directly to the origin.

Buying time during a patch window

The best reason to have a WAF is rarely mentioned on the product page. It buys time.

When a serious vulnerability appears, the correct response is to fix the affected software. But finding every instance, testing the patch and deploying it safely may take hours or days. Third-party and legacy applications can take longer.

A virtual patch can narrow that exposure window. A custom rule may block the vulnerable path, reject a malicious parameter or detect the request pattern associated with the exploit while the real patch is prepared.

OWASP's virtual patching guidance is clear about the boundary: correcting the source is the preferred remediation. The WAF rule is a compensating control, not permission to leave the vulnerability in place.

That still makes it valuable. During an incident, ten minutes and two days are very different amounts of exposure.

Stopping expensive requests earlier

Applications are expensive places to reject bad traffic.

By the time a request reaches application code it may have consumed a connection, invoked authentication, queried a database, called another API or triggered a paid service. A request does not need to contain an obvious exploit to create cost. It may simply repeat an expensive operation far more often than a legitimate user would.

An edge control can reject common exploit traffic and excessive requests before that work happens.

This is especially useful for login, search, registration, password reset, checkout and expensive API routes. Rate limits and bot controls can respond differently based on route, session, account outcome and other available evidence instead of treating every request from an IP address as the same actor.

NIST recommends applying general WAF, bot and denial-of-service controls early in the API serving stack to protect upstream systems from malicious payloads and unrestricted resource consumption. It also treats those as separate capabilities.

That distinction matters. A classic WAF does not automatically provide sophisticated bot management or network-scale DDoS protection. A broader WAAP service may bundle them, but buyers should check the controls rather than trust the acronym.

A control you can reach during an incident

Security incidents create awkward gaps between knowing there is a problem and having the final fix ready.

Perhaps one endpoint is being abused. A new exploit is spreading. Login failures are climbing. A scraper is rotating through residential proxies. An old hostname that should have disappeared is suddenly receiving traffic.

A centrally managed WAF gives the operations team somewhere to make a narrow, reversible change without waiting for several application releases. They can restrict a route, add a virtual patch, change a rate limit, challenge suspicious traffic or collect more detailed events while the investigation continues.

That operational separation is valuable. The application team can work on the root cause while the security or operations team reduces immediate exposure.

It also needs discipline. Emergency rules require owners and expiry dates. A temporary exclusion should not survive for years. Changes should be observed before blocking where the situation allows it.

Evidence before the origin

A WAF is often discussed only as a blocking device. Its position in the request path can be just as useful for understanding what is happening.

Good events can show which route was targeted, which rule matched, what action was taken and whether the request reached the origin. Rate, bot and API signals can add context. Combined with application logs, this helps teams distinguish an attack from a customer problem, a broken integration or a badly tuned rule.

The same visibility can expose weaknesses in the deployment itself:

a forgotten API version receiving traffic;
a hostname missing the expected policy;
an origin that is still publicly reachable;
an endpoint whose cost makes it an easy denial-of-service target;
an exclusion that is much broader than anyone remembered.

This does not require blocking on day one. Observe mode can create value before the team is confident enough to enforce a decision.

When the case for a WAF is strong

A WAF is usually worth serious consideration when the application has several of these characteristics:

customer accounts, payments or personal information;
public APIs or expensive dynamic routes;
third-party, legacy or slow-to-patch software;
regular scanning, credential stuffing, scraping or automated abuse;
multiple applications that need consistent emergency controls;
compliance requirements for runtime web protection;
an operations team able to tune rules and investigate events.

PCI DSS provides one concrete example. Since 31 March 2025, Requirement 6.4.2 requires an automated technical solution in front of applicable public-facing web applications to continually detect and prevent web attacks. The PCI Security Standards Council describes the requirement without requiring a particular product called a WAF.

Compliance is a legitimate reason to deploy the control. It is not evidence that the deployment works.

When the case is weak

Not every website needs a large WAAP contract.

A genuinely static, low-value site with no accounts, API or meaningful dynamic input presents a smaller application attack surface. Basic CDN protection, origin restriction, good patching and sensible security headers may be enough.

The case is also weak when nobody will own the WAF. An ignored ruleset eventually becomes noisy, stale or full of broad exclusions. A dashboard that nobody checks is not defence in depth.

Be cautious when the proposed product does not match the actual problem. A signature WAF is not the complete answer to sophisticated bots. An on-premises appliance cannot absorb a volumetric attack larger than its internet connection. Edge rules cannot repair business logic. A provider's “AI-powered” label does not establish an acceptable false-positive rate.

Sometimes the right answer is a smaller control. Sometimes it is a different control. The point is to buy against the risk rather than the category name.

How not to become the WAF horror story

Most bad WAF experiences begin with the same mistake: enabling everything and immediately blocking production traffic.

A safer deployment looks less exciting:

Define the job. Decide which applications, routes and abuse cases the WAF is expected to cover.
Put all relevant traffic through it and restrict direct access to the origin.
Start managed rules and new controls in observe or count mode.
Review real production-shaped traffic and tune false positives narrowly.
Test login, checkout, uploads, APIs and other important customer journeys before enforcement.
Give every custom rule and virtual patch an owner, reason and review date.
Monitor allowed as well as blocked traffic so false negatives do not disappear from view.
Keep application-level authorisation, validation and rate controls in place.
Test what happens when the WAF, agent or provider is unavailable.

That is the difference between owning a control and merely paying for one.

Where this leaves us

A WAF is neither useless nor sufficient.

It cannot understand every valid-looking abuse, prevent every bypass or rescue an application that ignores secure design. It introduces cost, tuning and another inline dependency.

It can still stop a great deal of cheap hostile traffic, buy time during a vulnerability, prevent excessive work from reaching the origin, give operators a fast response point and leave evidence that helps explain an incident.

Our two companion articles make each side of the case directly: Everyone Says a WAF Is Useless. Are They Right? and Your Application Needs a WAF. Just Not for the Reason You Think.

The conclusion is less catchy than either headline. Use a web application firewall when the application has something worth protecting, the WAF has a defined job and someone is responsible for operating it. Then keep fixing the code behind it.

Your Application Needs a WAF. Just Not for the Reason You Think

2026-07-28T09:30:00+10:00

A web application firewall will not make bad code good.

It will not repair broken access control. It will not redesign an unsafe checkout. It cannot decide whether a customer should be allowed to see a particular invoice, transfer money from an account or buy the last 200 tickets to a concert.

If your public application has accounts, valuable APIs or expensive dynamic routes, you probably still need one.

The case has nothing to do with an invisible shield or a promise to “solve the OWASP Top 10”. Public applications meet hostile traffic every day, software is imperfect and fixing the right thing often takes longer than attacking it.

That is what a WAF is for.

The internet does not wait for your next release

Every public application receives traffic it did not ask for.

Some of it is harmless background noise: crawlers looking for software that is not installed, scripts requesting old WordPress paths, scanners testing yesterday's vulnerability against every address they can find.

Some of it is aimed directly at the application: SQL injection attempts, malicious uploads, path traversal, unusual encodings and requests crafted to trigger a known vulnerability.

The application can reject those requests itself. Ideally, it will. But allowing every request to reach application code, authentication services, databases and third-party APIs is an expensive way to discover that something is hostile.

A WAF creates an earlier decision point. It can discard common exploit traffic before the request reaches the part of the system that holds customer data or performs expensive work.

That does not make the application secure. It means the application no longer has to face every cheap attack on its own.

Patches take time. WAF rules take less

The clearest reason to run a WAF is virtual patching.

Suppose a serious vulnerability appears in a framework, CMS plugin or third-party product. The responsible answer is to patch it. But first the team has to identify every affected system, test the update, work around compatibility problems and arrange a safe deployment.

The attacker does not have to do any of that.

A targeted WAF rule can reduce the exposure while the real patch is prepared. It may block a particular path, parameter, payload or request shape associated with the exploit. It is not the final repair, but it can turn an open window into a much narrower one.

OWASP's virtual patching guidance is refreshingly practical about this. Fixing the source is the number-one technical remediation. A virtual patch is useful when that fix cannot happen immediately. The two controls are complementary, not rivals.

This matters most for legacy applications, third-party software and systems with slow release cycles. Those are exactly the places where “just fix the code” can be correct advice and an inadequate incident response.

Your application should not absorb unlimited work

Not every damaging request contains an obvious attack string.

A search request may be perfectly valid but expensive. A login attempt may fail normally while being one of a million credential-stuffing attempts. A scraper may request public pages exactly as a browser would, just much faster. A customer-facing API may trigger email, SMS, payment or database costs every time it is called.

This is where a modern WAAP service goes beyond a traditional signature WAF. Rate limiting, bot management and application-layer DDoS controls can make decisions based on the route, request rate, account outcome, browser or network evidence, and the work the origin is being asked to perform.

NIST recommends placing general WAF, bot and denial-of-service controls early in the API serving stack so malicious payloads and unrestricted resource consumption do not exhaust upstream systems. Importantly, NIST treats these as related but separate capabilities. Buying something called a WAF does not automatically mean all three are present.

Reject bad or excessive work before it becomes expensive work.

Put the checks in different places

Good application security is built in layers because each layer knows something different.

The application knows who owns an object, whether an account may perform an action and what a valid transaction looks like. It should remain authoritative for those decisions.

The edge sees different evidence. It can compare traffic across routes and hosts, recognise widespread exploit patterns, apply an emergency rule across several applications and notice that one client is creating an unusual amount of work before the request reaches the origin.

Neither view is complete.

A WAF is valuable because it is independent of the code it protects. If an application developer makes a mistake, the WAF may still reject the exploit. If a WAF misses a clever request, the application should still validate it. One control can fail without immediately making the failure fatal.

If either layer makes a mistake, the other still gets a chance to respond. That is the useful part of defence in depth.

It gives you somewhere to respond

During an incident, speed matters.

Teams often know enough to reduce the risk before they know enough to ship the final fix. They may need to restrict a vulnerable endpoint, block an exploit pattern, lower a rate limit, challenge suspicious login traffic or temporarily exclude a region where an attack is concentrated.

Doing that through application releases can be slow, especially when several services are affected. A centrally managed WAF gives operators somewhere to make a narrow, reversible change while the application teams investigate.

The words “narrow” and “reversible” matter. Emergency blocks need owners and expiry dates. Rules should be tested in observe mode where time permits. Broad exclusions created during the incident should not quietly become permanent architecture.

The WAF is useful here because it is an operational control, not because it knows more about the application than its developers do.

It leaves evidence at the front door

Prevention gets most of the attention, but visibility is one of the better reasons to have a WAF.

When an application behaves strangely, the team needs to know what arrived before the failure. Which routes were targeted? Were requests blocked or allowed? Did the traffic share a network, client pattern or payload? Was a rate limit crossed? Did the attacker reach the origin directly?

Useful WAF events can answer part of that story. Combined with origin and application logs, they help distinguish a real attack from a broken integration, a customer mistake or a badly tuned rule.

They can also reveal traffic that nobody knew was public: an old API version, forgotten hostname, administrative route or direct-origin path.

Logs are not automatically useful. A million unexplained rule matches can be worse than a smaller set of events tied to route, action and outcome. But without evidence at the entry point, incident response starts with a large blind spot.

Compliance is a reason, but not the best one

For organisations handling payment-card data, a runtime application control may not be optional. Since 31 March 2025, PCI DSS Requirement 6.4.2 requires an automated technical solution in front of applicable public-facing web applications to continually detect and prevent web attacks.

The PCI Security Standards Council describes the requirement without mandating a particular product called a WAF.

That distinction matters. Compliance can justify the control, but it does not prove the control is effective. A WAF in log-only mode with nobody reading the alerts is not much of a defence. Neither is one with a public origin that attackers can reach directly.

Passing an audit is a business requirement. Blocking useful attacks without blocking customers is the security requirement.

A WAF needs to be operated, not merely purchased

The case for a WAF comes with a condition: somebody has to own it.

Managed rules need to be introduced carefully. Legitimate traffic needs to be observed. False positives need narrow corrections rather than sweeping allowlists. Important customer journeys need tests. Virtual patches need to be removed after the underlying vulnerability is fixed. Origins need to be locked down so the edge cannot be bypassed.

The job is not finished when the DNS changes.

The right first step is often detection rather than immediate blocking. Learn what normal traffic looks like, identify the noisy rules, find missing hostnames and understand which requests are expensive. Then move well-understood controls into enforcement.

A badly operated WAF can block customers, miss attacks and create false confidence. That is a reason to operate it properly, not a reason to give the application no independent protection at all.

What a WAF is actually for

A WAF should make exploitation harder, give operators a faster response and reduce what reaches the origin. In practice that means stopping familiar attack traffic, buying time during a vulnerability, putting limits in front of expensive routes and recording enough evidence to explain what arrived.

Developers still own secure design. The WAF gives them another layer, not an exemption.

Our companion article, Everyone Says a WAF Is Useless. Are They Right?, takes the sceptical case seriously. WAFs can be bypassed. They can cause false positives. They create cost and another inline dependency.

Those are real constraints. They define how a web application firewall should be deployed and judged.

They do not change the basic reality: bugs happen, patches take time and bots are cheap. It is sensible to make hostile traffic cross one more independent decision point before it reaches the application.

Everyone Says a WAF Is Useless. Are They Right?

2026-07-28T09:00:00+10:00

Spend long enough around application security and someone will tell you that web application firewalls are useless.

They are easy to bypass. They block real customers. They cannot fix bad code. They cost money, need constant tuning and create one more thing that can fail.

The annoying part is that none of this is entirely wrong.

The mistake is jumping from “a WAF is imperfect” to “a WAF has no useful job”. A lock can be picked. We still lock the door. Security controls are allowed to solve a bounded problem.

So here are ten excellent reasons not to use a WAF—and what they really tell us.

1. “We write secure code”

Good. Keep doing that.

A WAF cannot repair broken access control, fix an insecure password reset flow or stop an application from selling the same scarce ticket twice. Those rules belong in the application because the application understands the customer, the object and the transaction.

But even good teams ship bugs. Dependencies develop vulnerabilities. A vendor patch can take days to test. A legacy application may not have a team at all.

This is where virtual patching earns its keep. A narrowly written WAF rule can block a known exploit while the real fix is prepared. OWASP describes the source-code fix as the preferred answer, while also recognising that an enforcement layer can reduce the exposure window.

Secure code and a WAF are not competing ideas. One fixes the weakness. The other can make it harder to exploit in the meantime.

2. “Attackers can bypass it”

They can.

Researchers have found WAF bypasses using alternative encodings, duplicated parameters and differences between the way a firewall and an application parse the same request. One 2024 study found 311 protocol-level evasion cases across 14 WAFs and 20 web frameworks.

That finding should end any talk of a WAF as a force field. It should not convince us to pass every request straight to the application.

Most hostile internet traffic is not a handcrafted masterpiece. It is scanning, probing and replaying familiar attacks across thousands of sites. Filtering that traffic does not make the application invulnerable. It removes a large amount of cheap, automated opportunity.

A determined burglar may pick a lock. We still lock the door.

3. “WAFs block legitimate customers”

An untuned WAF certainly can.

A product description, support ticket or API request may contain HTML, SQL-like text or unusual characters for perfectly innocent reasons. Turn every managed rule on, switch immediately to blocking mode and the first security incident may be your own checkout failing.

Microsoft recommends starting a new WAF in detection mode, reviewing the logs and tuning it before enforcement. It also says the process may take several weeks.

What this rules out is the Friday-afternoon deployment: every managed rule enabled, blocking turned on and nobody watching checkout.

Start by observing. Find the rules that match real traffic. Make exclusions as narrow as possible. Test important customer journeys. Then block what you understand.

4. “It cannot understand our business”

Correct. This may be the most important criticism on the list.

A generic WAF cannot know that customer A should never see customer B's invoice. It cannot know whether buying 400 concert tickets is normal wholesale activity or scalping. It cannot decide whether a bank transfer fits the customer's history.

Many serious API failures involve valid-looking requests used in the wrong context. The OWASP API Security Top 10 is full of problems involving object ownership, authentication, permissions, resource consumption and sensitive business flows.

Those controls need application context.

There is still work suited to the edge: reject malformed requests, enforce broad limits, filter known exploit patterns and record what reached a sensitive route. A wider WAAP service may also add API schemas, bot signals and account-abuse controls. The application remains responsible for the final business decision.

5. “We already have a CDN”

You may already have the machinery for a WAF. That does not mean it is protecting anything.

Is the managed ruleset enabled? Is it logging or blocking? Does it cover every public hostname and API version? Can an attacker connect directly to the origin? Are large or compressed request bodies inspected? Has anyone reviewed the exclusions since the last application release?

A WAF only protects traffic that passes through it. Cloudflare's own troubleshooting guide says it only mitigates proxied traffic. AWS separately documents how to restrict an origin so visitors cannot bypass CloudFront and reach it directly.

“We have a CDN” is an architecture statement. “All public traffic crosses an active, tested policy” is a security statement.

6. “A WAF will not stop a huge DDoS attack”

Also true.

If an attack fills the network connection in front of an on-premises WAF, the appliance may be functioning perfectly while the website remains unreachable. Volumetric attacks need upstream capacity: an ISP, cloud network, CDN or dedicated scrubbing service able to absorb them before they reach the constrained link.

Application-layer attacks are different. They target expensive searches, login endpoints, uncached pages, GraphQL queries or API operations that consume disproportionate origin resources. Rate limits and request-aware controls can help there.

This is why the distinction between WAF and WAAP matters. A classic WAF filters HTTP requests. A WAAP bundle may combine that with bot management, API protection and application-layer DDoS controls. The acronym does not tell you which controls are included, licensed or switched on.

7. “Bots just rotate their IP addresses”

Yes, and an IP blocklist on its own is a fairly tired answer.

Modern abuse can arrive through residential proxies, mobile networks, cloud platforms and large pools of short-lived addresses. If the only question is “have we seen this IP before?”, the attacker often wins by changing it.

Useful bot management combines several weaker signals: request rate, route, session behaviour, account outcome, headers, network characteristics and browser evidence. The response can vary too. A suspicious request might be logged, slowed, challenged or given a tighter limit instead of being permanently blocked.

OWASP's bot-management guidance makes the goal clear: raise the cost of abusive automation while leaving legitimate people and useful bots alone.

An IP list is easier. It is also further from the problem.

8. “It is another expensive security subscription”

Sometimes it is. WAF pricing can be a peculiar experience because a business may pay to inspect millions of requests it never wanted.

The fair comparison is not “WAF bill versus zero”. It is the WAF bill against origin compute, emergency engineering, fraud, scraping, support calls, application downtime and the cost of investigating an incident with poor logs.

That does not guarantee the WAF wins. A brochure site with no accounts, no API and almost no dynamic input may need little more than sensible CDN protection, origin restriction and good patching. A busy login or checkout path under constant automated abuse has a different calculation.

The control should match the exposure. Buying the largest WAAP bundle available is not a security strategy.

9. “It is not set-and-forget”

No useful security control is.

Applications change. New endpoints appear. Old APIs stay online longer than expected. Managed rules are updated. Attack traffic changes. An exclusion created during an incident quietly survives for three years.

A WAF needs an owner, observable decisions, staged changes and periodic review. Virtual patches need expiry dates. Important customer journeys need regression tests. Logs need someone who will look at them.

If nobody will operate the WAF, that is a legitimate reason not to buy an elaborate one. A permanently ignored dashboard is not defence in depth. It is interior decoration.

10. “Putting it inline creates another point of failure”

It does.

A bad rule can block a site globally. A provider can have an outage. A self-hosted appliance can fail open or fail closed. In 2019, Cloudflare published a detailed account of how a WAF rule containing a poorly performing regular expression exhausted CPUs across its network.

Inline controls need the same engineering discipline as the applications behind them: staged rollout, rollback, monitoring, tested failure modes and a clear way to recover.

The origin, load balancer, DNS provider, identity service and database are points of failure too. We accept those dependencies when the service is worth it, then engineer around their failures. A WAF deserves the same treatment.

So, do you need a WAF?

Maybe not.

If the site is genuinely static, low value and already protected by a capable edge, a premium WAAP service may solve very little. If nobody will tune it, test it or respond to its alerts, the product may create more confidence than protection.

The case becomes much stronger when the application has accounts, payments, personal information, valuable APIs, third-party dependencies, slow patch cycles or a history of automated abuse. It becomes stronger again when the same edge can protect the origin, control bots, limit expensive routes and leave useful evidence for the people investigating incidents.

A web application firewall does not make an insecure application secure. The honest claim is smaller: applications have bugs, patches take time and the public internet is noisy. A well-run WAF gives that noise one more place to stop before it becomes your application's problem.