Security events
See which requests the firewall acted on, what it did, and why.
Every request the firewall acts on records an action and the source of the decision. Use these events to debug a custom rule, confirm attack challenge mode is working, spot false positives, or check whether your code ran.
The Firewall page
The project Firewall page shows security activity for the selected time range:
- Traffic: total requests and how many were mitigated
- Top sources: the clients sending the most requests, with how many were mitigated. From a row, you can start a rule for that source.
- Mitigated requests: each request the firewall acted on. Select one to see Why it was acted on, and the Client: IP address, country, network, user agent, and response status.
Select a rule in the rules list to show only that rule's mitigated requests. To write and test rules, see Firewall.
In Logs and charts
- The request details in Logs show a Firewall row with the action. See Requests.
- In the Logs search,
firewallAction:anylists every mitigated request,firewallAction:deny,challengelists specific actions, andwafRuleId:<rule-id>lists one rule's matches. - Open the Edge Requests chart on Observability for a breakdown by firewall action, and group custom queries by WAF action or WAF rule ID. See Metrics.
Actions
Filter on these values. They stay stable even when dashboard labels change.
| Value | Meaning |
|---|---|
deny | The request was blocked |
challenge | The client was sent a browser check |
challenge_pass | The client solved the check |
challenge_fail | The client didn't solve the check |
redirect | A rule redirected the request |
log | A rule matched and recorded the request, which went through |
rate_limit | A rate limit rule answered 429 |
bypass | A rule let the request skip attack challenge mode |
Easel's IP reputation protection can also report ban or throttle.
Challenge pass and fail count verification attempts, not page views.
Decision sources
Why on a mitigated request names the source:
- Platform protection: the client IP is on a blocklist of known-bad addresses that Easel manages and checks before your rules, on every project. See Security.
- Attack challenge mode: every visitor gets a browser check while it's on. See Attack challenge mode.
- Custom rule: the rule that matched and its position in the rule order. Rules run top to bottom, and the first match decides.
Deployment protection isn't a firewall decision. Requests it blocks don't appear here. See Deployment protection.
Response headers
Blocked, challenged, and rate-limited responses can carry X-Easel-Firewall-Action and
X-Easel-Firewall-Rule-Id; rate-limited ones also carry Retry-After. Challenge responses can carry
X-Easel-Mitigated: challenge. Use them to debug from curl, and see
CDN headers for the full list. Copies of these headers
that a client sends on a request aren't trusted.
Privacy
Client IP addresses and locations can be personal data. Limit access to the workspace members who need it, and don't copy raw client identifiers into systems that don't need them.