Attack challenge mode

Attack challenge mode makes every visitor to a project pass a short browser check before the page loads. Use it as a temporary control during a request flood, scraping, credential stuffing, or an attack you can't isolate with a narrow custom rule.

It isn't a replacement for authentication, authorization, or rate limiting in your app.

How it works

1. A visitor without a valid pass gets a challenge page with status 429 and Cache-Control: no-store.
2. The browser solves a proof-of-work check in the background, usually in about a second.
3. On success, Easel sets a pass cookie bound to the hostname and deployment.
4. The visitor reaches your app and isn't challenged again until the pass expires.

Clients that can't run JavaScript or store cookies fail the check. Passing it shows the client completed the check, not that it's a human. Switching hostname or deployment, or clearing cookies, means solving it again. See Limits for how long a pass lasts.

Turn it on

1. Open the project and choose Firewall.
2. Under Protections, find Attack challenge and choose Enable….
3. Under Turn off after, choose 1 hour, 6 hours, 24 hours, or Until I turn it off.
4. Choose whether to Let verified bots through.
5. Choose the enable button, such as Enable for 6 hours.

You can also turn it on from Project settings → Security → Attack challenge mode. Changes apply without a redeploy.

Attack challenge mode applies to every hostname that serves the project: production, preview URLs, and custom domains. These requests skip it:

• Requests with a valid pass cookie
• Requests matching a custom rule with the Bypass action
• Verified bots, when Allow verified bots is on
• BotID verification requests from your app

Custom rules run first, so a Deny, Redirect, or Challenge rule still applies. See Evaluation order.

APIs and webhooks

Webhooks, API clients, mobile apps, CLIs, and uptime monitors can't solve the check. Before you turn on attack challenge mode, add a custom rule with the Bypass action for that traffic, matched on a dedicated path, hostname, or fixed IP addresses. See Let webhooks through.

A bypass doesn't prove where a request came from, so keep verifying webhook signatures in your code.

Verified bots

A verified bot is a crawler or service whose identity Easel confirms with more than its user agent: its published IP ranges, forward and reverse DNS, or a signed request (Web Bot Auth). Googlebot, GPTBot, and ClaudeBot are examples. The list changes as providers update their infrastructure. A client can't become verified by copying a crawler's user agent.

Allow verified bots lets verified bots skip attack challenge mode so search indexing and link previews keep working. Set it when you turn on attack challenge mode, with the Verified bots switch under Protections on the Firewall page, or in Project settings → Security. It only has an effect while attack challenge mode is on.

Verified bots still go through platform protections, deployment protection, and your custom rules. To block a verified bot, add a custom rule for it.

AI crawlers

AI crawlers that Easel can verify, such as GPTBot and ClaudeBot, are treated like other verified bots. Others are unverified, and blocking them by user agent alone is easy to evade. To keep content away from crawlers, combine authentication, path rules, and Challenge rules or attack challenge mode.

For bot detection inside your app, use BotID in your application code.

Turn it off

Turn it off once the attack subsides and narrower protections are in place. Before you do, review the challenged traffic on the Firewall page and turn stable patterns into custom rules. If you chose an end time, attack challenge mode turns itself off then.

To turn it off now, choose Turn off next to Attack challenge on the Firewall page.

Next steps

• Write custom rules
• Review challenged requests
• Fix challenge problems