Session Clearance
Session clearance is an enforcement model where real sessions earn a signed pass that travels with the client, so IP rotation no longer resets a bot's slate.
Session clearance is an enforcement model in which a session proves it’s legitimate once and carries a signed pass from then on, instead of the site trying to blocklist every bad fingerprint and IP address.
How it works
- A real browser passes a client-side verification check with zero user friction.
- The session earns signed clearance that travels with the client, not with the IP address.
- Protected routes (login, checkout, scraped endpoints) ask one question: does this request carry valid clearance? Missing clearance on a sensitive route earns a challenge; passing the challenge lets a real user’s session self-heal.
Why it defeats IP rotation
Rotation attacks the keying of enforcement: every new IP resets an IP-based rule, and a fingerprint shared with real users can’t be blocked without collateral. Clearance is keyed to neither. It binds to the client session itself. A bot that rotates through a thousand residential IPs carries its missing (or revoked) clearance to every one of them, while a real human on any of those same IPs simply proves their own session and passes. This is the architecture the major enforcement vendors converged on; WebDecoy’s difference is the trigger.
The decoy connection
Most vendors decide who loses access from behavioral estimates. WebDecoy revokes clearance on honeytoken evidence: a decoy hit is deterministic proof, not a guess. A client that trips one has its active clearance revoked within about a minute and is refused new clearance on any IP, durably. That applies to hosted decoys and SDK tripwires alike. And only to them: heuristic signals like rate limits and filters deliberately never drive the deny-list, so enforcement stays proof-based. Fingerprint and IP rules remain as a cheap first layer for datacenter and scripted bots, where they’re safe.
Related terms
- Honeytoken: the ground truth that revokes clearance
- JA4 Fingerprint: the correlation layer beneath enforcement
- Web Bot Auth. Verified identity for legitimate bots, checked before enforcement
Deep dive: Closed-Loop Bot Enforcement in Your Cloudflare & AWS WAF
Frequently Asked Questions
Why not just block a bot's fingerprint or IP? +
Because both rules fail against the hard case. IP rules lose to rotation. Residential proxies give a bot thousands of fresh addresses. Fingerprint rules lose to collateral: a real browser automated from a residential IP looks identical to the human next door, so blocking the fingerprint blocks them both. Clearance sidesteps the dilemma by enforcing on the individual session instead of a shared attribute.
Do real users notice session clearance? +
No. A real browser passes the client-side check without friction and its session carries clearance from then on. Only clients that fail the check: or that have tripped a decoy, encounter a challenge on protected routes.
See these concepts in action
WebDecoy puts deterministic detection and rotation-proof enforcement behind a 5-minute setup.