The problem and decision criteria
Saving a document in a web editor returns a 403 response. Login and viewing work, but saving fails when particular content is included. Allowing the entire path may get work moving again. What inspection has been removed remains a separate question.
Identify the inspection that conflicts with legitimate behavior, then limit a WAF exception to the necessary requests and rules. Before deployment, define the defenses to retain and rollback conditions. Assign an owner, review time and expiry time to temporary exceptions. A reduction in blocked requests alone does not complete the change. Verify that the legitimate function is restored and that requests outside the exception and the remaining security controls still behave as intended.
This operational guide draws on official documentation checked on September 26, 2026. Product behavior is described within the scope of each document; approval, expiry and verification procedures are proposed operating practices for a team to define. All scenarios and change records are design examples, not actual customer incidents or test results.
First identify who returned the 403
A 403 can come from origin web server restrictions or application authorization checks. Cloudflare also returns 403 responses from security features other than its WAF and from some connection handling. The response code or the logo on a block page therefore does not establish a WAF false positive.[1]
Start by locating and correlating the same request across the layers.
| Inspection point | Information to record | Question to answer |
|---|---|---|
| User or test client | Timestamp and time zone, host, path, method, response code and the product's request identifier | Which request failed, and which function was affected? |
| Edge and WAF | Applied policy and version, matched rules, actual action and the rule that terminated evaluation | Was this merely a detection, or did this layer terminate the request? |
| Proxy and application | Correlatable request identifiers and timestamps, whether the request arrived, authorization and business processing results | Did it reach the origin, and did the origin independently reject it? |
If identifiers differ between layers, establish their relationship first. Do not assume they are identical or correlate different requests merely because their timestamps are similar. Use metadata and sanitized reproduction evidence rather than pasting entire requests.
In particular, a recorded rule match is different from the final reason for blocking. AWS WAF logs distinguish the final action, terminating rule, matches within rule groups and nonterminating matches. Identifying a rule group is insufficient if the actual blocking rule within it is missed.[2]
The absence of a log entry does not yet exclude the WAF. Cloudflare Security Events is not a complete inventory of incoming requests; events may be sampled, and one request may produce several events. Narrow the time range and filters, and correlate with other request logs where needed. Do not equate event counts with user request counts.[3]
Inspect and protect requests before they reach the service — Review request and blocking records, tune protection rules and manage certificates and access controls.
Establish evidence that the request is legitimate
A request is not safe merely because a user sent it or was logged in. First establish the application's permitted behavior. Does the document body allow a limited set of HTML? May this user edit this document? Does the server actually enforce that same input contract? These are the criteria to check.
OWASP Core Rule Set (CRS) explains that generic detection rules, which do not know an application's particular business context, can conflict with legitimate input. False-positive logs can themselves contain passwords or other sensitive information. Avoid copying original requests into public issues or shared documents.[4]
As minimum evidence for an exception review, reproduce the failure in an authorized test environment using sanitized input and explain which field conflicts with which rule. Record confirmation that the input is permitted by the business contract, together with evidence of the application's relevant security handling. After applying an exception, verify actual storage and subsequent retrieval as well as the HTTP success response.
Without that evidence, continue investigating rather than widening the exception. A WAF compensating for vulnerable input handling requires a different response from a false positive on legitimate input.
Narrowing request scope is different from trusting a user
Define the exception closer to “this method on this path of this host” than “this entire site.” Where the product and engine support it, narrow it further to the problematic field and rule. A path or method condition selects the requests to which an exception applies; it does not prove those requests are safe.
To use authentication context as a condition, verify whether validated identity information is actually available at the point of WAF evaluation. A client-controlled header such as X-Trusted, an arbitrary parameter or the presence of a session cookie does not establish an authenticated request. Skipping all remaining checks solely because of a particular country or IP address is also outside this guide's baseline approach.
If the architecture cannot validate identity before the WAF, explicitly record the risk that the exception also applies to unauthenticated requests. Keep the application's authentication and authorization checks in place. OWASP likewise recommends checking authorization on every request and denying access by default unless explicitly permitted.[5]
“Exception” skips different things in different products
CRS can exclude a field from a particular rule's inspection targets
CRS distinguishes excluding an entire rule from excluding particular variables from its targets. Conditional runtime exclusions can change only the targets of a specific rule for a specific request. Engine and rule-structure limitations still apply: the desired field exclusion is not available at every step of a chained rule, and configuration-time and runtime exclusions require different placement. Manage exclusions separately rather than editing the deployed CRS rule files directly.[4]
Cloudflare skips selected rules for matching requests
Cloudflare Managed Rules exceptions specify matching conditions and the rules or rulesets to skip. Narrowing a path and skipping a particular managed rule is therefore different from excluding just one of the multiple fields that rule inspects. Account-level and zone-level scope also matter. A zone-level exception evaluated later cannot reverse an earlier account-level block.[6]
Depending on the selected options, Custom Rules Skip can bypass evaluation of Rate Limiting or Super Bot Fight Mode as well as managed rules. The similarly named Bot Fight Mode cannot be skipped in the same way. Record exactly which targets are selected and check whether exception requests are logged. Disabling logging on a Skip rule can keep those requests out of Security Events.[7]
AWS WAF Count does not skip inspection
AWS WAF Count is a nonterminating action that records a match and continues evaluation. Allow terminates evaluation of that web ACL, so it is not an alternative that preserves inspection by later WAF rules. Overriding only a rule group's return action to Count is also different from overriding individual rules inside the group to Count. The former does not change the evaluation flow inside the group.[8]
One AWS exception-handling pattern changes an individual rule to Count and uses the label that rule adds in a later rule. When adjusting a blocking rule, that later rule can block requests that have the label but do not meet the narrow exception conditions. Verify that the label is actually provided, its exact name and the evaluation order. Omitting the later block weakens protection for requests outside the exception too.[9]
A scope-down statement for a managed rule group instead limits which requests enter that group at all. Requests excluded from the group are not evaluated by its other rules either. Do not treat this as excluding only one field or one rule.[10]
These differences mean that changing vendors requires more than copying exception-condition strings. Compare the requests admitted to the exception, the inspections removed and the inspections retained together.
Document the exception change
The following is a design example for a document editor that permits limited HTML. It assumes a self-managed CRS environment where the relevant rule supports a field-level exclusion. R, A and B are explanatory identifiers, not actual rule IDs or deployment versions. This is not a configuration to copy directly into Cloudflare or AWS WAF.
| Record item | Design example |
|---|---|
| Change ID and status | EX-WAF-2026-048, proposed. Approval, deployment and testing have not been performed in this example |
| Reason and legitimate behavior | Assume permitted limited HTML in the document body conflicts with XSS rule R. Approved content must be retrievable after saving |
| Minimum request scope | Requests matching all of host editor.example.com, exact path /api/articles/draft and method POST. Target only the parser-identified body field content |
| Inspection to exclude | Exclude only rule R's inspection of content on those requests. Aim to retain inspection of other fields, rules and paths |
| Authentication assumption | Do not assume the WAF determines login status. The application verifies user identity and permission to edit the document on every request |
| Defense lost | Rule R loses the opportunity to detect threats in content for the matching requests. Do not assume other XSS rules cover every equivalent risk |
| Compensating controls | Before deployment, verify server-side allowlist HTML sanitization, context-specific encoding in non-HTML output contexts, per-document authorization and input type/size limits |
| Controls that must remain unaffected | Other managed rules, separate rate limits, authentication and authorization. Confirm retention through actual configuration diffs and tests |
| Ownership and approval | Application owner confirms legitimate behavior and input handling. Security owner approves residual risk. Platform owner deploys, observes and rolls back |
| Configuration evidence | Preserve the diff from pre-change A to post-change B. In a real record, pin engine, ruleset and application versions and deployment identifiers |
| Review and expiry | Review at 2026-09-27 16:00 +09:00; expiry at 2026-09-27 18:00 +09:00. These are example times, not standard deadlines |
| Verification evidence | Connect the expected outcomes in the following test matrix to actual execution results. Unexecuted checks are not passes |
| Stop and rollback conditions | Stop if scope expands unintentionally, retained defenses regress, compensating controls fail or observation becomes unavailable. Revert to A and verify effective configuration and function |
| Action at expiry | Remove, or revalidate and reapprove. If rollback blocks work again, choose a separate response such as restricted operation of that function instead of silently extending the exception |
Compensating controls must address the risk associated with the missing defense. Adding a rate limit does not compensate for the same risk as removing an XSS inspection. Features that require HTML input need appropriate HTML sanitization; ordinary strings need encoding for their output context. OWASP does not treat a WAF as a solution to the underlying application causes of XSS.[11]
For the responsibilities of individual controls, see the comparison of WAF, API Gateway, Rate Limit, Schema Validation, JWT and mTLS.
Shape delivery around the content — Set caching by update behavior and observe edge delivery alongside origin load.
Retest exception boundaries as well as legitimate requests
Run verification in a test environment that you own or are explicitly authorized to use. Use synthetic input preserving the necessary characteristics, without transferring real customer tokens or production request bodies. The following table is a design example of expected outcomes, not a report of completed execution.
| Test group | Situation to check | Expected outcome |
|---|---|---|
| Legitimate operation | Save and retrieve permitted HTML and text containing Korean characters and line breaks | The operation completes while preserving permitted expressions |
| Path and method boundaries | Different host, similar path or different method | The exception does not match. This does not mean all requests must be blocked; the existing policy applies |
| Field boundaries | Query or cookie fields with the same name, and other body fields | Unintended fields are not excluded |
| Authentication and authorization | Unauthenticated requests and requests for documents the user cannot edit | The application rejects them regardless of the WAF exception |
| Compensating controls | Authorized defensive test input containing disallowed HTML elements or attributes | Input is rejected or sanitized according to the contract, leaving no executable content after storage and output |
| Retained WAF defenses | Baseline tests intended to trigger unchanged rules | Expected detection and blocking remain intact |
| Parser and input contract | Malformed input, oversized input and duplicate fields outside the contract | The predefined rejection or handling policy remains, and the exception does not expand |
| Rollback | Remove the exception or restore the previous configuration | The exception is actually gone; the original policy and business impact are confirmed |
Do not standardize every “must be blocked” outcome as a WAF 403. The application can reject an authorization failure, while HTML sanitization can transform input into a safe value. Define which layer owns which outcome before testing to avoid false passes.
Record excluded tests and their reasons alongside the selected tests. For a recording format, use the existing change-specific regression scope workbook, linking the boundaries and security expectations added by the WAF exception.
After limited rollout, observe function and defense together
Passing tests is not a reason to copy the exception across the site. Start with the function and path whose cause has been established, and define who observes the change and when to stop. AWS also recommends testing and tuning before production deployment and notes that behavior can differ temporarily while changes propagate. Distinguish a successful configuration API response from confirmation that the new policy works at every observation point.[12]
Observe the scope of requests matching the exception, success of the affected business operation, blocking outside the exception and application authentication/input errors together. If only the block count falls, it is still unclear whether false positives decreased or less inspection is taking place. Do not calculate a global false-positive rate from sampled events or treat the absence of detections in skipped inspections as evidence of safety.
Expiry requires more than writing a date in the rule description. If automatic removal or approved automation exists, verify its actual operation and failure alerts. Otherwise, assign removal or reapproval and the verification procedure to an owner. Do not assume every WAF automatically expires exceptions. Expiry here is an organizational operating control.
Removing the exception may restore the original blocking of legitimate requests. Reassess risk rather than expanding to an allow-all policy, and restrict the function or offer an alternative workflow if necessary. Even an urgent exception needs an approver, scope and termination conditions.
Review may be needed before the calendar expiry. Recheck the justification when paths, methods, parsers, authentication flows or rulesets change. Cloudflare's September 22, 2026 changelog includes managed rules changing their action from Log to Block. Security-rule behavior can change even when application code does not.[13]
Do not cover an application defect with an exception
If input formats violate the server contract, HTML is stored and output without safe handling, or authorization checks are missing, correct that design first. Conversely, indiscriminately deleting legitimate input that the business needs is not a good way to eliminate false positives. Define permitted input and safe handling before deciding whether an exception is necessary.
Hiding content in another encoding or opaque data solely to evade inspection is not a solution proposed here. Even where an exception is needed, justify it through verified permitted behavior and compensating controls, rather than the fact that detection was avoided.
Do not approve continued use of an exception when the original rule's risk cannot be explained, required compensating controls are missing, implementation is substantially broader than the intended minimum scope, or nobody owns observation and rollback. Consider temporarily restricting the function if safe operating conditions cannot be established.
A WAF exception change is not finished when the user's Save button works again. Close it only after confirming restored legitimate behavior, retained defenses, and removal or reapproval of the exception.
If rules, logs and rollback ownership are divided across teams, review the rule design and operation scope of IXC's WAF and DDoS protection service to distinguish work retained internally from work requiring support.
