Security

Every request to an Easel project passes through a fixed chain of security controls at the edge before it reaches the cache, static assets, or your functions. Some controls are always on and managed by Easel. Others you turn on and configure per project.

Workspace security covers who can change these settings, and security headers cover the browser policies your app sends.

Evaluation order

Easel evaluates the controls in this order:

Request received
      ↓
Platform protections (IP reputation)
      ↓
Deployment protection
      ↓
Verified bot classification
      ↓
Custom rules
      ↓
Attack challenge mode
      ↓
Routing and cache
      ↓
Static assets or functions

An earlier decision can stop the request before later controls or your code run. Custom rules run before attack challenge mode, so a rule can deny, challenge, redirect, or bypass a request before the project-wide challenge applies.

Terminal actions

These outcomes end the request at the edge, so it never reaches your app:

• A platform protection deny or challenge
• The deployment protection sign-in response
• A custom rule Deny, Redirect, or Challenge
• The attack challenge mode check

Custom rules run top to bottom and the first match decides. A Log rule is a first match too: it lets the request continue to attack challenge mode and your app, but custom rules below it don't run for that request. When no rule matches, the request continues to the next control.

Bypass skips browser challenges: attack challenge mode and the IP reputation challenge. It doesn't skip an IP reputation block or deployment protection. See Firewall.

Cache and rewrites

Security controls run before cache lookup, so a request must pass them before Easel serves cached content or invokes your app. Security responses such as challenges and denials aren't cached as app content.

Rewrites and other routing decisions happen after security evaluation. Easel doesn't re-run the chain for each internal rewrite, and an external rewrite destination only receives requests that already passed.

Platform protections

Platform protections are always on for every deployment. They don't need custom rules, middleware, or code changes, and you can't turn them off.

• DDoS protection absorbs network and HTTP request floods at the edge.
• IP reputation denies requests from known malicious sources before your custom rules run. It appears on the Firewall page under Protections.

Requests these protections stop don't run your code. They still appear in security observability with the action and the protection that made the decision, so you can tell them apart from your own rules. Easel doesn't expose detection signatures or reputation scores.

Platform protections can't guarantee availability during every attack. Put authentication, caching, and narrow custom rules in front of expensive endpoints, and turn on attack challenge mode during an active attack.

Shared responsibility

Easel secures the platform. You secure your application and its data.

Custom rules reduce exposure but can't fix insecure app logic. A rule can keep traffic away from /admin, but only your code can decide whether a signed-in user may read a given record.

Secure your application

Use these Easel controls alongside your own application security:

• Protect previews. Turn on deployment protection when previews show unreleased features or real data. An unlinked URL isn't private.
• Keep secrets in environment variables. Use separate Preview and Production values, and rotate anything that leaks. See Environment variables.
• Start rules with Log. Watch what a new rule matches on the Firewall page before you switch it to Deny or Challenge.
• Add Bypass rules for machine traffic first. Webhooks and API clients can't pass a browser check, so add them before you need attack challenge mode. Keep verifying webhook signatures in your code.
• Send security headers from your app. See Security headers.
• Limit who can change production. Give people the lowest role they need. See Workspace security.
• Test upgrades in Preview before you promote them to production.

Next steps

• Write custom rules
• Turn on attack challenge mode
• Report a vulnerability