Attack Mode
Add a browser verification step when a project is under attack.
Attack Mode protects a project during active abuse by requiring browser clients to complete a verification step before accessing application content.
In the dashboard this control appears as Attack challenge mode.
Use Attack Mode as a temporary defensive control during:
- Sudden request floods
- Automated scraping
- Credential-stuffing attempts
- Broad malicious scanning
- Attacks that are difficult to isolate with a narrow rule
Attack Mode is not a replacement for application authentication, authorization, or rate limiting.
How Attack Mode works
When Attack Mode applies to a request:
- Easel evaluates whether the request is eligible for browser verification.
- Unverified clients receive a challenge page with HTTP status 429.
- The browser completes a proof-of-work verification.
- The browser posts the result to
/.well-known/easel-challenge/verify. - On success, Easel sets a short-lived session cookie (
easel_ch_pass, about one hour, bound to hostname and deployment). - The client continues to the application without repeating the challenge until the session expires.
Challenge responses use Cache-Control: no-store so intermediaries do not cache
the interstitial.
Enable Attack Mode
- Open the project.
- Open Project settings.
- Find Attack challenge mode.
- Review the impact on APIs, bots, and non-browser clients.
- Optionally enable Allow verified bots.
- Turn Attack Mode on and save.
- Monitor firewall events and application health.
Scope
Attack Mode is project-wide. When enabled, it applies to hostnames that serve the project, including production and preview URLs, unless a request is exempt.
Exemptions include:
- A valid Attack Mode session cookie
- A matching Bypass attack challenge custom rule
- Verified bots when Allow verified bots is enabled
- Trusted internal edge fetches
- BotID opaque verification paths used by the BotID SDK
Custom Challenge rules still apply before Attack Mode. See Security evaluation order.
Browser verification
Verification requires a browser that can run the challenge page and store the session cookie. It does not prove that a visitor is human; it only shows that the client completed the configured verification flow.
Verification is bound to the hostname and deployment identity. Changing host, deployment, or clearing cookies can require a new solve.
APIs and non-browser clients
Attack Mode can disrupt:
- API clients
- Webhooks
- Mobile applications
- Command-line clients
- Monitoring systems
- Automated integrations
Before enabling it, create narrow Bypass attack challenge rules for trusted machine traffic when needed. Recommended signals include:
- Trusted IP ranges
- Dedicated webhook paths
- Known client headers that your edge can trust
Continue validating application-level signatures in your code. Firewall rules cannot replace webhook signature checks.
Bots
Verified bots may bypass Attack Mode when Allow verified bots is enabled.
See Bot traffic. A bot should not be trusted solely because its user agent resembles a known crawler.
Disable Attack Mode
Disable Attack Mode after the attack subsides and narrower protections are in place.
Before disabling it:
- Review matched traffic.
- Identify stable malicious patterns.
- Convert appropriate patterns into custom rules.
- Confirm application capacity is healthy.
- Continue monitoring after deactivation.