Security troubleshooting

Find what stopped a request

Start with the request ID. Open the request in security observability to see the action, the rule that matched, and whether the decision came from IP reputation or one of your custom rules. Denied responses also carry X-Easel-Firewall-Action, and custom rule denials carry X-Easel-Firewall-Rule-Id.

Visitors see 403 or a challenge page

1. On the Firewall page, look for a Deny or Challenge rule that matches the path, IP, or headers in use.
2. Check whether Attack challenge is on under Protections.
3. If the event shows IP reputation, the IP is on a known-bad list that Easel manages, and custom rules can't change that.

If one of your rules caused it, turn the rule off or narrow it, confirm traffic recovers, then rebuild it with Log until it matches only what you want. Don't add a broad Bypass rule to fix one false positive: it only skips attack challenge mode, not your other rules.

An API or webhook stopped working

Machine clients can't pass a browser check. Add a custom rule with Bypass for that traffic, matched on a dedicated path, hostname, or fixed IP addresses, and keep verifying webhook signatures in your code. See APIs and webhooks.

A browser is stuck in a challenge loop

The pass cookie is bound to one hostname and deployment, and the check needs JavaScript. Check that:

• JavaScript and cookies are allowed for the hostname.
• Redirects don't move the visitor between hostnames, such as www and the apex domain, so each hop needs a new pass.
• The system clock is roughly correct.
• Your app's Content Security Policy doesn't block the challenge page.

Include the request ID from the challenge page when you contact support.

A verified bot is blocked or challenged

Check that:

• Allow verified bots is on. It only applies to attack challenge mode.
• No custom Deny or Challenge rule matches the bot first.
• The bot is really verified. A crawler that only claims a known user agent isn't, and Easel treats it like any other client.

See Verified bots.

A rule doesn't match

Add the rule with Log and one condition at a time to find the condition that fails. Common causes:

• The rule is turned off, or an earlier rule matches first. A Log rule higher in the list also stops evaluation.
• Path is normalized; use Raw path to match the path exactly as sent.
• Comparisons are case-sensitive except Method, Country, and Continent.
• The header or cookie name is misspelled.
• The client uses IPv6 and the rule lists IPv4 addresses.
• Environment is production but the request went to a preview URL.
• The regex doesn't compile, so it never matches.

A rule matches too much traffic

Common causes:

• contains where you meant equals
• No Hostname condition, so the rule covers every domain on the project
• A negated condition, such as is none of, that also matches requests with no known location
• Conditions in separate OR groups that you meant to join with AND
• A proxy or CDN in front of Easel. Easel sees the proxy's IP, so many visitors share one address and IP, country, and ASN conditions match them all.

A rule change hasn't taken effect

Changes reach every edge region shortly after you save. Requests already in flight use the old rules. If a region still behaves differently after a few minutes, contact support with request IDs, the edge region from each request, and when you changed the rule.

What to send support

Include the project, domain, request IDs, approximate time, the firewall action and rule ID if any, what you expected, and steps to reproduce.