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.

Peakhour.IO - Cloudflare WAF