How WebDecoy Integrates With Cloudflare and AWS

Most bot-mitigation vendors want to become your infrastructure — an inline proxy, a DNS cutover, a new single point of failure. WebDecoy takes the opposite bet: your edge already exists. Cloudflare fronts your traffic; AWS WAF guards your load balancers. What’s missing isn’t another hop — it’s a verdict worth enforcing. So WebDecoy supplies the verdict and your own edge carries it out: a Cloudflare Worker gates protected routes on session clearance, and AWS WAF holds the fingerprint rules for the bots that never run a browser at all.

Here’s the whole thing, from both sides of the request.

The customer’s journey

Setup, once

1. Copy the site key. In the dashboard under Integrations → Clearance setup, grab your site key — it’s publishable, so it goes straight into markup.

2. Add one script tag.

   <script src=".../webdecoy.global.js" data-site-key="..." async></script>

   From now on, real browsers silently earn a wd_clearance cookie while they browse — minted in the background during idle time, no interstitial, no widget, nothing to click.

3. Deploy the edge validator. The Cloudflare Worker deploys to your zone with a single wrangler deploy. This is the piece that actually checks tokens on each request — and it fails open: if it can’t reach WebDecoy, it forwards the request untouched. The validator can slow a bot down; it can never take your site down.

4. Configure the policy. In the dashboard, scope which routes require a token — typically /login, /checkout, /api/*, not the whole site — and set up the two allowlist paths for legitimate tokenless clients: verified bots (Googlebot and friends, verified by published ranges and reverse DNS, never by User-Agent) and machine service tokens for your partners, monitors, and jobs.

Rollout, without holding your breath

Enforcement starts in monitor mode. Nothing gets blocked — but the validator tags every request with an x-wd-clearance header showing exactly what would have happened, and the audit log records the configuration as you build it. You watch the pass/challenge split until it looks right — real users passing, automation getting flagged — and then flip the toggle to enforce. That’s the whole cutover.

Operating it, day to day

The daily surface is small: watch detections, the deny-list, and the audit log. Issue a machine credential for a new partner; one-click revoke one that leaked. Manually deny a fingerprint that’s causing trouble, or lift a denial that’s expired its welcome. Every one of those changes lands in the audit trail with who did it — including the denies the system issued automatically.

Where AWS WAF fits

The clearance gate is built for browser-shaped traffic — the hard case. But plenty of hostile traffic never runs a browser: datacenter scrapers, scripted probes, credential-stuffing tools. For those, Response Actions push rules straight into your AWS WAF Web ACL: a managed JA4 fingerprint rule that follows a confirmed rotating actor across every IP it uses, and expiring IP blocks for one-off offenders. Fingerprint rules are deliberately reserved for confirmed rotators — behavior no legitimate user population produces — so a shared fingerprint is never blindly blocked. And like everything else here, it supports a Count-only monitor mode before you let it bite.

Two layers, one detection brain: AWS WAF handles the bots that stand out at the TLS handshake; the clearance gate handles the ones that don’t.

The visitor’s journey

This is the decision the edge validator makes on every request to a scoped route:

• A real human, browsing normally. The SDK mints their cookie in the background on the first page or two. By the time they reach /checkout, they already carry a valid token and pass invisibly. Zero friction.
• A real human deep-linking straight to /login before their cookie exists, with enforcement on: a one-time invisible check mints the token and reloads. One extra beat, once. (In monitor mode they simply pass, tagged.)
• Anyone on an unscoped page — most of the site — passes with no token required at all. The gate exists only where you scoped it.
• A good bot — Googlebot, a welcome AI crawler — is tokenless by nature but passes via the verified-bot allowlist: proof by reverse DNS and published ranges, not by a spoofable string.
• A partner API or uptime monitor carries its machine service token in a header and passes on proof, not on its IP address.
• A scraper hitting a scoped route with no token: challenged, can’t pass the client check (it’s headless or automated), 403. On 10,000 rotating IPs it still needs a valid token on each request and can’t mint one. Rotation buys it nothing.

The part that ties it together

Here’s the payoff, and it’s the reason the feature exists.

Consider the sophisticated bot that’s good enough to pass the browser check. It minted a token. It’s sailing through your protected routes, indistinguishable — for now — from a customer. Then it touches one of your decoys: a link no human can see, a path no honest crawler follows.

Because it’s carrying the wd_clearance cookie, that decoy hit hands WebDecoy the token. WebDecoy denies the exact fingerprint the token is bound to, the live token is revoked within about a minute, and the client can’t mint another — on any IP, until the lockout expires. No one clicks a honeypot by accident, so this is proof, not a guess.

And “decoy” means every deception surface. The tripwires you plant with the SDK — hidden honeytoken links in your own pages — forward the session’s token on a violation and feed the identical deny path. Deliberately, nothing else does: heuristic rules like rate limits and filters never touch the deny-list, and the mint gate stays lenient. The turnstile lets almost everyone in; the tripwires and decoys are the pressure plates, and only stepping on one locks you out.

That’s the arc: detection (a decoy) feeds enforcement (a deny) that your own edge carries out (revoke, and refuse re-minting). You set it up once. The visitor never notices. And the scraper that beat the front door gets locked out the moment it touches a tripwire.

That closed loop is what makes enforcement rotation-proof without collateral damage to real users — the thing IP rules and fingerprint rules, on their own, structurally cannot do. We wrote up the architecture behind it in Closed-Loop Bot Enforcement in Your Cloudflare & AWS WAF, and the setup reference lives in the docs.