Your app lets customers write formatted notes. Plain text saves normally, but a note containing an HTML example returns 403 Forbidden. The customer loses their work, and the application logs don't show an error from the save handler.
In this hypothetical case, a web application firewall (WAF) blocked the request before it reached the app. The content matched a security rule even though the editor was meant to accept it. That's a false positive: a protection rejects a legitimate operation.
Investigating these failures needs more than a graph of blocked traffic. You need to connect a block to the customer's route, understand the reported reason, and test whether the operation should have been accepted. Forte puts those starting points in the affected Service or Website's Blocked Requests view.
A rule match needs application context
A firewall inspects the request using its configured rules. A pattern that looks dangerous in one application may be valid content in another. An editor, for example, might accept code snippets that a basic contact form has no reason to receive.
That doesn't make the rule wrong everywhere, or the input safe everywhere. The editor still needs to validate what it accepts and render stored content safely. A WAF exception cannot repair an application that executes untrusted content.
For the note editor, begin with a synthetic note that reproduces the failure. Record its request time, hostname, HTTP method, and path. Check whether the same workflow succeeds with ordinary text. That comparison helps isolate the trigger without sharing a customer's private note.
Why AWS investigations involve several steps
When you operate AWS WAF yourself, first identify the web ACL protecting the application and find the matching request in its logs or samples. The AWS WAF investigation guide walks through that search.
AWS logs distinguish the final action, the terminating rule, and rules within managed rule groups. You need those details to identify which protection stopped the note. A group name alone may not identify the individual rule that needs review. AWS WAF log field reference
AWS supports overriding an individual rule's action to Count to test its behavior. Count records a match and continues evaluation; another rule can still block the request. It also changes enforcement for traffic matching that rule, so define the scope of the test before applying it in production. AWS rule action override documentation
AWS provides the controls. Your team owns identifying the rule, choosing a safe change, and checking the result. With separate firewall and application tools, gathering enough context for that decision is part of the work.
Start with possible false positives in Forte
Open the affected Service or Website and choose Monitoring → Blocked Requests. The view starts with Possible false positive, so you can begin with blocks flagged for review. Other categories are Attack traffic and Rate limited.
Forte groups blocks by method, route pattern, and reason. In the note editor, look for the failing POST route. A reason such as Request body contained HTML or script connects the firewall's decision to a feature you recognize.
Open the group and compare sample timestamps and paths with your test. The samples also show client IP, country, and user agent. Those fields help compare attempts, but they don't prove who sent a request or whether its content was safe.
The category is based on the matching rule and request path. It cannot establish the customer's intent. Treat Possible false positive as a place to start reviewing, and inspect the other categories if you haven't found the reported failure.
This blocked-request view works for both Services and Websites. You can investigate a firewall rejection even though the request never reached the application code that would normally write logs.
Ask for a review with the request attached
Choose Get help on the affected group or a particular sample. Forte opens a support draft containing the resource and time range, the route, block reason, category, and group counts. Selecting a sample adds its identifying context as well.
Add what the app is supposed to accept, what the customer observed, and how to reproduce it with safe test data. For the editor, explain that formatted notes are expected and provide a synthetic example that fails. Review the draft before submitting it.
This gives the reviewer a specific request to investigate. The view doesn't automatically allow the traffic, change firewall rules, or offer a customer-controlled rule override. Forte operates the managed firewall; you provide the application context and verify that the intended feature works after a correction.
Keep the correction as narrow as the evidence allows
Turning off broad protections can let the note through while also admitting unrelated traffic. A useful review asks which request triggered which protection and what change would preserve the feature with the least loss of coverage.
The application may also need a change. For example, an editor that doesn't need arbitrary HTML could accept structured formatting instead. When HTML is required, the app still needs appropriate validation and safe rendering. Explain the actual requirement before choosing a workaround.
For a self-managed AWS setup, follow AWS's monitoring and tuning guidance when deciding how to scope an exception. In Forte, keep the reproduction and expected behavior attached to the support case so the managed-firewall review has that same context.
Verify that the customer's work succeeds
Repeat the synthetic note save through the public hostname after the correction. Confirm that the expected response arrives and the saved note can be opened again. Test plain text and other supported formatting too, since allowing one request doesn't establish that the whole editor works.
Then revisit Blocked Requests to compare new activity. The console covers the last seven days and shows up to 25 recent samples per group. Ingestion is periodic, and samples aren't a complete record of attempts. Use the application's actual result to confirm the retry succeeded.
You don't need to capture a private request body to begin this investigation. A route, timestamp, block reason, and safe reproduction often provide the useful starting context. Keep credentials and customer content out of shared diagnostics.
Explore Forte Compute or Forte Websites to evaluate managed firewall protection with blocked-request visibility alongside your app.