Home / OCI

OCITroubleshootingIntermediate

OCI WAF is blocking legitimate users: find the rule and tune it safely

Use WAF logs to find which protection, access control or rate-limit rule blocked a request, then add a narrow exception instead of switching protection off.

Deepak Bhardwaj2 min read

Applies toOCI Web Application Firewall (WAF policies on Load Balancer), OCI Logging

Symptoms

  • A customer gets 403 (or a custom block page) for a specific form, API call or file upload.
  • Only some users are affected: certain countries, a corporate proxy, or heavy API clients.

1. Turn on and read the WAF logs

Enable the WAF log for the firewall (Logging → service logs → Web Application Firewall), then search:

search "<compartment>/<log-group>/<waf-log>"
| where data.action = 'BLOCK'
| sort by datetime desc

Note these fields from the blocked request:

  • The rule name/key that matched (protection rule, access control or rate limiting)
  • The request path, method and client IP
  • For protection rules, the matched parameter and value, which shows what triggered it

2. Which rule type?

Rule type Typical false positive Safe fix
Protection (OWASP-style SQLi/XSS) Rich-text editors, JSON bodies with code snippets, SQL in a support form Exclude that parameter or path from that rule only
Access control Geo-blocking hits travelling users; IP allow-list missing a new office Update the condition, or add an allow rule for the specific path or IP
Rate limiting Mobile apps behind carrier NAT, integrations batching calls Raise the limit for that path, or key the limit on a header or API key
Request body size Large uploads Raise the body inspection or size limit for the upload path only

3. Tune without opening the door

  1. Reproduce the block with the customer's request (curl, Postman) against a test listener if you can.
  2. Prefer, in this order:
    • A condition that skips one protection rule for one path or parameter.
    • Changing that single rule to log/detect-only, temporarily, while you test.
    • Never: turning off the whole protection capability or the policy.
  3. Record the change with the customer ticket number in the rule description.

4. Verify

  • The customer's flow works again.
  • WAF logs show the request now allowed, and other attacks against the same path are still blocked. Test with a known-malicious payload in staging.

Rate limiting design tips

  • Set limits per path (login, search, API) rather than one global number.
  • Return a clear 429 response with a Retry-After header for API clients.
  • Monitor the share of blocked requests. A sudden rise after a release usually means a new legitimate pattern, not an attack.

Caution

Don't add the customer's IP to a full allow-list that bypasses all inspection. If that IP is ever compromised, or it's a shared proxy, you've removed protection for everyone behind it.

Related fixes