A legitimate request being blocked creates pressure to fix the experience quickly. That pressure is understandable. It is also how a narrow compatibility problem becomes a broad security exception.
I would separate two questions: what made this request legitimate, and what made the protection consider it suspicious? You need evidence for both before deciding what to change.
Reproduce the shape, not the sensitive payload
Build a sanitized example with the same method, route, content type, and relevant input structure. Keep credentials and customer data out of tickets. Correlate the request with the security event using the identifiers available in your environment, then check which policy and rule actually applied.
Do not infer a false positive just because a user reports a 403. The response could come from another layer, and a user-controlled field can contain genuinely unsafe input even in an otherwise legitimate workflow.
Make the proposed exception measurable
An illustrative upload endpoint might accept a document format that repeatedly triggers an inspection rule. I would review a route-specific or parameter-specific adjustment before any hostname-wide exclusion. The exact controls and evaluation options depend on the Akamai product and policy configuration.
Akamai’s supported policy evaluation mode can record how candidate WAF settings would behave alongside existing protection. Use that evidence where available; do not treat evaluation as the same thing as enforcement or assume it covers every security feature.
Give the exception an owner and an end condition
The review should name the affected workflow, evidence, matching scope, approver, and the condition for removal. “Temporary” without an expiry or review date is just a description.
After the change, compare legitimate completion rates, relevant security events, and unexpected traffic in the exception’s scope. Lower block volume alone is not proof of improvement: disabling a control also lowers its block volume.
If the application can change its input handling or request format, include that work in the longer-term fix. The edge adjustment should not silently become the only documentation of an application dependency.
The outcome I want is specific: the legitimate workflow works, the exception is explainable, and reviewers can see which protections still apply.