Support has reported that a legitimate customer cannot submit a form. The application team suspects a Cloudflare WAF rule because the failure began after a security change. There is enough evidence to investigate, but not enough to disable the rule across the site.
Start a change record while you examine the request. Keep the operational work and the record together so the next person can understand the decision without reconstructing it from chat.
The sequence below follows a targeted adjustment for a suspected false positive. It assumes you can inspect relevant events and make changes in the account. Available controls and visibility depend on your Cloudflare configuration and entitlement.
Open with the symptom and the evidence
Ask support for the affected URL, approximate time with timezone, steps taken, and any displayed error or Ray ID. Avoid copying payment information, credentials, or unnecessary personal data into the change record.
Try to reproduce the failure through an approved test account or safe application flow. Record the hostname, path, method, and result. If reproduction would create an order or alter customer data, agree on a safe test with the application team first.
Find the corresponding security event where available. Identify the rule, ruleset, and action associated with the request. A blocked-page screenshot suggests where to investigate; the event provides stronger evidence about the control involved.
Write down what remains uncertain. If the request cannot be correlated, keep investigating before treating a WAF adjustment as the fix.
State the hypothesis before choosing the exception
State a specific hypothesis: a particular rule appears to match a valid request from the updated form.
Test that explanation against the available evidence. Did the request reach the origin? Did the application return its own error? Did another deployment happen at the same time? Are other requests on the route succeeding?
Then describe the proposed change in terms a reviewer can assess. Include the affected hostname and route, the rule being adjusted, and the action or exception you intend to apply.
For a confirmed false positive, the appropriate option may be a narrowly scoped exception to the identified rule. The exact mechanism depends on the rule type and controls available. Inspect its scope carefully: an exception that skips an entire ruleset has a different effect from one targeting a single rule.
Get an accountable approval
The operator preparing the change should name the expected security effect and the possible application impact. The application owner should confirm the legitimate behaviour the route needs to support.
Use the approver required by your change process. For an urgent service disruption, follow the established emergency path and record who authorised the action. An incident does not remove the need to explain what changed.
The approval record should include:
- The evidence supporting the adjustment.
- The exact scope and intended duration.
- The legitimate journey used for verification.
- The previous configuration and rollback method.
- The signals that would cause the team to stop or reverse the change.
Keep this concise enough to read during an incident. A reviewer needs a decision they can assess, with the configuration details attached where appropriate.
Capture the starting state
Before editing, save the relevant rule configuration, expression, action, and position or execution context. Record related exceptions that could affect the outcome.
Check for concurrent changes. Another engineer may be editing the same ruleset, or an automation process may restore configuration from a separate source. Coordinate the change through the system your team uses to manage it.
Identify a small set of useful observations from before the adjustment. These might include matching events, application errors on the route, and the result of a controlled test. Traffic totals alone will not show whether the form works.
Prepare rollback before applying the edit. Confirm that restoring the prior state will not overwrite someone else’s approved work.
Apply one bounded adjustment
Apply the approved change and record the time. Where supported and appropriate, use an observation mode to understand matching behaviour before enforcement. An urgent false positive may require a targeted correction followed immediately by verification.
Avoid bundling unrelated cleanup into the same change. Rule renaming, broad expression rewrites, and exception removal can wait unless they are necessary to resolve the issue.
Have a second person check the resulting configuration when your process calls for it. Compare the saved state with the actual change, including any scope selected in the interface.
Keep the application owner and support contact informed that verification is underway. Applying the edit is an intermediate step.
Verify the journey and the remaining protection
Repeat the previously failing request using the agreed safe test. Confirm the application outcome, including any downstream step needed to establish success.
Check the corresponding Cloudflare event and origin evidence where available. Establish whether the adjustment changed the behaviour you intended.
Then test relevant neighbouring behaviour. A fix for one form should not unintentionally cover unrelated routes. Use approved security test cases where available to check that the controls expected to remain active still behave as intended.
Watch real traffic during the agreed observation period. If the journey still fails, revisit the hypothesis. If the change creates unacceptable exposure or unexpected behaviour, use the documented rollback and record the result.
Close with evidence and a review date
The closing note should say what failed, which evidence linked it to the rule, what changed, and how success was verified. Include any limits to the verification.
Assign temporary exceptions a review date and a named reviewer. Where an application change can remove the need for the exception, track that work separately.
When you need an operator who will take a WAF change through approval, apply it, and verify the customer journey, Vigilbase sells the Cloudflare licence and operates the account after go-live. For the wider operating rhythm, see how we run Cloudflare after go-live.
