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

  1. A real browser passes a client-side verification check with zero user friction.
  2. The session earns signed clearance that travels with the client — not with the IP address.
  3. 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.

  • 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.

← All glossary terms

See these concepts in action

WebDecoy puts deterministic detection and rotation-proof enforcement behind a 5-minute setup.

Start Free Trial