Security evaluation order

Security controls run in a defined order. An earlier decision may prevent later controls or application code from running.

Request flow

Request received
      ↓
Platform protections
      ↓
Deployment protection
      ↓
Verified bot classification
      ↓
Custom firewall rules
      ↓
Attack Mode
      ↓
Cache and routing
      ↓
Static output or function

Platform protections run first and are not overridable by custom rules. Deployment protection runs before custom firewall rules. Custom rules run before Attack Mode, so a matching rule can deny, challenge, redirect, or bypass Attack Mode before the project-wide challenge applies.

Why order matters

Suppose a request matches both a custom deny rule and Attack Mode.

Because custom rules run first:

A Deny rule stops the request with 403 before Attack Mode runs.
A Challenge rule issues browser verification for that match.
A Bypass attack challenge rule skips Attack Mode for that match.
A Log rule records the match and continues evaluation.

Platform protections remain active regardless of custom-rule outcomes.

Terminal actions

A terminal action ends evaluation for that layer and prevents the request from reaching the application.

Terminal outcomes include:

Platform block or throttle
Custom rule Deny
Custom rule Redirect
Challenge response (from a custom rule or Attack Mode)
Deployment protection sign-in response

A Log action records a match and continues. When no custom rule matches, the request continues unless another security layer blocks or challenges it.

There is no separate Allow action that ends evaluation and skips later layers. Use Bypass attack challenge when you need trusted traffic to skip Attack Mode only.

Rule order

Within a custom firewall configuration:

Active rules are evaluated from top to bottom.
The first matching rule wins.
Disabled rules are skipped.
Reordering rules changes which match applies first.

See Custom rules.

Attack Mode

Attack Mode is a project-wide challenge that runs after custom firewall rules.

Custom rules can:

Block traffic before the challenge
Challenge only selected routes
Bypass Attack Mode for matching traffic
Redirect selected clients elsewhere

Verified bots may skip Attack Mode when Allow verified bots is enabled. See Bot traffic.

Cache interaction

Security controls run before cache lookup and origin routing.

A request must pass platform protections, deployment protection (when applicable), custom rules, and Attack Mode before Easel serves cached content or invokes your application. Short-circuit security responses are not stored as ordinary cacheable application content.

Rewrites and internal requests

Internal rewrites and routing decisions happen after security evaluation. Easel does not re-run the full security chain for each internal rewrite hop.

External rewrite destinations and proxied origins receive traffic only after the original client request has passed security controls.

Internal edge fetches used for platform operations can use a trusted bypass that external clients cannot reproduce. Challenge verification for /.well-known/easel-challenge/* is handled so verification can complete without looping.

Request metadata

When a custom rule denies or fails a redirect, Easel may set response headers such as:

X-Easel-Firewall-Action
X-Easel-Firewall-Rule-Id

Treat these as operational signals for debugging. Do not rely on client-supplied copies of security headers as proof of identity. See Firewall observability.

On this page