Skip to content
VercelVercel
Menu

ANOMALY_SCORE_EXCEEDED

The ANOMALY_SCORE_EXCEEDED error occurs when a request is blocked by the OWASP Core Ruleset managed ruleset. The OWASP CRS uses an anomaly scoring model: each rule that matches a request adds points to a cumulative score. When the total score exceeds the configured threshold, the request is denied with this error.

This typically means the request contained patterns associated with common web threats (SQL injection, cross-site scripting, etc.) that triggered enough OWASP rules to exceed the blocking threshold.

403

ANOMALY_SCORE_EXCEEDED:

Forbidden

Troubleshoot

AI Assistance

I'm encountering an error and reviewing the docs at https://vercel.com/docs/errors/ANOMALY_SCORE_EXCEEDED.md to understand what's happening. Please help me resolve this by: 1. **Suggest the fix**: Analyze my codebase context and propose what needs to be changed to resolve this error. If you do not have access to my codebase, ask me for the codebase and try to fix the error based on the information you have. 2. **Explain the root cause**: Break down why this error occurred: - What was the code actually doing vs. what it needed to do? - What conditions triggered this specific error? - What misconception or oversight led to this? 3. **Teach the concept**: Help me understand the underlying principle: - Why does this error exist and what is it protecting me from? - What's the correct mental model for this concept? - How does this fit into the broader framework/language design? 4. **Show warning signs**: Help me recognize this pattern in the future: - What should I look out for that might cause this again? - Are there similar mistakes I might make in related scenarios? - What code smells or patterns indicate this issue? 5. **Discuss alternatives**: Explain if there are different valid approaches and their trade-offs My goal is to fix the immediate issue while building lasting understanding so I can avoid and resolve similar errors independently in the future.

If the blocked request is legitimate traffic (a false positive), the project owner can adjust the firewall configuration:

  1. Review matched rules:
    • From your project's dashboard, open Firewall in the sidebar
    • Navigate to Rules > OWASP Core Ruleset > Configure
    • Review which specific rules triggered and contributed to the anomaly score
  2. Set rules to Log mode: For rules causing false positives, change the action from Deny to Log. This allows you to monitor traffic without blocking it while you assess whether the rule applies to your application
  3. Disable overly aggressive rules: If certain rules consistently trigger with legitimate traffic, consider disabling them. Review each rule's purpose to ensure you're not reducing security unnecessarily
  4. Create bypass rules: Use a WAF Custom Rule with a bypass action to allow specific requests that should not be evaluated by the OWASP ruleset
  5. Monitor firewall logs: After making changes, monitor the Firewall overview page to verify that legitimate traffic is no longer blocked and that your application remains protected

For more details on configuring the OWASP Core Ruleset, see WAF Managed Rulesets.

CLI and API troubleshooting

You can also investigate and resolve ANOMALY_SCORE_EXCEEDED errors using the Vercel CLI and API.

View blocked requests

Use the CLI to filter logs for blocked requests:

vercel logs --status-code 403 --since 1h

For JSON output with full request details:

vercel logs --status-code 403 --json

Search for the specific error code:

vercel logs --query "ANOMALY_SCORE_EXCEEDED" --since 1h

The JSON output includes firewall-specific fields in the proxy object:

  • proxy.wafAction: The action taken (log, deny, challenge, bypass, rate_limit)
  • proxy.wafRuleId: The ID of the firewall rule that matched

Read firewall configuration

Query your project's firewall config via the API:

vercel api /v1/security/firewall/config?projectId=<project-id>

Update OWASP rules

To switch a rule to Log mode, use a PATCH request:

vercel api /v1/security/firewall/config?projectId=<project-id> -X PATCH \
  --input config.json

Where config.json contains:

config.json
{
  "action": "crs.update",
  "id": "xss",
  "value": { "active": true, "action": "log" }
}

Available OWASP rule IDs: sd (scanner detection), ma (multipart attack), lfi (local file inclusion), rfi (remote file inclusion), rce (remote code execution), php, gen (generic), xss, sqli (SQL injection), sf (session fixation), java.

To disable a rule entirely, set "active": false or use the crs.disable action.

Create bypass rules via API

Add a bypass rule with rules.insert:

config.json
{
  "action": "rules.insert",
  "value": {
    "name": "Bypass for internal API",
    "action": "bypass",
    "conditions": [{ "type": "path", "op": "pre", "value": "/api/internal" }]
  }
}

Ongoing monitoring

For continuous monitoring, use Log Drains with source: "firewall" to stream WAF events to your SIEM or logging infrastructure.

You can also manage firewall rules as code using the Terraform provider with the vercel_firewall_config resource.

Was this helpful?

supported.