Security overview

Start simple, add protection as you grow — the layered path from public key to signed tokens.

error.page is designed to work the moment you paste the snippet — no security setup required to get started. But because your project's API key ships in the browser (it's public by design, like a Sentry DSN or a Google Analytics ID), you may want to add protection so nobody can send forged error reports using a copied key.

Security here is a ladder: start with nothing, add layers as your needs grow. Each is optional and independent, and you'll find every control under a project's Security panel.

The ladder

Layer	Protects against	Effort	Where
Rate limits (always on)	Volume floods from one origin	None — automatic	—
Origin allowlist	Casual & cross-site use of your key	Paste your hosts	Projects
Server-side secret key	Anyone ingesting to your backend endpoints	One header	Projects
Signed ingest tokens	A determined forger with your public key	Server integration	Hardened ingest

1. Rate limits — nothing to do

Every project is bounded by a per-project ceiling and a tighter per-IP cap, on every plan. A single origin can't flood you regardless of which key it holds. This is always on.

2. Origin allowlist — a good default

List the hosts your SDK legitimately runs on and browser ingest is accepted only from those. The Origin header is browser-enforced, so this stops casual copying and cross-site embedding. It won't stop a scripted client that spoofs the header — for that, keep climbing. Set it under Security → Browser origin allowlist.

3. Server-side secret key — for backend reporting

If you report errors from your own servers (not the browser), require a secret X-Secret-Key header. The secret never leaves your infrastructure, so only your backend can ingest. Enable it under Security → Server-side secret key.

4. Signed ingest tokens — best practice

The strongest option: your server mints a short-lived, signed token (a JWT) that the browser attaches to each report. error.page verifies the signature with a secret the browser never sees, so a forger without it can't produce a token we'll trust. You control the token lifetime and refresh cadence, and can require it strictly. This is the recommended posture for security-sensitive apps. See Hardened ingest for the full setup and copy-paste sample code in six languages.

Trust tiers

Once signed tokens are on, every incident is labelled by how it was authenticated — signed, verified (secret key), or unverified. Unverified reports are still visible but are kept out of your headline metrics, so forged traffic can't skew the numbers you act on.