Enabled configurations—Configuration state, not protection status
Customer enforcementBackend requiredSDK setup is not automatic enforcement
Site configuration and backend credentials are saved privately to your organization. A local browser SDK and authenticated verifier are available. Your backend must verify each request before executing it; saving a site alone does not protect an API.
CONFIGURATION
Sites & credentials
Select a site to manage access
Your sites
Loading sites…
Add a site
Public site key
This identifies the site; it is not a secret or backend API credential. Use it only in the browser SDK; keep backend credentials private.
Backend credentials
Server-only credentials, scoped to this site. Never put them in frontend code. Use the authenticated verifier before your protected handler.
Save this secret now
This is the only response that contains the secret. Store it in your backend's secret manager. It cannot be retrieved again.
REQUEST ACTIVITY
Live outcomes
Server-side verifier results for the selected site. Ratios are measurements, not proof of DevTools. Inconclusive readings are not a clean-browser verdict and do not trigger the timing rule. Resampled means a second, bounded measurement passed the same quality checks. Old records may lack a reason. Severity is a configured weight, not a probability. Only authenticated proofs contribute browser observations.
Select a site to view its request outcomes.
Time
Session alias
Outcome
Observed / diagnostic
WASM ratio
Response policy
Severity
Up to 1,000 events per site and 20,000 across this service, retained for at most 7 days while cleanup is active. Older records may be evicted sooner. Request bodies, URLs, proofs and raw browser reports are not stored here.
One response for your site. Choose which observations trigger it.
Select a site to edit its policy.
Existing custom policy is still active.
Its separate responses cannot be combined without changing behavior. Nothing has been replaced. Choose an overall response below only if you want to replace this policy.
Saved changes apply to the next verified request. Changing the response or signal selection resets its session allowance. Randomized responses complicate immediate comparisons but do not prevent statistical inference.
PROTECTION / TRUSTED ADDRESSES
IP exclusions
Let trusted addresses through without anti-bot verification, including DevTools checks.
Full anti-bot bypass, not just a DevTools exception. Anyone sharing an excluded public IP can bypass protection for this site. Application login and permissions still apply. Add only addresses you trust and remove them when no longer needed.
Add an address
How it applies
Your backend SDK sends the visitor's connection IP over the authenticated verification API. Excluded requests need no signing proof and skip signal, replay and response-policy checks. They appear as “bypassed” in Live outcomes. Service limits and backend credential checks still apply.
By default, the Node adapter uses the socket address and ignores forwarding headers. Behind a proxy, configure a trusted server-side address resolver first. Never trust a visitor-supplied IP header. The browser SDK may still run if your page loads it; this exclusion bypasses server enforcement.
No addresses excluded. Anti-bot verification applies to every visitor.
IP address
Label
Added
Actions
GETTING CONNECTED
Integrate your site.
Local SDK · not published to npm
Your site's configuration, ready to copy. Install both sides to protect requests.
No sites yet. Add a site to generate its public key and setup examples. Creating an account does not create a site or backend credential.
This site is disabled. Enable it in Sites & credentials before using its SDK.
Service URL
Site ID
Public site key — safe for frontend code
Server-to-server verification API · POST
01 / BROWSER
Sign, then send with your client
Pass the URL, query params, method, headers and serialized body to client.sign(). It returns the randomized proof header without sending your application request. Use fetch, Axios, XMLHttpRequest or your own transport to send it.
Use signed.url and the exact body and headers you signed. Params use URLSearchParams semantics and append to existing query values; do not add them again when sending. Serialize JSON first; automatic body or content-type changes invalidate the proof. Sign again for every new attempt—proofs are single-use.
Signing initializes and renews local sessions automatically. Your transport owns responses: only a 403 with x-antibot-action: rebootstrap calls for client.refresh(), a fresh signature and at most one retry. Do not retry ordinary refusals or uncertain network failures automatically. client.fetch() remains an optional convenience wrapper.
Currently, protected URLs must share the page's origin. This is an existing verifier restriction, not a requirement to use fetch. Allow the service and required WASM/Worker capabilities in your CSP. No backend secret belongs here.
02 / NODE BACKEND
Verify before executing
Download cruva-server.mjs into your backend, next to this module. This is a Node HTTP adapter, not an npm installation.
Mount protectedHandler on the same route used above, before any body parser or application effects. Pass the actual incoming Node request/response. Set server request/header deadlines and handle rejected promises in your HTTP framework.
Backend credential
Set CRUVA_BACKEND_KEY in your backend environment or secret manager. Credentials are site-scoped and shown only when created or rotated; this page never retrieves or inserts an existing secret.
The adapter sends Authorization: Bearer <secret> to the verification API. Keep that call server-side. Browser-only integration does not enforce protection.
Trusted IP exclusions
The current adapter sends clientIp from request.socket.remoteAddress. Download and restart with the updated adapter to enable IP exclusions. Other backends must include the trusted visitor IP in their authenticated verification envelope; missing clientIp never bypasses.
Behind a reverse proxy, supply a synchronous resolveClientIp(request) option to protect() using your framework's correctly configured trusted-proxy resolver. Verify the immediate peer and forwarding chain. Never return a raw visitor-controlled header or exclude a shared proxy address. Invalid resolver output fails closed.
The current Node adapter reports raw incoming HTTP/1 and HTTP/2 header names, without values, to the verifier. Alphabetical ordering checks the entire regular-header sequence from first to last, without a minimum count. HTTP/2 pseudo-headers such as :method are validated separately. The signal is enabled by default under Policies → Request transport and uses the same overall response as your other selected signals.
For native HTTP/2, pass the request/response from Node's http2.createSecureServer compatibility API to protect(). Reverse proxies can sort legitimate requests or change protocols; this is not proof of automation. Disable the signal if your ingress sorts legitimate traffic. Set observeHeaderOrder: false in the server-side protect() options to omit collection. Download and restart with the updated adapter. HTTP/3 is not captured, and a proxy's forwarded order is not necessarily the browser's original order.
ACCESS
Account session
Signed in as
Session expires
Organization ID
Password resets are handled by your deployment administrator. Signing sessions do not use your dashboard cookie.