Peakhour.IO - False Positives

Privacy Relay, Corporate VPN, or Residential Proxy?

2026-08-01T12:00:00+10:00

An application sees a login from an address that does not match the user's apparent location. The connection belongs to a relay, VPN, or proxy network.

That is a reason to look closer. It is not a reason to call the user malicious.

Privacy relays, corporate VPNs, consumer VPNs, carrier-grade NAT, and residential proxies all weaken the old assumption that an IP address describes one person in one place. They do it for different reasons and with different operating models. A security policy that reduces them to anonymous=true will either miss abuse or punish legitimate users.

Privacy Services Deliberately Separate Identity from Destination

Apple says iCloud Private Relay uses separate internet relays so no single party can see both who a user is and which sites they visit. It also lets the user preserve a general location or use a broader country-and-time-zone location. Apple's Private Relay overview explains the scope and the role of the relay addresses.

That design changes what a website can infer from the source IP. It does not remove the session, account, route, browser, or request behaviour available to the application.

A corporate VPN creates a different pattern. Many employees may exit through a small set of company gateways. The source can be stable and organisation-owned, but the address still represents a population rather than one device. A consumer VPN may rotate gateways and mix unrelated subscribers. Carrier-grade NAT can make a normal mobile or broadband address shared even when no privacy product is involved; RFC 6598 documents shared address space reserved for carrier deployments.

Residential proxy services are different again. A remote operator deliberately routes through consumer connectivity so the destination sees the household or mobile exit. The exit may have joined through an informed participant, an embedded SDK, compromised software, or another supply path.

The network categories matter. They still do not establish intent.

Define the Expected Population

Policy should reflect the application and route.

A workforce portal may know its corporate VPN ranges and require device or certificate evidence. A consumer service should expect mobile networks, privacy relays, travel, and shared households. A country-restricted service may need stronger location verification than an online catalogue. An API used by fixed partners can enforce network expectations that would be unreasonable on a public login page.

Ask:

Is this network type expected for this user population?
Is the route public, authenticated, sensitive, or expensive?
Does the account have established device and session history?
Is the apparent location material to the transaction?
Can the client provide another form of evidence?
What does a false rejection cost?

The answer determines whether the network signal should be ignored, logged, challenged, or combined with stronger controls.

Use Context to Separate Risk from Privacy

Peakhour IP Intelligence and Residential Proxy Detection place network context beside credentials, device history, fingerprints, behaviour, route, and recent events.

Consider two logins through privacy infrastructure.

The first uses an established session, familiar device history, a normal route sequence, and one successful authentication. The second attempts many accounts, carries an exposed credential, has no normal session history, and repeats the same failure pattern across rotating addresses.

Both hide or replace the direct source address. Only one presents a strong account-abuse pattern.

The policy should be able to express that difference. Blocking every relay or VPN is not contextual security. It is a network-category ban.

Geography Needs the Same Restraint

IP geolocation is an estimate of network presence, not proof of a person's physical location. VPN gateways, relays, mobile routing, satellite networks, corporate egress, and proxy exits can all separate the address from the user.

Use geography as evidence proportionate to the decision. A content preference may tolerate a coarse estimate. A regulated transaction may require account evidence, verified identity, payment context, or an explicit location control beyond an IP lookup.

Avoid impossible-travel rules that treat every IP change as physical movement. A session can switch between mobile, Wi-Fi, VPN, and relay paths without the person travelling at all. Look for continuity in the account, device, session, and behaviour before escalating.

Choose an Action That Can Be Recovered From

The action can then scale with the evidence:

Allow expected privacy or corporate access with consistent session evidence.
Log an unfamiliar network category on low-consequence routes.
Apply tighter rate limits when repeated behaviour spans accounts or rotating exits.
Challenge an interactive client when network change appears beside account risk.
Require step-up verification for recovery, payment, or access-control changes.
Block confirmed automated abuse with bounded route and policy scope.

Challenges are not perfect humanity tests. Automation can complete them, while privacy tools, accessibility software, or broken browser environments can cause legitimate failures. Measure completion and provide a recovery path.

Retain the Reason

When a policy acts, retain the network category, source, route, contributing evidence, action, and outcome. “Anonymous IP” is too vague for support or incident review.

The record should show whether the deciding factor was proxy use, an exposed credential, failure velocity, a new device, a route sequence, or several observations agreeing. That evidence lets the team tune the control without adding broad exceptions that erase protection.

Privacy and security are not opposing verdicts attached to an address. They are requirements the application has to handle at the same time.

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.