Prosopo Protect is site-wide and API bot protection — the Prosopo detection engine intercepts every request in front of your origin. Deploy at the edge (Cloudflare Workers, AWS Lambda@Edge) or as a server-side integration (nginx, Caddy, custom reverse proxies) — whichever runtime already sits in front of your traffic. On each request Protect consults the Prosopo API for a verdict and applies your Access Rules. Different response shapes for HTML site pages (branded interstitial) and JSON API endpoints (HTTP status + `X-Prosopo-Decision` header). Session-based verdict caching via a first-party `prosopo_session` cookie, and every decision correlated by an `X-Prosopo-Request-Id` header for audit.
Prosopo Protect — Site-Wide and API Bot Protection
Prosopo Protect is site-wide and API bot protection — the Prosopo detection engine intercepts every request in front of your origin, not just a form. Deploy at the edge (Cloudflare Workers, AWS Lambda@Edge) or as a server-side integration (nginx, Caddy, custom reverse proxies) — the same detection engine, Access Rules and portal work either way. Where Procaptcha (the widget) protects a specific form, Protect wraps every request to a site or JSON API.
Detect, decide, explain — on every request
Every request scored, every rule enforced, every decision auditable — at the edge or from your backend.
Intercept
Every request to your origin is scored before it gets there — the Prosopo Protect worker sits inside your CDN's edge runtime (Cloudflare Workers, AWS Lambda@Edge) and consults the Prosopo API for a verdict. Typically single-digit milliseconds from the nearest edge PoP.
Decide
Protect returns `allow`, `block` or `challenge`. Access Rules match on IP CIDR, ASN, country, User-Agent, headers, JA4 TLS fingerprint and OS. Verdicts are cached per-session via a first-party `prosopo_session` cookie so real users see any challenge at most once.
Explain
Every block returns the reason it was stopped — *Inconsistent hardware readings for device*, *Solver service detected*, *Synthetic interaction timings*, *HTTP header fingerprint mismatch*. Every response carries an `X-Prosopo-Request-Id` correlation header. Drill into any block in the dashboard by ID, then filter by detector fired, Access Rule matched, JA4 fingerprint, ASN or timing signal. Stream events to Datadog, Splunk, Elastic or Sentinel for retention alongside your other traffic data.
Why Prosopo
Why teams deploy Prosopo Protect
Stops bots before origin
Every request is scored at the point closest to the visitor — an edge runtime for CDN-fronted sites, or the origin for backend-only deployments — and blocked, challenged or passed through before it ever consumes an application round-trip. Bot load never eats capacity from real users.
Access Rules on every request
Enforce IP CIDR, ASN, country, User-Agent, headers, JA4 TLS fingerprint and OS rules from a single dashboard. Rules apply the moment they're saved — no code deploy, no re-provisioning.
Single-digit-millisecond decisions
Protect calls the Prosopo API from the edge PoP closest to the request. The extra round-trip is measured in milliseconds and stays well under the latency budget of authentication, checkout and search endpoints.
Different verdicts for HTML and JSON
HTML pages get a branded, server-rendered interstitial when blocked. JSON APIs get the appropriate HTTP status code and an `X-Prosopo-Decision` header (`allow` / `block`) — plus an `X-Prosopo-Status` protocol header on 401 responses when the client needs to init a session or handle a challenge. Configurable per path type.
Session-aware caching
A first-party `prosopo_session` cookie caches the verdict for the duration of a legitimate session, so real users see any challenge at most once and subsequent requests skip the API round-trip entirely.
Every block comes with a reason
Blocks come back with the name of the specific detector — *Inconsistent hardware readings for device*, *Solver service detected*, *Synthetic interaction timings*, *HTTP header fingerprint mismatch*. Not a numerical risk-score bucket. Every response carries an `X-Prosopo-Request-Id` correlation header so any block can be drilled into by ID in the same view Prosopo engineers use to build the next detector.
What Prosopo Protect stops
Protect blocks the automated attacks that specifically depend on hitting your origin at volume:
- Scraping by AI-training crawlers, price aggregators and look-alike competitors — enforced at the edge, so scraper traffic never consumes origin capacity or shows up in access logs.
- Credential stuffing against login and password-reset endpoints — blocked before it reaches the authentication layer.
- Denial of inventory and ticket scalping — Access Rules by ASN and JA4 fingerprint on checkout endpoints catch the scalper-toolkit signature at the door.
- API abuse — carding, enumeration, mass-signup, scraping-via-API. Different verdicts for HTML pages and JSON APIs so client applications handle blocks cleanly.
- Unwanted AI-agent traffic — enforce a policy of "verified crawlers welcome, unauthorised agents challenged" on every request, per endpoint pattern.
- Stealth-headless browsers on residential proxies — the exact profile that gets past Cloudflare Bot Management's default posture, caught by JA4 fingerprinting and behavioural signals.
How Protect stacks with Procaptcha
Procaptcha (the widget) and Protect (the edge product) are peers. Same detection engine underneath, different install paths for different jobs:
| Procaptcha (widget) | Prosopo Protect (edge) | |
|---|---|---|
| What you install | A <script> on a form | A Cloudflare Worker or Lambda@Edge function |
| What it protects | One form (login, signup, checkout, contact) | An entire site, API or endpoint pattern |
| When to reach for it | Per-form verification, drop-in reCAPTCHA/hCaptcha replacement | Whole-site enforcement, scraping defence, API abuse, edge access control |
| Deployment surface | Any HTML page with a form | Cloudflare Workers, AWS Lambda@Edge |
| User experience | Widget renders on the form | Blocked / challenged requests get a branded interstitial (HTML) or status code (JSON) |
| Access Rules | ✓ | ✓ |
| Same dashboard, portal, event stream | ✓ | ✓ |
Procaptcha for per-form verification; Protect for whole-site or API-wide enforcement. Pick the one that matches how you want to intercept traffic — you don't have to run both.
Sites and APIs — same worker, different verdicts
One Protect deployment handles both HTML site traffic and JSON API traffic on the same origin. The detection engine and the Access Rules are identical for both; only the block/challenge response shape changes to match what the client expects:
| HTML site pages | JSON API endpoints | |
|---|---|---|
| Block response | Server-rendered branded interstitial (logo, colours, typography configurable) | 403 with X-Prosopo-Decision: block |
| Challenge response | Interstitial page hosting a captcha the visitor solves before the request proceeds | 401 with X-Prosopo-Status: challenge — protect.js on the client intercepts the header, shows the challenge, and retries the request on success |
| Session-init response | Handled inline in the bootstrap | 401 with X-Prosopo-Status: no-session — protect.js intercepts and calls /session/init before retrying |
| Session cookie | First-party prosopo_session set by Protect, verdict cached until it expires | Same cookie when the caller is a browser; API-only clients (mobile app, server-to-server) fall through to the standard no-session flow |
| Configuration | Per path pattern in the dashboard | Per path pattern in the dashboard |
| Access Rules | Same rule set | Same rule set |
You configure which paths are treated as HTML vs JSON in the same dashboard as your Access Rules; every rule can be scoped per path type as well as per endpoint pattern.
Runtimes
Deploy Protect wherever your ingress traffic already lands — edge or server-side. Same detection engine, same Access Rules, same portal in every case.
Edge integrations:
- Cloudflare Workers — deployed as a Worker script bound to your zone or specific routes. Runs on Cloudflare's global network of edge locations. Compatible with the rest of your Cloudflare configuration (cache rules, page rules, Worker chains) without conflict.
- AWS Lambda@Edge — deployed as a Lambda function associated with your CloudFront distribution. Runs at CloudFront's PoPs before the request reaches your origin, so bot traffic never enters your AWS account.
Server-side integrations:
- nginx — as a subrequest filter in front of your upstreams.
- Caddy — as a handler in your Caddyfile.
- Custom reverse proxies — any HTTP-terminating layer that can consult the Prosopo API on incoming requests and act on the returned verdict.
More runtimes are on the roadmap. If yours isn't listed today, get in touch — we'll walk through what's available.
Access Rules reference
Access Rules match on any combination of the following signals extracted from the incoming request. Every rule is stored as a policy (block, restrict, or a captcha type / difficulty step-up) plus a scope (which signals to match on). Full reference in the Access Control Rules documentation.
- IP CIDR — match specific IPs or IP ranges (stored as
numericIp+ min/max mask internally) - ASN — target hosting networks, VPN providers, mobile-proxy pools by network operator
- Country — geographic gating by country code
- User-Agent — hashed match against known scraper toolkits (
userAgentHash) - Headers — hashed match on the request-header signature (
headersHash) for fingerprinting stealth-automation frameworks - JA4 TLS fingerprint — catch stealth-headless frameworks that spoof user-agent but can't spoof the TLS handshake structure (
ja4Hash) - OS — server-side OS classification from User-Agent (
os), matched on exact tag
Rules can be scoped globally, per client (site key), or per group. Rules that would defer the block until the verify step (e.g. so the attacker still pays the captcha-solving cost before being rejected) are supported via a deferToVerify flag on the policy.
Not an Access Rule dimension: network-class filtering (VPN / proxy / Tor / datacenter / mobile / satellite / crawler) is handled by the Spam Filter's Traffic Filter and evaluated during the same verification. Enable both if you want IP-based rules stacked with network-class rejection.
Compliance and data handling
Protect processes only the request metadata needed for the verdict — IP, headers, JA4 fingerprint, request timing. No cookies are set on the visitor beyond the first-party prosopo_session verdict cache, no cross-site tracking, no personal data harvested for downstream purposes. EU-only verification endpoints are available on request for GDPR-strict deployments. See the GDPR-compliant CAPTCHA product page for the full data-handling posture.
Related
- The Prosopo Platform — the platform-level view: what Prosopo detection catches across Procaptcha (widget), Protect (edge), and Spam Filter (add-on).
- Access Control — the Access Rules reference in more depth.
- Prosopo Protect edge documentation — full technical reference for the Cloudflare Worker and Lambda@Edge deployments.
- Stop web scraping with Prosopo Protect — the primary use case, worked through end-to-end.
One deploy to live
Deploy the Worker or Lambda@Edge, add a rule, watch monitor mode until the baseline looks clean, then enforce.
1
Step 1: Deploy the Worker
Publish the Prosopo Protect Worker script to your Cloudflare zone, or associate the Lambda@Edge function with your CloudFront distribution. Under 20 lines of configuration for either. See the [Protect edge documentation](https://docs.prosopo.io/en/protect-edge/) for the full walkthrough.
2
Step 2: Author Access Rules
Add rules in the Prosopo dashboard — block ASNs known for scraping, gate high-risk countries on your checkout endpoint, whitelist a partner IP range on your API. Rules take effect the moment they're saved, without a re-deploy.
3
Step 3: Baseline, enforce, investigate
Run in monitor-only mode against live traffic first — Protect logs every verdict but doesn't block. Compare against your baseline of legitimate traffic. When the numbers look clean, switch to enforcement. Every block is traceable to a specific rule via the `X-Prosopo-Request-Id` header.
By the numbers
Trusted by companies of all sizes.
Active websites
0+
Monthly verifications
0+
Bots stopped per month
0+
Reviews
Our customers love us.
Hundreds of businesses have made the switch from reCAPTCHA and hCaptcha to Prosopo. Here's what they have to say.
Frequently Asked Questions
What is Prosopo Protect?
How is Prosopo Protect different from Procaptcha (the widget)?
Procaptcha is the client-side widget you embed on a form — a <script> tag that adds a verification step to login, signup, checkout or any other form; your backend verifies the returned token via a `/siteverify` call. Prosopo Protect is the edge layer that wraps every request to a site or JSON API, before it reaches your origin. Same detection engine, same Access Rules, same portal — different scope. Procaptcha for per-form verification, Protect for whole-site or API-wide enforcement. Pick the one that matches how you want to intercept traffic.
Where does Prosopo Protect deploy?
Two paths, same detection engine. **Edge**: Cloudflare Workers and AWS Lambda@Edge as first-party integrations. **Server-side**: nginx, Caddy or a custom reverse proxy — anywhere already handling your ingress traffic. Either way you get the same Access Rules, the same verdict headers and the same portal.
What verdicts does Protect return?
One of three per request: `allow` (request passes through untouched, carrying an `X-Prosopo-Decision: allow` header), `block` (Protect serves a branded interstitial on HTML paths, or a 403 with `X-Prosopo-Decision: block` on JSON API paths), or `challenge` (Protect serves a captcha interstitial on HTML, or returns a 401 with `X-Prosopo-Status: challenge` on JSON APIs — protect.js on the client intercepts the header, shows the challenge, and retries the request on success). Verdicts are cached per-session via the `prosopo_session` cookie so real users see a challenge at most once.
Can I write my own Access Rules?
Yes. Access Rules match on IP CIDR, ASN, country, User-Agent, headers, JA4 TLS fingerprint and OS, individually or combined. Rules can be scoped per path type (HTML vs. JSON) and per endpoint pattern. Full rule reference in the [Access Control Rules documentation](https://docs.prosopo.io/en/advanced/access-control-rules/).
How does Prosopo Protect stack against Cloudflare Bot Management or DataDome?
Cloudflare Bot Management is included in the Cloudflare Enterprise WAF contract and works well against unsophisticated bots; it is routinely bypassed by stealth-headless frameworks (`puppeteer-extra-stealth`, `playwright-stealth`, `undetected-chromedriver`) running on residential proxies. Prosopo Protect can run inside the same Cloudflare Worker as a second adversarial layer with a different signal set — JA4 fingerprinting, behavioural analysis, adaptive challenge escalation — and every block comes with a reason you can read (*Inconsistent hardware readings for device*, *Solver service detected*, *Synthetic interaction timings*, etc.) rather than returning a black-box score. DataDome ships a similar model at enterprise pricing; Prosopo is the specialist alternative with an open-source client stack and a plain-language reason on every block.
Does Prosopo Protect break my caching?
No. Protect runs before the cache decision — the request is intercepted, Prosopo returns a verdict, and if the verdict is `allow`, the request proceeds to the cache/origin fetch normally. Cached responses are unchanged; only the initial scoring step is added. Verdict caching via `prosopo_session` means repeat requests from the same session skip the API round-trip entirely.
More from Prosopo
What else can Prosopo protect for you?
No matter the threat, we have a solution to keep your business safe.
Product
Accessible CAPTCHA: verification that does not lock people out
An accessible CAPTCHA alternative. Invisible for most users, proof of work rather than an image challenge as the first escalation, image challenges disableable per site, keyboard and screen reader support.
Learn more
Product
Prosopo Protect — Site-Wide and API Bot Protection
Site-wide and API bot protection from Prosopo — deploy at the edge (Cloudflare Workers, AWS Lambda@Edge) or as a server-side integration (nginx, Caddy, custom reverse proxies). Access Rules on every request, allow/block/challenge verdicts, branded interstitials on HTML pages, clean HTTP status + header on JSON APIs.
Learn moreProduct
Residential proxy detection
How Prosopo detects residential proxies — TCP fingerprint interrogation, IP intelligence, and a self-maintained proxy-vendor catalogue. Available on the Enterprise plan.
Learn more
Product
Access Control — the Customer-Authored Layer
Access Control is the customer-authored rules layer of the Prosopo platform — layered on top of the named-detector library that catches the bulk of bots by default.
Learn moreProduct
Enterprise Bot Protection — the Prosopo Platform
Enterprise bot protection from Prosopo. One detection engine, delivered as a widget (Procaptcha) or at the edge (Prosopo Protect), same dashboard for both. Every block comes with a reason, in plain words, rather than a black-box score.
Learn moreProduct
Invisible CAPTCHA
Prosopo's Invisible CAPTCHA is the invisible-first mode of Procaptcha — real users see nothing, and every block on a suspected bot comes with a reason you can read.
Learn moreProduct
Procaptcha: the GDPR-compliant CAPTCHA widget
Procaptcha is Prosopo's CAPTCHA widget — a drop-in reCAPTCHA and hCaptcha replacement, cookieless by default, GDPR-compliant, free for the first 10,000 verifications per month.
Learn more
Product
Spam Filter: Add-on for Procaptcha and Prosopo Protect
Spam Filter is a Procaptcha add-on that blocks fake signups, throwaway emails and abusive-network traffic during each verification — without you writing any extra integration code.
Learn more