DEV Community: webdecoy

How to Block Bots on WordPress Without a CAPTCHA or a WAF

webdecoy — Sun, 13 Sep 2026 18:32:08 +0000

Most WordPress bot protection works by estimating. It looks at a User-Agent, a request rate, a header set, and produces a guess. Good scoring gets you a long way — but every guess carries a false-positive tail, and on a checkout page that tail has a price.

There's a second approach that doesn't guess at all: set things that only a bot can touch.

This is a practical guide to doing that on WordPress. I'll use the WebDecoy plugin for the concrete examples because it's the one I work on and it's free and local, but the technique is the point — you could build most of it yourself in an afternoon.

Why deception is different from detection

A detector says "this request is 80% likely to be automated." A trap says "this request fetched a URL that appears nowhere in your sitemap, nowhere in your HTML, and is disallowed in robots.txt."

The second statement isn't a probability. A human browsing your site cannot accidentally do it.

That property is worth a lot, because the expensive failure in bot blocking isn't the bot you miss — it's the customer you block. A signal with no false-positive tail can drive a hard action (block, ban, refuse checkout) that you'd never dare trigger from a score alone.

So a sane architecture uses both: scoring for breadth, deception for certainty.

The four traps worth setting

1. Tripwire paths

Hidden URLs that only crawlers and scanners request. Nothing links to them, they're disallowed in robots.txt, and they don't appear in your sitemap. Anything that requests one has either ignored robots.txt or is enumerating paths.

WordPress has an unusually rich set of these available, because attackers probe the same handful of things on every WP site:

Fake vulnerable-plugin paths (/wp-content/plugins/<known-CVE-plugin>/…)
An XML-RPC trap
An author-enumeration canary (/?author=1 style probing)

These are the "public scanner" tier. They fire constantly on any site with a public IP, so treat them as a steady background signal rather than something to alert on.

2. Honeytoken links

An invisible decoy link injected into your pages. A human never sees it; a link-following scraper follows it.

The distinction from a tripwire path matters: a tripwire catches something guessing at URLs, a honeytoken catches something parsing your HTML and following every href. Different populations, and the second one is usually the scraper you actually care about.

Because nothing legitimate ever touches it, this is the one trap worth an alert.

A small war story on that: an earlier version of the plugin emailed the admin when the canary tripped. Sensible idea, terrible in practice — the canary link is on every public page, so busy sites got an email every hour, forever. It got removed one release later. Detections belong on a detections page, not in your inbox. If you build this yourself, learn from that: alert on the first trip per source, not every trip.

3. Deceptive files with canary credentials

This is the sharpest one. Serve plausible-looking responses for the files attackers always probe:

/.env
/wp-config.php.bak
/backup.sql
/phpinfo.php

Instead of a 404, return a realistic file — seeded with per-site canary credentials that are valid nowhere.

Now you have a second-stage signal. Requesting /.env tells you someone is probing. Using the database password from that fake .env tells you someone read it and is trying it. That's not reconnaissance any more, that's an attempted intrusion, and it earns an immediate critical classification.

The per-site part matters: the canary has to be unique per install, or a single leaked credential list makes every site's canary identical and useless.

4. A decoy WooCommerce coupon

If you run a store: a hidden coupon code that appears nowhere a customer could find it. Coupon-scraping bots harvest and try codes in bulk. Applying that code at checkout is proof of automation — there is no innocent path to it.

This one is my favourite because it sits exactly where the money is. Card-testing and coupon-abuse bots both hit checkout, and checkout is where a false positive costs you an actual order. A deterministic signal there is worth more than anywhere else on the site.

Start in monitor mode. Actually do it.

The plugin ships in monitor mode by default — it records what it would have done without doing it. That default is correct and you should respect it rather than flipping to blocking on day one.

I wrote a whole piece on why bot detection false positives are a business event, and the short version applies here: you cannot know your false-positive rate until you've watched real traffic, including the weird tail of it — corporate proxies, carrier-grade NAT, accessibility tooling, your own uptime monitors.

Run it in monitor mode across at least one full weekly cycle. Then look specifically at what would have been blocked and ask whether you recognise anyone in there.

# check current mode and counts
wp webdecoy status

# watch first
wp webdecoy config set mode monitor

# ...then, once the would-block list looks clean
wp webdecoy config set mode block

If you manage client sites, you can lock the mode in wp-config.php so a settings save can't silently drift it:

define( 'WEBDECOY_DEFAULT_MODE', 'monitor' );  // or 'block'
define( 'WEBDECOY_MAX_LOG_RETENTION', 90 );    // days, default 30

One design detail I think is worth stealing: an unrecognised value for that constant is ignored rather than guessed. Forcing 'block' on a typo would start enforcing on a site that asked to watch; defaulting to 'monitor' would disarm one that asked to enforce. Neither is a safe guess, so it refuses to make one.

Verify the pipeline actually works

The failure mode nobody talks about with security plugins: it's installed, the dashboard is green, and it isn't actually inspecting anything — because a page cache sits in front of it, or the real client IP never arrives, or the scanner script is being stripped by an optimizer.

Two ways to prove it end to end:

Trip your own canary. The honeytoken's secret path is shown in the settings with a "trip it now" link. Open it and watch the detection land. That exercises the full path: request → trap → scoring → storage → UI.

Hit it with the reserved test User-Agent:

curl -A "WebDecoy-Test/1.0" https://your-site.example/

The plugin records a detection and answers with a 403 JSON receipt, so the curl output itself shows it acted. The test never blocks your IP, never trips enforcement rules, and never fires alerts.

That second one is the check I'd want in a deploy script. A green admin page proves the plugin is installed; a 403 receipt proves it's in the request path.

Don't break your SEO on the way

The single most common way to hurt yourself here is blocking a crawler you needed.

Never allowlist by User-Agent string. Matching Googlebot and letting it through is a bypass, not an allowlist — anyone can send that string, and attackers do precisely because so many plugins trust it. Use forward-confirmed reverse DNS:

Reverse-DNS the requesting IP to a hostname
Check the hostname ends in a verified domain (.googlebot.com)
Forward-resolve that hostname back to an IP
Confirm it matches the original IP

Any decent plugin does this for you — WebDecoy ships a list of 60+ verified crawlers — but check that yours does, because "recognises Googlebot" and "verifies Googlebot" are very different claims.

AI crawlers are a separate decision from search crawlers. GPTBot, ClaudeBot, PerplexityBot and friends can be blocked independently of Googlebot and Bingbot, and you want that as its own switch rather than robots.txt surgery. Worth deciding deliberately: some AI search engines send referral traffic worth having, while pure training scrapers return nothing.

What this doesn't solve

Being honest about the limits, because "deception" can sound like a silver bullet:

Traps catch bots that explore. A scraper that only fetches linked, allowed pages at a human pace will never touch one. That population needs the scoring layer, not the trap layer.
A trap is one signal, not a policy. You still need to decide what a trip does — block, ban, challenge, refuse checkout — and for how long.
Application-layer blocking still costs you the request. The bot reached PHP. If you're being flooded rather than probed, you want blocking at the edge; application-layer detection is where you identify who to push there, not where you absorb volume.
Local means local. No third-party IP reputation, no cross-site intelligence, unless you opt into a cloud tier. That's a genuine tradeoff, not just a privacy talking point.

Install

wp plugin install webdecoy --activate

Or Plugins → Add New → search "WebDecoy". Requires WordPress 6.1+ and PHP 7.4+ (tested to 7.0.x). GPL, free, and with no API key it makes zero external connections — front end or back end. Detection data lives in your own database and cleans itself up after 30 days.

The mental model I'd leave you with: scoring tells you who's probably a bot, deception tells you who definitely is. Most setups have plenty of the first and none of the second, and the second is the cheaper half to build.

If you've deployed honeypot paths or canary tokens on a production site — what actually tripped them first? On ours it's almost always a plugin-vulnerability scanner, long before anything interesting shows up.

Originally published at webdecoy.com.

Bot Protection for WordPress Without CAPTCHAs or API Keys

webdecoy — Sun, 13 Sep 2026 18:29:59 +0000

Most WordPress security plugins ask you to configure rules, connect APIs, tune thresholds, and then hope you got it right. We went the other way: install, activate, done. Every protection layer works immediately with zero configuration and no API key.

This post is about why that design, and what it actually stops.

The two camps, and why neither worked

WordPress powers a large share of the web and is the most targeted CMS for automated attacks. Comment spam, brute force logins, fake registrations, credential stuffing, and WooCommerce carding are daily realities for site owners.

Existing solutions fall into two camps:

CAPTCHA-based plugins force every visitor to prove they're human. Conversion rates drop. Accessibility suffers. And vision models can now solve image challenges programmatically — so you're paying a UX tax for a test the attacker passes and your customer resents.

API-dependent plugins require accounts, keys, and external services. They charge per request, which means costs spike during attacks — exactly when you need protection most. If the API goes down, your protection disappears with it.

So: all detection runs locally, on your server and in the visitor's browser. No external dependencies. No per-request billing. No CAPTCHAs. Humans never see a challenge.

Zero-config, and what that actually means

Earlier versions required an API key before protection hooks would activate. That requirement is gone. Every detection layer — server-side analysis, client-side fingerprinting, proof-of-work challenges, rate limiting — runs locally without any external connection.

An optional Cloud integration adds threat intelligence feeds, VPN detection, and cross-site threat sharing for teams managing multiple installs. The core protection needs none of it. That's the part worth stressing: the free path isn't a crippled trial, it's the whole detection engine.

SHA-256 proof-of-work instead of a CAPTCHA

Rather than showing a challenge, the plugin issues invisible SHA-256 proof-of-work. The browser computes a valid hash before a form submission is accepted. For humans on modern hardware this takes milliseconds and is completely invisible. For bots running thousands of concurrent sessions, the compute cost makes attacks economically unviable.

Same principle as FCaptcha, our open-source CAPTCHA replacement, adapted for WordPress's form handling.

4-factor behavioral scoring

Every form submission is evaluated across four weighted signal categories:

Behavioral (40%) — interaction timing, keystroke patterns, mouse movement characteristics
Environmental (35%) — browser consistency checks, headless detection, automation framework markers
Temporal (15%) — time-on-page, submission velocity, session duration anomalies
Form (10%) — honeypot triggers, field completion order, paste detection

Each category contributes a weighted score; the combined result decides allow, flag, or block. No single signal is decisive — the system looks at the full picture. That's deliberate: binary checks are how you end up blocking a real customer on a Tuesday because they had one unusual header.

What it protects

Comment and form spam. Invisible detection is injected into comment, login, and registration forms. Honeypot fields catch simple bots, proof-of-work stops headless browsers, behavioral scoring catches everything in between. Hooks activate automatically for standard WordPress forms.

Login and registration attacks. Brute force and fake registrations are blocked through rate limiting and behavioral analysis. The plugin tracks failed-login velocity per IP and blocks sources that exceed thresholds.

WooCommerce carding. Fraudsters test stolen cards against your checkout. Every declined transaction generates processor fees — enough declines and your payment provider drops you. The plugin detects the pattern: multiple small transactions from one IP, rapid checkout velocity, different card numbers in quick succession, headless signatures on the checkout page. Detected carders are blocked before reaching your payment processor.

Content scraping and AI crawlers. Identifies and blocks unauthorized scrapers including GPTBot, ClaudeBot, and others. Legitimate crawlers — Googlebot, Bingbot, and 60+ more — are verified through forward-confirmed reverse DNS, not by trusting the User-Agent string, and always allowed through. Your SEO stays intact.

MITRE ATT&CK path analysis. Requests probing for wp-config.php, admin endpoints, backup files, and other sensitive paths are flagged as reconnaissance — not just logged, but fed into the scoring model as signals.

Under the hood: two layers that cross-reference

Server-side analysis examines every request before WordPress processes it: user-agent patterns, header consistency, request rates, IP reputation, path analysis. Known good bots are verified via reverse DNS and exempted immediately.

Client-side fingerprinting runs in the visitor's browser checking for headless markers, automation framework signatures (Playwright, Puppeteer, Selenium), browser API consistency, and environmental anomalies. The fingerprint is submitted alongside form data and validated server-side.

When the two layers disagree — a request claims to be Chrome but client-side checks detect Playwright markers — the threat score increases significantly. The disagreement is the signal.

IP management

Individual addresses and CIDR ranges
IPv4 and IPv6
Optional expiration (temporary blocks that auto-release)
Bulk operations for large block lists

Expiring blocks matter more than they look. A permanent block list is a growing pile of decisions nobody revisits, and shared IPs rotate — today's abusive address is next month's office NAT.

Local dashboard

A statistics page with trend visualization: detection volume over 30 days, threat type distribution (spam bots, scrapers, credential stuffing, carding), top blocked IPs and their attack patterns, and source analysis. The detections interface supports date filtering, CSV export, and bulk operations.

All of it renders from your own database. Detection data cleans itself up after 30 days, and the charting library is bundled into the plugin rather than loaded from a CDN — so the dashboard makes no third-party requests either.

Install

wp plugin install webdecoy --activate

Or Plugins → Add New → search "WebDecoy". Protection starts immediately; there is no step three.

Requirements: WordPress 6.1+, PHP 7.4+. GPL v2, open source at github.com/WebDecoy/wordpress-plugin.

If you want the detection internals — the scoring table, the MITRE mapping, the HMAC-signed proof-of-work design — I wrote those up separately in Inside a WordPress Bot Detection Engine.

If you run WooCommerce: have you actually measured your decline rate from card testing? It's the one bot cost that shows up directly on a processor invoice, and most stores never look.

Originally published at webdecoy.com.

Related reading:

Inside a WordPress Bot Detection Engine

webdecoy — Sun, 13 Sep 2026 16:54:36 +0000

The WebDecoy WordPress plugin ships with zero configuration required. But underneath the "install, activate, done" experience is a multi-layer detection engine that scores every request across server-side signals, client-side fingerprints, behavioral analysis, and proof-of-work verification.

This post walks through how each layer works, how they combine into a single threat score, and why this architecture catches bots that simpler approaches miss. It's a WordPress plugin, but the scoring design applies to any request pipeline.

The Detection Pipeline

Every request flows through a pipeline that evaluates it before WordPress processes it:

Incoming Request
  │
  ├─ Is this IP blocked? → Yes → Block page
  │
  ├─ Is this a known good bot? → Verify via reverse DNS → Allow
  │
  ├─ Server-side analysis
  │    ├─ User-Agent patterns
  │    ├─ HTTP header consistency
  │    ├─ MITRE ATT&CK path matching
  │    └─ Rate limit check
  │
  ├─ Client-side signals (on form submission)
  │    ├─ WebDriver / headless detection
  │    ├─ Automation framework markers
  │    ├─ Canvas / WebGL fingerprint
  │    └─ Behavioral scoring
  │
  ├─ Proof-of-Work verification (on form submission)
  │    └─ SHA-256 challenge validation
  │
  └─ Score aggregation → Allow / Challenge / Block

The first two checks are fast exits. Blocked IPs get rejected immediately. Verified good bots skip detection entirely. Everything else gets scored.

Threat Scoring: 0 to 100

Every detection signal adds points to a threat score. The score determines what happens to the request:

Score Range	Severity	Action
0–19	Minimal	Allow (likely human)
20–39	Low	Log only
40–59	Medium	Optional challenge
60–74	High	Challenge or block
75–100	Critical	Automatic block

The default blocking threshold is 75, configurable in settings. Scores at 40 and above are logged for review.

The scoring is additive. A request doesn't need to fail one dramatic test — it accumulates evidence across multiple signals. A slightly suspicious user agent (+25) combined with missing cookies (+15) and an unusual request path (+20) adds up to 60, enough to trigger a challenge. No single signal is conclusive, but the combination tells a clear story.

Base scores for common signals:

Missing standard headers:      10-30
No cookies on non-first visit:    15
Suspicious user agent:            25
Known bot user agent:             50
curl / wget / python-requests:    35
Automation tool detected:         40
Headless browser markers:         25
Rate limit exceeded:              25
Honeypot field triggered:         60
Fake bot (failed DNS verify):     80

A real Chrome browser hitting a normal page scores near zero. A Python script with a spoofed user agent, no cookies, and missing standard headers quickly crosses the blocking threshold.

Server-Side Analysis

User-Agent and header consistency

The plugin checks the User-Agent against known bot patterns (curl, wget, python-requests, Go-http-client, scrapy, and dozens more) and evaluates header consistency. Real browsers send a predictable set of headers — Accept, Accept-Language, Accept-Encoding, Connection — in a consistent order. Automated tools frequently omit headers or send them in unusual combinations.

Missing Accept-Language is a strong signal. Every real browser sends it. Most HTTP libraries don't unless explicitly configured.

MITRE ATT&CK path matching

This is one of the more distinctive pieces. Rather than maintaining an arbitrary blocklist of "bad" URLs, detection is organized by attacker tactic:

Credential Access (TA0006):
  .env, wp-config.php, .git/, *.sql         → +30 points

Collection (TA0009):
  Backup files, database dumps              → +25 points

Reconnaissance (TA0043):
  Admin probes, user enumeration            → +20 points

Discovery (TA0007):
  Debug endpoints, phpinfo, server-status   → +20 points

When an IP requests /wp-config.php.bak, then /.env, then /.git/config, each request scores individually while the rate limiter tracks velocity. The combined effect is rapid escalation to the blocking threshold.

The mapping isn't only for scoring. It surfaces in the detections table, so you can see a blocked IP was performing credential access reconnaissance rather than just "requesting bad URLs." The categorization tells you what attackers are actually looking for.

Rate limiting

Tracks requests per IP with a configurable window (default: 60 requests per 60 seconds). Exceeding it adds 25 points and can trigger automatic blocking.

The limiter uses the WordPress database for tracking, so it works behind load balancers and CDNs as long as the real client IP is forwarded in a standard header (X-Forwarded-For, X-Real-IP, or CF-Connecting-IP).

Client-Side Detection

The server-side layer catches unsophisticated bots. The client-side layer targets headless browsers, automation frameworks, and tools that spoof headers but can't perfectly replicate a real browser environment.

A scanner script loads with defer so it never blocks rendering, runs environment checks, and submits results alongside form data.

WebDriver detection — the simplest check. Selenium, Puppeteer, and Playwright all set navigator.webdriver = true by default. Stealth plugins override this, but it still catches unmodified tooling.

Headless markers — HeadlessChrome in the UA string, missing chrome.runtime and chrome.app objects (present in real Chrome, absent in headless), PhantomJS signatures on window.

Chrome consistency — a request claiming Chrome should have the chrome global with chrome.runtime, chrome.app, chrome.csi. If the UA says Chrome but these are missing or structurally wrong, the environment has been tampered with.

Behavioral scoring

For form submissions, the plugin evaluates how the user interacted with the page. This is where most sophisticated bots fail, because generating convincing human behavior at scale is genuinely hard.

Behavioral signals (40% weight):
  - Mouse velocity variance
  - Straight-line movement ratio
  - Micro-tremor score (natural hand movement)

Environmental signals (35% weight):
  - Headless browser markers
  - Automation framework detection
  - Browser API consistency

Temporal signals (15% weight):
  - Time on page before submission
  - Form completion velocity
  - Session duration

Form signals (10% weight):
  - Honeypot field triggers
  - Field completion order
  - Paste detection

Mouse velocity variance is particularly effective. Humans move with variable speed — accelerating, decelerating, overshooting, correcting. Bots that simulate movement typically use linear interpolation or simple easing functions, producing unnaturally smooth velocity profiles.

Straight-line movement ratio measures what percentage of movements travel in perfectly straight lines. Humans almost never do, because of micro-tremors and natural imprecision.

Micro-tremor score looks for the tiny involuntary oscillations present in all human hand movement. These have characteristic frequency patterns that are difficult to simulate; their absence suggests input generated by code.

Honeypot fields, rotated daily

Invisible form fields real users never see. If a field receives a value, the submission came from a bot that filled every input on the page.

What makes the implementation interesting is the obfuscation. Instead of obvious names like honeypot or trap, the plugin generates legitimate-looking field names that change daily:

// Field names rotate using a daily seed
// Examples of generated names:
//   contact_name, user_email, address_field, phone_number
// CSS class prefixes mimic common form frameworks:
//   form-, input-, wp-, cf-, gform-, ninja-

Daily rotation stops bot operators hardcoding a skip-list of honeypot names. The realistic naming defeats bots that filter for obvious trap patterns.

Proof-of-Work Challenges

The layer that makes automated attacks economically painful even when bots pass everything else.

When a form loads, the server generates a challenge: a random hex prefix and a difficulty parameter. The client must find a nonce where SHA-256(prefix + nonce) starts with N zero hex characters. There's no shortcut — it's brute force.

Server generates:
  prefix:      "a7f3c8e91b04d265"   (16 hex chars from 8 random bytes)
  difficulty:  4                     (requires 4 leading zero hex chars)
  expires:     current_time + 5 minutes
  signature:   HMAC-SHA256(challenge_data, wordpress_auth_key)

Client computes:
  nonce = 0:  SHA-256("a7f3c8e91b04d265" + "0") = "7f2a..."   (fail)
  nonce = 1:  SHA-256("a7f3c8e91b04d265" + "1") = "b391..."   (fail)
  ...
  nonce = N:  SHA-256("a7f3c8e91b04d265" + "N") = "0000a..."  (pass)

Client submits:  { challengeId, nonce, signature }

At difficulty 4, the client tries roughly 65,536 hashes on average — milliseconds on modern hardware, entirely in the background while the user fills out the form. They never see it.

Why it stops bots: a single challenge is trivial, but the economics change at scale. A bot submitting 10,000 spam comments needs 10,000 challenges — about 655 million hash operations. Achievable, but it costs real compute.

Difficulty also scales with threat signals. An IP already flagged by server-side analysis gets harder challenges. Default difficulty 4 is intentionally low for normal users; suspicious traffic might face difficulty 6, roughly 16 million hashes per challenge.

Replay prevention

Each challenge carries an HMAC signature generated with WordPress's AUTH_KEY salt. The server verifies the signature before checking the hash, which prevents:

Challenge reuse — each challenge ID is single-use
Challenge tampering — difficulty and prefix are signed, so they can't be modified
Challenge forging — without AUTH_KEY, valid signatures can't be generated
Stockpiling — a 5-minute TTL kills pre-solved challenges

Signing rather than storing means the server never writes issued challenges to the database. That keeps the table clean and removes a DoS vector where an attacker floods the challenge endpoint to fill storage.

Good Bot Verification

Not all bots are bad. Googlebot, Bingbot, and 60+ other legitimate crawlers need unimpeded access for indexing, previews, uptime monitoring, and SEO tooling.

Search engines:   Googlebot, Bingbot, YandexBot, Baiduspider,
                  DuckDuckBot, Applebot
Social:           Facebook, LinkedIn, Twitter, Pinterest
Monitoring:       Pingdom, UptimeRobot, StatusCake, Datadog
SEO tools:        Ahrefs, SEMrush, Moz, Majestic
Feed readers:     Feedly, NewsBlur
AI crawlers:      GPTBot, ClaudeBot, PerplexityBot (optional blocking)

For verifiable bots, the plugin does forward-confirmed reverse DNS:

Look up the requesting IP's hostname via reverse DNS
Check the hostname ends with a verified domain (.googlebot.com, .google.com)
Forward-resolve that hostname back to an IP
Confirm it matches the original requesting IP

A fake Googlebot scores +80 — an instant block — because spoofing a search crawler is a strong signal of intent. Results cache in WordPress transients with a 1-hour TTL to avoid repeated lookups.

This matters more than it sounds: matching Googlebot in a User-Agent string and allowing it is a bypass, not an allowlist. Anyone can send that string.

WooCommerce: carding defense

Attackers test stolen card numbers against real checkout flows. Every failed transaction generates processor fees, and a high decline rate can get your payment processing suspended.

Checkout velocity limiting — configurable max checkout attempts per IP per window (default: 5 per hour). Legitimate shoppers rarely attempt checkout more than once or twice. An IP submitting 20 attempts in an hour is testing cards.

Card testing pattern detection — multiple different card numbers from one IP, rapid sequential attempts, and headless signatures on the checkout page all trigger detection, blocking before further transactions reach the processor.

Compatible with classic checkout and WooCommerce Blocks, and declares HPOS (High-Performance Order Storage) compatibility.

Architecture decisions worth calling out

No external dependencies for core protection. The entire detection engine runs on your server. No API calls during request processing, no third-party JavaScript on the frontend. Protection works during API outages, on airgapped installs, and at any traffic volume without per-request costs. Even the admin dashboard's charting library is bundled into the plugin rather than pulled from a CDN, so the plugin makes zero external connections unless you explicitly add a Cloud API key.

Additive scoring over binary decisions. Every signal adds to a score rather than making a pass/fail call. This dramatically reduces false positives: a single suspicious signal might be coincidence, five together are a pattern. No single check that misfires can block a legitimate user on its own.

Daily rotating honeypot names. Static names get learned and skip-listed. Seeded rotation changes them daily while staying deterministic, so the server can verify which fields are honeypots without storing state.

HMAC-signed challenges instead of stored ones. The signature itself proves the challenge is legitimate and unmodified — no database writes, no storage-exhaustion vector.

Getting started

wp plugin install webdecoy --activate

Or: Plugins → Add New → search "WebDecoy" → Install → Activate.

Defaults (sensitivity medium, block threshold 75, rate limit 60/min, PoW difficulty 4) work for most sites. Requires WordPress 6.1+ and PHP 7.4+. GPL-licensed.

If you're building request scoring in any stack, the transferable idea here is the additive model: resist the urge to make any single signal decisive, and let evidence accumulate instead. It's the difference between a detector that's occasionally spectacularly wrong and one that's boringly right.

How do you handle bot scoring — hard rules or weighted signals? Curious what thresholds other people have landed on.

Originally published at webdecoy.com.

Related reading:

Bot Detection False Positives: How to Actually Test Accuracy

webdecoy — Sun, 13 Sep 2026 15:28:21 +0000

The fastest way to lose confidence in bot protection is not to miss a bot. It is to block a real customer.

A missed scraper costs bandwidth or content. A blocked customer costs a sale, a support escalation, and trust that took months to earn. Which is why a bot detection benchmark cannot stop at a single accuracy number. It has to answer a harder question: what happens to real people when this policy leaves the dashboard and starts controlling traffic?

A false positive is a business event

In bot detection, a false positive is legitimate traffic classified as automated. The technical label matters; the consequence matters more. The same wrong classification produces very different outcomes:

Route	Possible false-positive cost
Public article	One page view is challenged or delayed
Login	A customer cannot reach their account
Password reset	A locked-out user cannot recover access
Checkout	Revenue is interrupted at the point of purchase
Public API	A partner integration begins failing
Account creation	A legitimate prospect cannot start a trial

An aggregate false-positive rate hides these differences. A vendor can report a low global rate while causing concentrated damage on one browser, one mobile network, or one high-value route.

So the useful question is not "what is the false-positive rate?" It is: how many known-human sessions did this rule challenge or block on each protected route, and what happened next?

Accuracy is usually the wrong headline metric

Bot traffic is a class-imbalanced problem. Most requests on a customer-facing app are legitimate; the attacks worth stopping are a small slice. In that setting a large accuracy percentage can describe a weak detector.

Suppose a site receives 100,000 requests:

99,000 are legitimate
1,000 are automated attacks
The detector catches 900 attacks
It also flags 200 legitimate requests

The detector is 99.7% accurate. That sounds excellent. It is also blocking or challenging 200 real requests, missing 100 attacks, and producing a bot verdict that is wrong almost one time in six.

Use a small set of metrics together instead:

Precision           = true bot detections / all bot detections
Recall              = true bot detections / all actual bot attempts
False-positive rate = false bot detections / all known-human requests

In the example: precision 81.8%, recall 90%, false-positive rate ~0.2%. At one million legitimate requests per day, that last number is about 2,000 customer requests per day receiving the wrong treatment.

Google's classification metrics guide makes the tradeoff clear: changing a threshold changes all three. There is no threshold you can evaluate independently of the cost of each kind of mistake.

Which usually leads to three operating goals:

Hard blocks favor precision. The evidence should be strong enough that a human is very unlikely to match it.
Challenges balance precision and recall. They provide a recovery path for ambiguous traffic.
Monitoring favors recall. A broad signal is fine when a person or later rule reviews it before enforcement.

One score should not control all three actions.

Build a benchmark that resembles production

A clean lab set with one Chrome version and a few obvious Selenium scripts proves the code runs. It does not establish that the detector is safe for customers. Build from three label groups.

Known-human traffic

Strong human labels come from successfully authenticated sessions, completed purchases that were not reversed, support-confirmed sessions, or employees following a controlled test plan. None is perfect alone — the point is traffic with independent evidence that a real person completed a meaningful action.

Keep the sample representative across:

Desktop and mobile browsers
Older devices and slow connections
Corporate networks, universities, and carrier-grade NAT
VPNs and privacy tools your customers actually use
Assistive technology and keyboard-only navigation
Logged-in customers, anonymous visitors, and partner users
Every route where the policy may eventually enforce

If the known-human set contains only employees on recent MacBooks, the benchmark is measuring employee laptops, not customers.

Known automation

Run controlled clients with Playwright, Puppeteer, Selenium, curl, and any stack relevant to your app. Include slow bots, distributed low-volume clients, headless browsers, and scripts carrying realistic headers.

Trusted automation belongs in the set too. Search crawlers, uptime monitors, accessibility scanners, payment callbacks, and partner integrations are automated — that does not make them hostile.

Unknown traffic

Leave genuinely ambiguous traffic labeled unknown. Do not call every session that failed to convert a bot, and do not call every session that passed a JavaScript check human. Those shortcuts make the detector's own assumptions part of its ground truth.

Freeze the policy during each test

Record the exact configuration behind every verdict: engine version, rule and threshold version, signals that fired, score and proposed action, route group, session identifier, timestamp, allowlist decision.

If thresholds change halfway through a test without a version marker, your final precision number combines two different systems.

{
  "policy_version": "checkout-2026-09-01.1",
  "route_group": "checkout",
  "score": 72,
  "would_action": "challenge",
  "signals": ["headless_mismatch", "velocity_anomaly"],
  "identity": "unverified",
  "outcome": "purchase_completed"
}

The important field is outcome. Without it you can count detections but cannot tell whether a proposed action would have interrupted a customer.

Start in shadow mode

Shadow mode evaluates every request but does not change the response. A request that would have been challenged gets the normal page; a request that would have been blocked reaches the application. The proposed action and its evidence are logged.

This is the safest place to tune thresholds, because the detector sees real traffic while mistakes stay observable rather than customer-facing. For every route group, answer:

How many sessions would have been allowed, challenged, or blocked?
How many would-block sessions later logged in, purchased, submitted a valid form, or called an authenticated API?
Which rules contribute most of the false-positive candidates?
Are errors concentrated by browser, device, geography, ASN, customer, or integration?
How much attack traffic would each threshold miss?

Don't declare victory after a quiet afternoon. The sample should span weekday and weekend behavior, billing cycles, product launches, and campaigns.

The rule of three

The absence of an observed false positive is not proof the true rate is zero. A useful rough check: if a test observes zero errors in N independent known-human sessions, the upper edge of a rough 95% confidence interval is about 3/N.

Zero errors in 1,000 sessions only supports a rate below roughly 0.3%. Zero errors in 100,000 sessions supports a much tighter claim. Report counts beside rates so a reader can tell whether "100% recall" means 2 of 2 attacks or 20,000 of 20,000.

Test low-volume attacks without fooling yourself

A credential stuffer sending two attempts per IP per day never creates an obvious spike. A scraper taking one page every few minutes blends into human traffic. If the positive class holds only a handful of confirmed attacks, one mislabeled session swings precision dramatically.

Extend the observation window. Collect enough normal traffic to see rare customer conditions, and enough attack traffic to be more than a one-day anecdote.
Replay known attacks. Recorded sequences let you compare policy versions against identical inputs. Keep replay results separate from live ones — a recording can't reproduce every timing and network condition.
Run controlled red-team traffic. Throttle your own automation to the rate a real attacker would use. Use realistic sessions and route order instead of hammering one endpoint.
Measure evidence, not just volume. A low request rate doesn't erase other evidence: failed identity verification, a composite fingerprint reused across accounts, a decoy link followed, an impossible field submitted, machine-like workflow consistency. Rate should be one signal, not the whole detector.

Verify good bots before you allow them

A crawler allowlist reduces false positives only if it verifies identity. Matching Googlebot in a User-Agent creates a bypass, because any client can send the same text — Google's own documentation warns the User-Agent is commonly spoofed and recommends verifying via published IP ranges or reverse DNS with forward confirmation.

Declared identity
    -> verify source or signature
        -> verified:    apply the crawler or partner policy
        -> failed:      treat as impersonation evidence
        -> unavailable: keep unverified, avoid claiming certainty

Don't turn a failed lookup into an automatic block if the source data may be stale. Record why verification failed and choose a route-appropriate fallback — public content can often fail open, sensitive APIs may require a service token.

Shared IP addresses break simple enforcement

An IP address is a network location, not a person. One address may represent an office, university, hotel, mobile carrier, VPN exit, or large customer integration. One abusive client behind that address does not make every other client hostile.

This is exactly why an IP-only block looks accurate in a lab and fails in production: the test environment assigns one address per client, while production puts thousands of unrelated sessions behind one egress point.

Treat IP reputation and request rate as context. Correlate with session evidence, authentication state, route, TLS and browser characteristics, and behavior. When uncertainty remains, challenge the session rather than blocking the address.

Test rate limits from a shared-network simulator: send legitimate traffic from many independent sessions through one source address, then add one abusive session. The desired result is not "the attack stopped." It is "the attack stopped while the other sessions continued."

Move from shadow mode to a canary

Once shadow results meet the route's safety threshold, enforce on a small, stable cohort. Assignment should be sticky by session or account so the same visitor doesn't bounce between control and enforcement on every request.

Shadow everything. Collect proposed actions and business outcomes.
Canary challenges. Challenge a small percentage of ambiguous sessions on one route group.
Enforce high-confidence evidence. Block deterministic abuse, or sessions that repeatedly fail the recovery path.
Expand by route. Increase exposure only after guardrails stay healthy.
Keep a control group. A small untreated cohort keeps conversion and support impact measurable.

Start with an action that can recover. A challenge lets a misclassified human prove the detector wrong and continue. A hard block provides no such information unless the customer opens a ticket.

Define rollback triggers before the canary begins:

Login success falls beyond the agreed tolerance
Checkout completion drops relative to control
Challenge abandonment rises for one browser or device class
Support contacts mention access failures
A major customer or partner appears in the would-block cohort
Latency exceeds the route's budget

If a trigger fires, return the cohort to monitor mode, preserve the evidence, and investigate the contributing rule. A rollback is a successful safety mechanism, not a failed launch.

Measure conversion impact directly

Security metrics cannot tell you whether customers are being harmed. Join the enforcement decision to product outcomes using a privacy-conscious session or account key.

For a trial signup flow: landing-to-signup-start rate, signup-start to account-created rate, challenge pass and abandonment rates, time to complete the form, validation and retry errors, support requests about access.

Compare the canary with its concurrent control group. Do not compare launch week against last month's average if traffic source, promotions, device mix, or seasonality changed at the same time.

And segment the results. An overall conversion rate can stay flat while Safari users, one mobile carrier, or a single enterprise customer's corporate proxy experiences a serious regression.

Set thresholds from cost, not confidence theater

A score of 90 is not automatically safe to block. It is only meaningful if you know what generated it, how that evidence performed on representative traffic, and what a mistake costs on the current route.

Decision	Evidence standard	Typical action
Broad anomaly	Useful for investigation, weak identity	Log
Several independent suspicious signals	Likely automation, meaningful uncertainty	Challenge or rate-limit
Verified trusted automation	Proven operator or partner identity	Allow under explicit policy
Deterministic abuse evidence	Decoy interaction, valid attack signature, repeated failed proof	Block with expiry

Review thresholds after browser releases, mobile app updates, WAF changes, major customer onboarding, and attacker shifts. A benchmark is not a certificate that lasts forever. It is a repeatable process for finding regressions before customers do.

Production readiness checklist

[ ] Known-human traffic covers important browsers, devices, networks, and customers
[ ] Known automation includes trusted crawlers, partners, monitors, and hostile test clients
[ ] Unknown traffic remains unknown rather than forced into a convenient label
[ ] Every verdict records the policy version and contributing evidence
[ ] Precision, recall, and false-positive rate are reported together
[ ] Metrics are broken down by route and customer-impact level
[ ] Shared-IP and corporate-proxy scenarios are included
[ ] Trusted bots are verified rather than matched by User-Agent alone
[ ] Shadow mode connects would-block decisions to product outcomes
[ ] Canary and control cohorts are stable and comparable
[ ] Challenges provide a recovery path for ambiguous traffic
[ ] Hard blocks expire and can be reversed quickly
[ ] Rollback triggers are written before enforcement starts
[ ] Conversion, support, and latency guardrails are monitored

If several answers are no, keep the system in shadow mode. More traffic is not going to make an unmeasured policy safer.

The benchmark is the product

Bot detection accuracy is not one percentage in a sales deck. It is a body of evidence showing what the system catches, what it misses, which real users resemble automation, and what happens when a decision becomes an action.

The safest rollout is deliberately uneventful. Observe first. Label carefully. Verify trusted automation. Challenge uncertainty. Block strong evidence. Measure the customer journey at every step.

That process feels slower than turning on a global block rule. It is much faster than discovering your false-positive rate through lost checkouts and angry customers.

Has anyone here actually run a shadow-mode rollout end to end? Curious what your would-block cohort looked like the first week — ours is always more embarrassing than expected.

Originally published at webdecoy.com.

Related reading:

AI Agent Authentication in 2026: Web Bot Auth, ARD & OAuth

webdecoy — Sun, 13 Sep 2026 15:26:40 +0000

AI agent authentication is not one protocol. It is a stack.

An agent may need to discover a tool, prove which workload is running, authenticate an HTTP request, show that a user delegated authority, and leave enough evidence to reconstruct the action later. ARD, workload identity, Web Bot Auth, and OAuth solve different parts of that sequence. Treating any one of them as the whole answer creates an identity gap.

That distinction got sharper in 2026. Google announced the open Agentic Resource Discovery specification for finding and verifying agentic capabilities, and a separate IETF Internet-Draft on AI agent authentication proposed an architecture for agent credentials, delegated user authority, workload identity, authorization, and audit trails.

Neither replaces OAuth. Neither makes a signed bot trustworthy. Together they show what a serious agent identity architecture has to look like.

Four layers, four questions

Layer	The question it answers	Typical mechanism	What it does not prove
Discovery	Where is the capability, and who published its metadata?	ARD catalogs, registries, trust metadata	That the caller is allowed to invoke it
Workload identity	Which running software workload is this?	WIMSE credentials, SPIFFE IDs and SVIDs, mTLS	Which user delegated authority
Request authentication	Did this HTTP request come from the claimed automated client?	Web Bot Auth, HTTP Message Signatures, mTLS	That the requested action is permitted
Delegated authorization	What may the agent do, for which audience, on whose behalf?	OAuth access tokens, token exchange, transaction tokens	That the agent will behave safely

There is a fifth layer underneath all four: observability. If an operator cannot connect the discovery result, workload credential, user delegation, authorization decision, tool call, and final side effect, the system is not meaningfully auditable.

Why API keys and user-agent strings aren't enough

Traditional web automation has two identity mechanisms: a User-Agent header that names the bot, and an API key that grants access.

The first is a claim anyone can copy. The second is usually both an identity credential and a bearer permission compressed into one long-lived secret. If that key leaks from a log, environment variable, container image, or agent transcript, whoever holds it inherits its authority.

AI agents make this worse, because one action involves several distinct principals:

The agent operator — owns or deploys the software.
The running agent workload — needs its own stable identity and credentials.
The delegating user or system — whose authority the agent may be exercising.
The resource owner — decides what that combination may do.

Collapsing those into one API key destroys the information an authorization engine needs. It also produces an audit record that says only "the key did it" — not which workload ran, who authorized it, what constraints applied, or where authority changed hands.

The July 2026 IETF draft starts from a useful premise: agents are workloads. They should receive cryptographic credentials at runtime, authenticate as themselves, carry delegated authority separately, and preserve both identities through the call chain.

Layer 1: ARD discovers capabilities before invocation

Agentic Resource Discovery addresses a problem that appears before authentication: how does an agent find the right tool, API, MCP server, A2A agent, or nested catalog without relying on a closed directory or hard-coded endpoint?

ARD uses domain-hosted catalogs and federated discovery. A publisher describes resources and attaches trust metadata; a consumer discovers a candidate, verifies the published information, then connects through the resource's native protocol.

The boundary matters. ARD is deliberately pre-invocation infrastructure. It can answer:

Which domain claims this capability?
Where is its endpoint and protocol description?
What trust material did the publisher provide?

It cannot answer:

Is this calling process the agent it claims to be?
Did a user authorize this transaction?
Is the requested action within policy?

Put differently: verified discovery metadata is not a runtime access token. It establishes a trusted starting point; the resource must still authenticate and authorize the caller.

ARD is still evolving — the spec repository described v0.91 as an evolving specification. Version your catalogs and don't treat today's fields as permanently fixed.

Layer 2: workload identity proves which agent is running

After discovery, the caller needs a real identity. The strongest model is not "read a secret from an environment variable." It is "attest this runtime and issue a short-lived credential to the workload that passed attestation."

The agent has a stable identifier; its credentials are temporary and rotated. Issuance can be bound to the cluster, namespace, service account, image, execution environment, or deployment policy.

SPIFFE is the mature example: a workload receives a SPIFFE ID and a short-lived SVID (X.509 or JWT) through the Workload API, then uses that identity for mTLS or application-level auth without shipping a long-lived secret beside the code.

The architectural requirements that matter:

Give the agent a stable workload identifier.
Provision primary credentials at runtime.
Prefer short-lived, automatically rotated credentials.
Keep credentials out of source code, images, prompts, and static config.
Authenticate the agent independently from the user it represents.

This is useful even when no human is involved. A scheduled research agent or autonomous monitoring service still needs its own identity so policy can distinguish it from every other workload.

Layer 3: Web Bot Auth proves an automated HTTP caller

Workload identity fits naturally inside an organization. The open web has a different problem: a site receives an HTTP request from a crawler it does not operate. The request claims a name; the origin needs evidence the claim belongs to the operator.

Web Bot Auth profiles RFC 9421 HTTP Message Signatures so automated clients sign request components and servers verify using public keys associated with the operator.

A valid signature proves:

The request was signed by the holder of the corresponding private key.
Protected components were not changed after signing.
The signature was created within its validity window.
The identity claim ties to an operator-controlled key.

It does not prove:

The agent is benevolent.
The operator has a business relationship with the site.
A user consented to the requested action.
The request should bypass rate limits or bot controls.
The signer is entitled to read, purchase, modify, or delete anything.

That last distinction is the most important one in this whole article: authentication is evidence for an authorization decision, not the decision itself.

A practical note on deployment: most automated traffic is still unsigned. Web Bot Auth upgrades a spoofable user-agent claim into verifiable request identity where it's present, but if you build a policy that assumes signatures, you will be building for a tiny slice of your actual traffic. Design for graceful fallback — operator-published IP ranges and forward-confirmed reverse DNS where available, and treat a bare user-agent string as unproven, not as identity.

Layer 4: OAuth carries authority, including user delegation

Once an agent is authenticated, a resource still needs to know what it may do. Two materially different cases:

The agent acts on its own authority. It obtains a narrowly scoped access token through a machine-to-machine grant, authenticating to the authorization server with its workload credential — not a static, long-lived client secret. The resulting token should be short lived, audience-restricted, minimally scoped, bound to the authenticated client where supported, and revocable without rebuilding the agent.

The agent acts for a user. Now the system must preserve two identities: the agent as the OAuth client, and the delegating principal as the subject. The user grants authority through an interactive flow; the agent separately authenticates with its workload credential.

The resource should be able to answer both:

Which agent exercised the authority?
Which user or system delegated it?

That separation limits the confused-deputy problem, and it prevents an audit record from falsely attributing an automated action directly to a human.

For multi-service workflows, OAuth 2.0 Token Exchange (RFC 8693) lets a security token service swap one token for another with a different audience or reduced authority. Every hop should narrow or preserve authority; no downstream tool should silently gain a broader token than the initiating agent received. Current OAuth security guidance is consolidated in RFC 9700 — follow it rather than reviving weaker historical patterns because the client happens to be autonomous.

An end-to-end flow

Discover. Query an ARD catalog; receive a candidate capability, endpoint, protocol description, trust metadata.
Verify discovery. Validate the publisher before connecting. Discovery results are untrusted input until verified.
Attest the workload. The runtime proves where and how the agent is running; the identity system issues a short-lived credential bound to its stable identifier.
Authenticate the connection or request. mTLS or a WIMSE proof inside a trust domain; Web Bot Auth at a public website boundary. Bind the credential to the actual request or channel.
Obtain authority. An OAuth token for the agent's own authority, or for explicitly delegated user authority — with the two kept distinguishable.
Authorize at the resource. Evaluate agent, subject, audience, scope, action, tenant, risk, and policy. A valid credential is necessary evidence, not an automatic allow.
Downscope each hop. Token exchange gives downstream tools only what they need.
Record and monitor. Logs connect agent identifier, delegating subject, token identifier, policy decision, tool call, and side effect.
Revoke independently. Workload, key, token, user grant, and discovered resource each revocable on their own.

Failure modes this architecture should stop

A valid identity becomes an allowlist bypass. Signing tells you who holds a key. It does not make every request from that identity safe. Keep behavioral controls, rate limits, route policy, and response-level data authorization in place for verified agents.

The user and agent collapse into one subject. If a downstream service sees only the user, it cannot tell whether the user acted directly or an agent acted for them. If it sees only the agent, it cannot enforce user-specific consent. Carry both.

A bearer token gains power as it moves downstream. Don't forward the broad original token through every tool call. Exchange or downscope per audience and action.

Discovery metadata is trusted like an access decision. Catalog content can point an agent at an attacker-controlled endpoint. Verify publisher trust metadata, constrain redirects and egress, apply normal SSRF defenses.

Static secrets are cloned with the agent. If every replica shares one API key, you cannot distinguish instances or revoke one compromised runtime.

The audit trail loses authorization context. Logging only the final API call is not enough. Preserve agent identity, delegating principal, token audience and scope, policy version, decision, and result.

Implementation checklist

Assign every agent workload a stable identifier.
Issue credentials at runtime after workload attestation.
Make credentials short lived and automatically rotated.
Never bake API keys or OAuth client secrets into agent images, code, or prompts.
Keep the agent's identity separate from the user's delegated identity.
Use OAuth scopes, audience restrictions, and expiry as real policy boundaries.
Downscope authority at each tool or service hop.
Verify HTTP signatures over the components that matter, and enforce replay bounds.
Treat discovery results as untrusted until trust metadata is verified.
Do not equate a valid signature with safe behavior or permission.
Log the agent, delegating subject, authorization decision, tool call, and side effect together.
Design independent revocation for workload credentials, signing keys, OAuth grants, and discovered resources.
Support unsigned traffic without silently upgrading a claim into verified identity.

What's stable, what's still emerging

HTTP Message Signatures — standardized, RFC 9421.
OAuth Token Exchange — standardized, RFC 8693. Security BCP is RFC 9700.
SPIFFE — deployed workload identity infrastructure with published specs and implementations.
Web Bot Auth — IETF Internet-Draft built on RFC 9421.
AI agent authentication architecture — an individual Internet-Draft, not an adopted standard. -03 updated July 2026, work in progress.
ARD — open, evolving specification. Expect iteration.

That mix is normal. You do not need to wait for every draft to finalize before removing static secrets, separating agent and user identity, enforcing narrow OAuth audiences, or building complete audit trails. Those are sound security properties regardless of which emerging profile wins adoption.

The bottom line

ARD tells an agent what exists and where to find it.
Workload identity proves which software instance is running.
Web Bot Auth proves who signed an automated web request.
OAuth says what that agent may do and on whose behalf.
Observability proves what happened afterward.

No one layer can safely stand in for the others. The 2026 standards work matters because it stops treating "AI agent" as one magical new principal and starts decomposing it into the identities, credentials, delegation, policy, and evidence that security systems already know how to manage.

If you're building agent-facing APIs right now — are you separating the agent identity from the delegating user, or is it all still one API key?

Originally published at webdecoy.com.

Related reading:

Browser Fingerprinting in 2026: What Still Works, What Doesn't

webdecoy — Sun, 13 Sep 2026 15:24:47 +0000

Browser fingerprinting still works in 2026, but the useful techniques have shifted underneath everyone. Chrome's Privacy Sandbox has frozen or removed half the signals fingerprinting libraries depended on. Firefox and Safari added noise injection and API restrictions. Brave blocks attempts outright. Meanwhile headless browser frameworks have gotten dramatically better at spoofing what remains.

If you're building or maintaining a fingerprinting system, a lot of the advice from even two years ago is obsolete. This is a technical audit of what still produces usable signal, what's been neutralized, and what emerged to replace the losses.

One caveat up front: a fingerprint is not a durable cross-browser identity, and no single fingerprint should be treated as proof that a visitor is human or automated.

The Scoreboard

Each technique rated on two axes — entropy (how much identifying information it produces) and durability (how resistant it is to spoofing and browser mitigation).

Technique	Entropy	Durability	Status in 2026
User-Agent string	Very low	None	Dead. Frozen by Chrome 107+.
navigator.plugins	None	None	Dead. Returns empty array in Chrome.
navigator.platform	Very low	None	Dead. Frozen to generic values.
Canvas fingerprint	Medium	Medium	Degraded but usable. Noise in Firefox/Brave.
WebGL fingerprint	Medium-High	Medium-High	Still strong. Renderer strings remain diverse.
WebGL rendering	Medium	Medium	Works. GPU output is hard to standardize.
AudioContext	Medium	Medium	Works. Hardware timing differences persist.
Font enumeration	Low-Medium	Low	Declining. OS font standardization.
Screen/display props	Low	Low	Minimal entropy. Heavily spoofed.
Client Hints	Low	Low	Reduced by design.
TLS fingerprint (JA4)	High	Very High	Strongest signal. Cannot be spoofed from JS.
HTTP/2 settings	Medium	High	Underutilized. Good connection-level entropy.
TCP/IP stack	Low-Medium	High	Niche but durable.

The trend is clear: JavaScript-accessible signals are eroding. Network-level signals are ascendant. The most durable techniques in 2026 operate below the browser's API surface, where privacy extensions and stealth plugins can't reach them.

What's Dead

User-Agent string. Chrome killed it. Since Chrome 107 in late 2022 the string is frozen — the version number still increments, but OS version is pinned to Windows NT 10.0, platform details are generic, and it no longer differentiates minor versions or OS builds. Firefox and Safari followed. You can distinguish Chrome from Firefox from Safari, and that's about it. For bot detection it's worse than useless, because every automation framework sets whatever string it wants.

navigator.plugins / navigator.mimeTypes. Used to return arrays of installed plugins — a user with Flash 32.0.0.453, Java 8u281 and Chrome PDF Viewer had a distinct, slowly-changing signature. Chrome now returns a fixed generic array. Firefox the same. Remove these from any library that still checks them.

navigator.platform. Frozen to generic values like Win32 regardless of actual architecture. The Client Hints replacement (navigator.userAgentData.platform) is designed to be lower entropy and gates detailed values behind a permission request.

What's Degraded but Usable

Canvas fingerprinting

Draw a complex scene, read back the pixel data, hash it. GPU hardware, driver versions, font rendering and anti-aliasing produce slightly different output across devices.

Per-browser reality in 2026:

Chrome — still consistent, device-specific output. No noise injection. Highest-fidelity target.
Firefox — noise injection since 113 via privacy.resistFingerprinting. Off by default, on in strict privacy mode and private windows. When enabled, the same device produces a different hash on every page load.
Safari — minimal canvas protection. Still stable.
Brave — aggressively randomizes by default. Effectively useless against Brave users.

function getCanvasFingerprint() {
  const canvas = document.createElement('canvas');
  canvas.width = 256;
  canvas.height = 256;
  const ctx = canvas.getContext('2d');

  ctx.textBaseline = 'top';
  ctx.font = '14px Arial';
  ctx.fillStyle = '#f60';
  ctx.fillRect(125, 1, 62, 20);
  ctx.fillStyle = '#069';
  ctx.fillText('Browser fingerprint', 2, 15);
  ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
  ctx.fillText('Browser fingerprint', 4, 17);

  // Geometric shapes for GPU-dependent rendering
  ctx.beginPath();
  ctx.arc(50, 50, 50, 0, Math.PI * 2, true);
  ctx.closePath();
  ctx.fill();

  return canvas.toDataURL();
}

Verdict: still works on roughly 80% of browsers. Expect continued degradation.

Font enumeration

Weakened for three reasons: OS standardization (Windows 11, recent macOS and modern Linux distros ship increasingly similar default sets), web font dominance (most modern sites never trigger system font rendering), and browser restrictions (privacy.resistFingerprinting returns a fixed list). Still distinguishes Windows from macOS from Linux. The days of font lists as a high-entropy identifier are over.

Screen and display properties

A 1920×1080 display at 1× describes tens of millions of devices. Trivially spoofed — Playwright and Puppeteer set arbitrary viewport sizes in one line. Include in a composite, don't rely on it.

What Still Works

WebGL — the quiet workhorse

Two levels. Parameter enumeration exposes hardware and driver information:

function getWebGLFingerprint() {
  const canvas = document.createElement('canvas');
  const gl = canvas.getContext('webgl');
  if (!gl) return null;

  const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');

  return {
    vendor: gl.getParameter(gl.VENDOR),
    renderer: gl.getParameter(gl.RENDERER),
    unmaskedVendor: debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL)
      : null,
    unmaskedRenderer: debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL)
      : null,
    maxTextureSize: gl.getParameter(gl.MAX_TEXTURE_SIZE),
    maxViewportDims: gl.getParameter(gl.MAX_VIEWPORT_DIMS),
    extensions: gl.getSupportedExtensions(),
    shadingLanguageVersion: gl.getParameter(gl.SHADING_LANGUAGE_VERSION),
  };
}

The unmasked renderer string alone carries substantial entropy — ANGLE (NVIDIA GeForce RTX 4070 Ti Direct3D11 vs_5_0 ps_5_0) identifies a specific GPU model. Level 2 is render output: drawing a 3D scene and reading back pixels, with higher variability than canvas because 3D pipelines differ more across GPU architectures.

Why it's durable: browser vendors have been reluctant to restrict WebGL because doing so breaks legitimate applications — games, data visualizations, 3D product viewers, mapping. Injecting noise would break these visibly.

For bot detection specifically, WebGL is gold. Headless Chrome in a cloud VM reports the VM's virtual GPU — typically Google SwiftShader or llvmpipe — instantly distinguishable from any real user GPU. Even BaaS platforms that spoof this value struggle to replicate the full constellation of parameters a real GPU produces.

AudioContext

Exploits hardware-dependent differences in audio signal processing. Route an OscillatorNode through a DynamicsCompressorNode, read the output, and you get floating-point sample values that vary with the audio hardware and driver stack:

function getAudioFingerprint() {
  return new Promise((resolve) => {
    const context = new OfflineAudioContext(1, 44100, 44100);
    const oscillator = context.createOscillator();
    oscillator.type = 'triangle';
    oscillator.frequency.setValueAtTime(10000, context.currentTime);

    const compressor = context.createDynamicsCompressor();
    compressor.threshold.setValueAtTime(-50, context.currentTime);
    compressor.knee.setValueAtTime(40, context.currentTime);
    compressor.ratio.setValueAtTime(12, context.currentTime);
    compressor.attack.setValueAtTime(0, context.currentTime);
    compressor.release.setValueAtTime(0.25, context.currentTime);

    oscillator.connect(compressor);
    compressor.connect(context.destination);
    oscillator.start(0);

    context.startRendering().then((buffer) => {
      const data = buffer.getChannelData(0);
      let sum = 0;
      for (let i = 4500; i < 5000; i++) sum += Math.abs(data[i]);
      resolve(sum);
    });
  });
}

Lower entropy than WebGL, but it's an independent signal that's hard to spoof because it depends on the actual audio processing pipeline rather than a JavaScript property. Headless browsers often have no audio stack at all, or a software implementation producing output that matches no real desktop configuration.

TLS fingerprinting (JA4)

The biggest shift in fingerprinting since canvas was discovered. TLS fingerprinting doesn't operate in JavaScript at all. It analyzes the ClientHello sent during the HTTPS handshake — before page content loads, before JavaScript executes, before any browser API can be manipulated.

The ClientHello contains supported cipher suites in preference order, TLS extensions and their order, supported groups, signature algorithms, and ALPN protocols. JA4 hashes these into a fingerprint identifying the TLS stack implementation. Critically: you cannot change your JA4 fingerprint from JavaScript. It's determined by the TLS library compiled into the client.

Which means:

A Playwright bot claiming Chrome 126 but running an older Chromium has a JA4 that doesn't match real Chrome 126.
A Python requests session spoofing a Chrome User-Agent has a JA4 matching urllib3, not Chrome.
A BaaS platform running headless Chrome in the cloud has a JA4 matching their specific Chromium build — often months behind stable.

The cost: it requires server-side or proxy-level access to the raw handshake. You can't do it from JavaScript. But if you control the server, or use a CDN that exposes TLS metadata (Cloudflare exposes JA3 and JA4 in firewall rules), it's the most powerful identification signal available.

HTTP/2 settings

When a client opens an HTTP/2 connection it sends a SETTINGS frame — initial window size, max concurrent streams, header table size, enabled push. Different implementations choose different defaults, and like TLS it's determined by the client implementation rather than configurable from JavaScript. Underutilized, and worth adding.

The Anti-Fingerprinting Landscape

Chrome (Privacy Sandbox). Surgical rather than blunt: reduce entropy from each API rather than blocking it. Frozen UA, reduced Client Hints, deprecated plugins. WebGL renderer info stays exposed because removing it would break too many sites. The goal is to make fingerprinting less unique, not impossible.

Firefox. The most granular controls. privacy.resistFingerprinting (off by default, on in Tor Browser) adds canvas noise, restricts font enumeration, normalizes screen dimensions, limits timer precision. Standard Firefox blocks known fingerprinting scripts by domain without modifying API output.

Safari. Pragmatic — restricts some vectors (limiting document.fonts, reducing timer precision) but focuses mainly on cookie and storage partitioning.

Brave. The most aggressive. Randomizes canvas, blocks WebGL renderer info, adds AudioContext noise, limits fonts. The goal is to make fingerprinting actively unreliable, not just lower entropy.

On the other side:

Puppeteer Extra Stealth / Playwright stealth patches patch navigator.webdriver, spoof plugin arrays, override Chrome runtime properties. Increasingly they spoof WEBGL_debug_renderer_info to report a realistic GPU instead of SwiftShader. None of it affects TLS or network-level signals.

Browser-as-a-Service (Browserbase, Hyperbrowser) run real Chromium in the cloud, producing genuine fingerprints at the JavaScript level. Their weakness is TLS: the Chromium version they run often lags stable, creating a detectable mismatch between claimed UA version and actual JA4.

Anti-detect browsers (Multilogin, GoLogin, Dolphin Anty) are the hardest to detect, because they use modified real browser engines rather than automation frameworks. Detection requires ensemble methods — no single signal catches them.

Building a System in 2026

Layer 1 — network fingerprints (server-side). Collect at the proxy or load balancer:

TLS ClientHello   → JA4 hash
HTTP/2 SETTINGS   → settings fingerprint
TCP/IP characteristics → OS fingerprint

This is the foundation because it cannot be manipulated from the client. It tells you what the client actually is, regardless of what it claims.

Layer 2 — hardware fingerprints (JavaScript). WebGL renderer + parameters, AudioContext output, canvas rendering. Harder to spoof than software properties because they depend on physical components and low-level driver behavior.

Layer 3 — behavioral fingerprints (JavaScript). Mouse movement patterns, scroll behavior, keystroke timing, touch events, interaction timing. Not traditional fingerprints, but the strongest bot/human discrimination available — a bot can spoof every static property perfectly and still fail here, because generating convincing human interaction at scale is an unsolved problem.

Cross-signal coherence is the whole game

No single technique is sufficient. The value is in the combination, and specifically in coherence. A client claiming Chrome 126 on Windows 11 should have:

a JA4 hash matching Chrome 126's TLS stack
a WebGL renderer matching a real Windows GPU (not SwiftShader)
AudioContext output consistent with Windows audio drivers
HTTP/2 settings matching Chrome's defaults
mouse movement with human-like jitter and velocity curves

If any one of these contradicts the others, something is being spoofed. A real browser is internally consistent. A spoofed browser almost never is, because each spoofing mechanism operates independently and rarely accounts for cross-signal dependencies.

The privacy tension

This has been written from a security perspective, deliberately. Fingerprinting for bot detection and fingerprinting for cross-site tracking are the same technology applied to different ends.

The privacy concerns are real — fingerprinting has been used to track users across sites without consent, circumventing cookie controls. The browser restrictions above are responses to documented abuse.

The security case is also real. Without fingerprinting, bots are nearly undetectable. CAPTCHAs fail. Rate limiting fails. Behavioral analysis alone has a high false-positive rate. The same signals that let an ad network track you across the web are the signals that let a payment processor catch a credential-stuffing attack.

This is a genuine tension, not a false dichotomy. The current trajectory — browsers restricting JavaScript-accessible signals while network-level fingerprinting becomes the primary detection vector — is a reasonable compromise. It makes cross-site tracking harder (you can't read TLS fingerprints from JavaScript) while preserving the ability of server operators to identify suspicious clients hitting their own infrastructure.

Where this lands in three years is anyone's guess. For now: the toolkit is smaller than it was, the signals that remain are more durable than the ones that were lost, and the arms race shows no sign of slowing.

Anyone here still getting useful entropy out of canvas, or have you moved everything to the network layer?

Originally published at webdecoy.com.

Related reading:

Why CAPTCHAs Are Dead (And What Replaces Them in 2026)

webdecoy — Sun, 13 Sep 2026 15:23:18 +0000

There's a pattern you can watch happen on any reasonably popular site once a quarter. A team ships a new sign-up flow. They add reCAPTCHA. The bots keep coming. They upgrade to reCAPTCHA v3 invisible. The bots keep coming. They switch to hCaptcha for privacy reasons. The bots keep coming. They try Cloudflare Turnstile. The bots keep coming. Somewhere around month four, somebody writes a Slack message that reads "what if we just made it harder for real users?"

This is not a story about a particular CAPTCHA being broken. It's a story about a category that has lost its asymmetric advantage. The defining property of an effective CAPTCHA — that it costs more for an attacker to solve than for a legitimate user — has been priced into oblivion. Solvers cost a fraction of a cent. Vision models do the rest for free. Real users churn.

What a CAPTCHA Was Supposed to Do

A CAPTCHA, in the 2003 sense Luis von Ahn coined, is a "Completely Automated Public Turing test to tell Computers and Humans Apart." The asymmetry depends on three properties:

The challenge is hard for current machine learning.
The challenge is easy for typical humans.
The cost to generate the challenge is much lower than the cost to solve it.

All three were approximately true for distorted-text CAPTCHAs in 2003. None are true for any visual CAPTCHA in 2026.

The death of (1) is what people mean when they say CAPTCHAs are broken. The death of (2) is what people mean when they say CAPTCHAs are user-hostile. The death of (3) is the boring one that actually matters, because it's the one that breaks the economics for defenders.

The Solver Economy

Here's the part that doesn't get talked about enough. CAPTCHAs are not defeated primarily by AI. They are defeated by markets that price AI at scale.

2Captcha, CapSolver, AntiCaptcha and a long tail of grey-market resellers operate as commodity APIs. You send a challenge image or sitekey, you get back a token, you pay per solve. Pricing as of mid-2026, in round numbers:

Challenge type	Price per 1,000 solves	Median solve time
reCAPTCHA v2 (image grids)	$1.50 – $3.00	8 – 15 s
reCAPTCHA v3 (invisible)	$1.50 – $2.50	1 – 3 s
hCaptcha	$1.00 – $2.50	8 – 12 s
Cloudflare Turnstile	$1.50 – $3.00	4 – 10 s
Arkose Labs FunCaptcha	$3.00 – $7.00	15 – 30 s
Audio CAPTCHA	$2.00 – $4.00	15 – 25 s

Translate that into attacker math. A credential stuffing operator running 100,000 attempts a day at a 0.3% hit rate, valuing a validated account at $20, makes $6,000/day in revenue against $300 in solver cost.

CAPTCHA is a 5% line item in their cost of goods sold. It is not a deterrent. It is a tax an attacker pays without complaint while extracting value from your system.

The Autopsy, By Variant

reCAPTCHA v2 image grids. Solved end-to-end by GPT-4-class vision models in 2023, and by smaller, cheaper fine-tuned models since. Solve rate against modern grids is consistently above 90% — higher than the average human solve rate against the same puzzles. The audio accessibility fallback is solved by Whisper with similar reliability.

reCAPTCHA v3 invisible scoring. Three concrete problems. The score is gameable — operators run checkers in real Chrome with warm Google session cookies on seasoned residential profiles, scoring 0.7–0.9. The score routinely flags legitimate users on Linux, Firefox, hardened browsers, or VPNs, often below 0.3. And every page shipping v3 is also shipping a Google tracking beacon to every visitor, which is a live regulatory issue under GDPR and US state privacy laws.

hCaptcha. Functionally similar to v2 with a privacy-first marketing posture. Solved by the same providers at similar prices with similar success rates.

Cloudflare Turnstile. The most interesting of the modern lot, because it skips the puzzle and scores on browser environment signals. When it works, it works invisibly. When it fails, it fails opaquely. Two failure modes we see in the wild: it passes Browser-as-a-Service traffic (Browserbase, Hyperbrowser) with high frequency, because those platforms serve real Chromium on real residential IPs; and it blocks a long tail of legitimate users on hardened privacy browsers (Brave strict shields, LibreWolf, Tor) at rates that produce real conversion impact. Right shape for the future, closed implementation tied to one edge.

Arkose FunCaptcha. Long the holdout because of the 3D-rotation requirement. By 2025, depth-aware vision models trained on synthetic 3D renders started solving these reliably.

The Shape of the Replacement

Six independently useful components. Most production stacks combine three or four. None are silver bullets — the point is that combining cheap signals raises attacker cost faster than any single signal does.

1. Behavioral biometrics

Real humans interact with a page in characteristically messy ways. Continuous mouse trajectories with micro-tremors at 3–25 Hz from physiological hand movement. Hover, overshoot, correct. Inter-keystroke intervals that follow a log-normal distribution with dwell-time variance, rollover on common letter pairs, and real Shannon entropy.

Automated browsers can replay recorded human traces — that's the obvious counter. The current state of play is that replayed traces look right at first order (mouse moves, things get clicked) but break under second-order analysis: the trace doesn't match the page layout the model is currently looking at, keystroke entropy is uniform across the corpus, the timing distribution has a different tail.

Signals worth capturing, in rough order of cheapness:

Mouse trajectory entropy and curvature
Inter-event timing distributions (keystroke, mouse move, scroll)
Field-fill order and time-on-form
Pointer move events between page load and first click
Touch vs mouse vs synthetic event detection (event.isTrusted)
Scroll velocity profiles
Focus and blur event sequences

2. Proof-of-work

The oldest idea in the deck, and one of the most underused. Adam Back's 1997 Hashcash proposal is the original spec: before accepting a request, require the client to find a partial SHA-256 collision against a server-issued nonce. Tunable difficulty, no interactivity, invisible to the user.

The asymmetry is straightforward. A 200 ms PoW solve on a real phone is below the threshold of perception. The same 200 ms across 10,000 parallel sessions is 33 minutes of single-threaded compute, or a real cloud bill in parallel. Worth nothing against someone targeting one account. Crippling for mass-volume operators.

async function solve(nonce, difficultyBits) {
  const target = (1n << (256n - BigInt(difficultyBits)))
  for (let counter = 0; ; counter++) {
    const buf = new TextEncoder().encode(nonce + counter)
    const digest = await crypto.subtle.digest('SHA-256', buf)
    const hashInt = BigInt('0x' + [...new Uint8Array(digest)]
      .map(b => b.toString(16).padStart(2, '0')).join(''))
    if (hashInt < target) return counter
  }
}

Difficulty calibration is the only interesting tuning question. Too low and it doesn't bite; too high and slow phones see a noticeable delay. We land around 20 to 22 bits, roughly 100–400 ms on a five-year-old Android and well under a second on anything modern.

3. Privacy Pass and Private Access Tokens

The most promising long-term direction. A trusted attester (Apple, Google, your own service) verifies the client is a real device, then issues a blind cryptographic token the client redeems at your service. You learn the request came from an attested human-controlled device. You learn nothing else. The attester learns nothing about which sites the user visits.

The catch in 2026 is coverage: well-supported on Apple platforms, partially on Cloudflare's network, effectively unsupported elsewhere. PAT is part of the stack, not the whole stack.

4. TLS and HTTP/2 fingerprinting

The layer below the browser. Every HTTP client has a TLS ClientHello with a specific cipher suite ordering, extension list, and supported groups; every HTTP/2 client has a settings frame with specific values and pseudo-header order. These vary by client library and stack version, and are very hard to spoof from a script without driving an actual browser.

A POST that arrives with User-Agent: Mozilla/5.0 ... Chrome/124 and a JA4 fingerprint that says "Go HTTP client" is automated. Full stop. No human Chrome ever produced that combination.

5. Honeypot fields and decoy endpoints

The oldest cheap trick still works for a useful slice of the threat. Two important caveats, though. Classic CSS-hidden honeypots (display: none) are increasingly invisible to vision-based agents that read the rendered page rather than the HTML — the agent never sees the field, so it never fills it. And accessibility tooling sometimes interacts with hidden fields, producing false positives for screen-reader users.

The patterns that hold up in 2026 use DOM-tree placement (a field after the submit button), naming conventions that look real but never appear in your actual schema, or Shadow DOM containment that mainstream automation libraries don't traverse.

6. Server-side risk scoring

The layer that ties everything together. Every signal above produces a feature; score requests across all of them and decide what to allow, what to challenge with a step-up, and what to silently drop.

The thing to avoid is a single hardcoded "bot or not" threshold. The thing to embrace is a graduated response that maps risk score to action.

How They Combine

A realistic 2026 stack on a high-value form:

1. Edge
   - TLS / HTTP/2 fingerprint logged
   - Datacenter ASN gets harder PoW difficulty
   - Known-bad fingerprint clusters hard-blocked

2. Page load
   - Behavioral telemetry script attached
   - Keystroke, mouse, scroll, focus events captured
   - Honeypot fields rendered into the DOM
   - PoW challenge issued at low difficulty

3. Submit
   - Form + signed telemetry token + PoW result posted
   - Honeypot fields verified empty
   - Server computes risk score across all signals

4. Decision
   - Score below A: accept silently
   - Score in band: step up (harder PoW or soft MFA)
   - Score above B: drop with response symmetry
                    (identical status, body shape, timing)

What you do not do, in any layer, is show the user a visual challenge.

An open-source implementation

FCaptcha is our open-source implementation of this stack (currently v1.37). We started it because every team that came to us asking how to replace reCAPTCHA wanted the same three things: an open-source library, a self-hostable server, and a scoring algorithm they could read and audit.

What's in the box: behavioral telemetry across mouse/keystroke/scroll/focus/environment categories; keystroke cadence biometrics (dwell variance, log-normal fit, Shannon entropy, autocorrelation, rollover detection); SHA-256 proof-of-work with server-side timing validation; vision-AI detection (zero-movement click bypass, screenshot-to-API patterns, synthetic event filtering); automation detection for Playwright, Puppeteer, Selenium, Stagehand and BaaS; servers in Go, Python and Node with identical scoring semantics; no cookies, no cross-site tracking, no PII.

1. Run the server.

docker run -d -p 3000:3000 \
  -e FCAPTCHA_SECRET=your-secret \
  ghcr.io/webdecoy/fcaptcha

That gives you POST /api/* for verification and GET /fcaptcha.js for the widget. Two deployment notes worth knowing up front: the server fails closed without FCAPTCHA_SECRET (the public dev key is in the repo, so anything signed with it can be minted by anyone), and running more than one replica requires REDIS_URL so single-use tokens are single-use across the whole deployment rather than per process.

2. Add the widget. Invisible mode auto-protects forms with no UI:

<script src="https://your-server.com/fcaptcha.js"></script>
<script>
  FCaptcha.configure({ serverUrl: 'https://your-server.com' })
  FCaptcha.invisible({ siteKey: 'your-site-key', autoScore: true })
</script>

3. Verify on the backend. A plain HTTP POST:

import requests

resp = requests.post(
    'https://your-server.com/api/token/verify',
    json={'token': token_from_form, 'secret': FCAPTCHA_SECRET},
).json()

# In FCaptcha, a LOW score means the request looks human.
if resp['valid'] and resp['score'] < 0.5:
    return accept()
elif resp['valid'] and resp['score'] < 0.8:
    return require_step_up()
else:
    return reject()

What we don't claim

This does not "solve bot detection." Nothing does. It raises the cost of mass-volume automated abuse to the point where commodity attackers move on and bespoke attackers leave signals you can act on. Targeted attackers with patient capital and real Chromium on real residential bandwidth will still get through. That's true of every defense in this category.

Behavioral telemetry can be replayed. Open datasets of recorded human interactions exist for the explicit purpose of training automation to look human. The signals that hold up are second-order ones — does the trace match the current page, does the keystroke entropy match the current user's history. Harder to replay convincingly. Not impossible.

Proof-of-work is not free for clients. A 200 ms hit is small but not zero. On a four-year-old phone with thermal throttling it can stretch to 800 ms. Tuning difficulty by device class means low-trust devices get more friction, which is its own UX cost.

No CAPTCHA replacement is GDPR-trivial. Behavioral telemetry is biometric data under EU law, and the scoring is opaque enough that "right to explanation" obligations require thought. You will still need a privacy review.

A migration path

If you're on reCAPTCHA today, the path that has worked for most teams:

Week 1 — Ship behavioral telemetry alongside the existing CAPTCHA. Log scores, don't gate on them. Build a dashboard of score distributions for known-good and known-bad sessions.
Weeks 2–3 — Calibrate thresholds against the labeled dashboard. Find the band that cleanly separates confirmed humans from confirmed bots, and the gray middle that needs step-up.
Week 4 — Move the CAPTCHA into step-up-only mode. Default flow is invisible; only the gray band sees a challenge.
Weeks 5–6 — Replace the CAPTCHA step-up with a higher-difficulty PoW step-up, or soft MFA for accounts that have it.
Week 7 — Remove the CAPTCHA SDK entirely. Audit the privacy footprint reduction. Tell your conversions team.

Most teams measure a conversion lift on legitimate sign-up traffic at step 3 — the moment the CAPTCHA stops gating clean sessions — and a sharper drop in confirmed bot success by step 5.

Where this goes next

Agent-driven traffic from real Chromiums. The Browser-as-a-Service ecosystem is industrializing exactly the population that defeats most behavioral defenses. Cross-session correlation, JA4-plus-device-fingerprint binding, and challenge interaction physics beyond first-order signals all matter more in this world.

Standardized client attestation. PAT is the early form. WebAuthn-anchored device attestation, TPM-backed remote attestation, and App Attest are converging toward a future where "is this a real device controlled by a real user" is a cryptographic question rather than an inferential one. Uneven and partial today. Worth tracking.

The CAPTCHA is dead. What replaces it is not one thing — it's a stack of cheap, layered signals producing a real-time score, paired with a graduated response that mostly does nothing visible to the user. That's the bar. Everything below it is theater.

Either way: please stop making people click on traffic lights.

What are you running on your sign-up flow right now? Curious how many teams have actually managed to rip reCAPTCHA out versus just layering on top of it.

Originally published at webdecoy.com.

Related reading:

Next.js Bot Detection: Block AI Crawlers at the Edge

webdecoy — Sun, 13 Sep 2026 14:14:57 +0000

Your Vercel usage graph is climbing and your logs are full of names you did not invite: GPTBot, ClaudeBot, PerplexityBot, Bytespider. They hammer your App Router pages and quietly run up your bandwidth and compute bill.

The reflex is a ten-line user-agent block in middleware.ts. After you ship it the graph looks calmer for a day. Then it climbs again.

The ten-line block is not wrong. It is just the first of three layers, and on its own it catches only the crawlers honest enough to tell you who they are. This is a working guide to all three in a normal Next.js project: an edge gate on every request, honeypot routes that catch the bots that lie, and an origin fingerprint check for the signal the edge genuinely cannot see.

We will also be honest about that last part, because most tutorials are not.

The naive block, and exactly why it fails

Almost every Next.js bot-blocking guide ends here:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

const BLOCKED = /GPTBot|ClaudeBot|PerplexityBot|Bytespider|CCBot|Google-Extended|Meta-ExternalAgent|Amazonbot/i

export function middleware(req: NextRequest) {
  const ua = req.headers.get('user-agent') || ''
  if (BLOCKED.test(ua)) {
    return new NextResponse('Forbidden', { status: 403 })
  }
  return NextResponse.next()
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

This works against a crawler that announces itself. GPTBot sends a user agent that says GPTBot, you match it, you return 403. Done.

The problem is that a user agent is a string the client chooses. Nothing forces a scraper to keep telling the truth, and the moment blocking becomes common, the well-funded scrapers stop. Perplexity was reported through 2025 to fetch pages with a generic Chrome user agent and rotating addresses after its declared bot was blocked. A scraper running headless Chrome or a plain HTTP client can set any user-agent header it likes in one line. Your regex never sees them.

So the honest framing: a user-agent block is a politeness filter. It removes the crawlers that respect your wishes, which is real and worth doing, and it does nothing to the ones that do not. The same logic applies to robots.txt, which is a request rather than a rule.

Layer one: a real edge middleware

Keep the user-agent gate, but stop treating it as the whole defense. A useful middleware does three jobs: cheaply block the honest crawlers, rate limit everyone else so a single client cannot flood you, and hand a signal to your origin so the deeper check knows where to look.

Where middleware lives, and what `matcher` does

middleware.ts sits at the root of your project, or inside src/. It runs on the Edge Runtime by default, before your routes and before cached output — exactly why it is the right place for a first gate. The request is stopped before it costs you a function invocation or a database hit.

The matcher is your most important performance setting. Without it, middleware runs on every asset, including static files Next.js already serves for free:

export const config = {
  matcher: [
    // run on everything except Next internals and static files
    '/((?!_next/static|_next/image|favicon.ico|robots.txt|sitemap.xml).*)',
  ],
}

Block, rate limit, or rewrite

NextResponse gives you three moves inside middleware:

return new NextResponse('Forbidden', { status: 403 })          // block
return new NextResponse('Too Many Requests', { status: 429 })  // rate limit
return NextResponse.rewrite(new URL('/tarpit', req.url))       // send to a decoy

You can hand-roll the gate from here, but it adds up fast: a regex of declared crawlers to maintain, plus a shared rate-limit store — an in-process counter (a plain Map) will not hold when edge invocations do not share memory, so you reach for Upstash Redis or Vercel KV.

That is ongoing work, and it is the work @webdecoy/nextjs exists to remove:

npm install @webdecoy/nextjs

// middleware.ts
import { withWebDecoy } from '@webdecoy/nextjs'
import { rateLimit } from '@webdecoy/node'

export default withWebDecoy({
  apiKey: process.env.WEBDECOY_API_KEY!,
  // Built-in rules engine: no separate counter store to stand up.
  rules: [rateLimit({ max: 100, window: 60 })], // 100 requests per 60s
  // Skip work on paths that never need protection.
  skipPaths: ['/_next', '/favicon.ico', '/robots.txt'],
})

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

On every matched request this runs local analysis, applies your rules, and returns the right response on its own: a tripped rateLimit returns 429 with a Retry-After header, a deny rule returns 403, and an allowed request continues with an x-webdecoy-decision header so your routes can read the verdict downstream. onBlocked and onError let you override, and onError fails open by default, so a hiccup in detection never locks out real users.

This is a real improvement over the ten-line version. But notice what every signal so far has in common. User agent, headers, address, and request rate are all things the client controls or can rotate. To catch a bot that lies about all of them, you need a signal it does not get to set: its own TLS handshake.

The honest constraint nobody mentions

Here is the part most Next.js guides skip, and it holds whether you hand-roll the gate or use a package: you cannot compute a TLS fingerprint inside middleware.ts.

A JA3 or JA4 fingerprint is built from the raw ClientHello of the TLS handshake — the cipher suites, the extensions and their order, the supported groups, the way the client negotiates the connection. These are extremely hard to fake because they come from the client's TLS stack rather than from a header.

The catch on a platform like Vercel is that TLS terminates at the edge network before your middleware runs. By the time your code executes, the handshake is over and the ClientHello bytes are gone. The Edge Runtime has no socket access and no node:tls, so there is nothing to read. Recent Next.js versions let you move middleware to the Node.js runtime, which is useful for other reasons, but it still does not hand you the original handshake.

This is not a flaw in Next.js. It is just where the layers sit. Put the fingerprint check where the handshake is visible:

Your own origin, when you self-host Next.js behind your own TLS termination (next start behind nginx or Caddy), where the proxy reads the handshake and forwards it as headers.
A detection service that captures those handshake signals for you and returns a verdict your route handler can act on.

So the architecture becomes: gate cheaply at the edge, trap the liars with honeypots, run the fingerprint check at the origin where the signal lives.

Layer two: honeypot routes in the App Router

A honeypot exploits a simple asymmetry: a real visitor never touches it, so any hit is suspicious by definition. The classic version is a hidden form field. For a Next.js crawler problem, a honeypot route is a better fit, because crawlers follow links and probe paths humans never click.

First, plant a decoy link that humans cannot see but a link-following scraper will. Put it in your layout, and disallow the path in robots.txt so honest crawlers skip it — anything that fetches it has both ignored robots.txt and followed an invisible link, which is a strong signal:

// app/layout.tsx (excerpt)
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        {/* Invisible to humans, irresistible to link-scraping bots. */}
        <a href="/api/trap" aria-hidden="true" tabIndex={-1}
           style={{ position: 'absolute', left: '-9999px' }}>
          Account archive
        </a>
      </body>
    </html>
  )
}

Then the trap itself — a route handler that records the hit and responds blandly so the bot does not learn it was caught:

// app/api/trap/route.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { flagClient } from '@/lib/threat'

export async function GET(req: NextRequest) {
  const ip = req.headers.get('x-forwarded-for')?.split(',')[0] ?? 'unknown'
  const ua = req.headers.get('user-agent') || ''

  // Record the hit. Anything reaching this route is presumed automated.
  await flagClient({ ip, ua, reason: 'honeypot:trap', score: 80 })

  // Respond like a boring empty resource. Do not reveal the trap.
  return new NextResponse(null, { status: 204 })
}

Now your middleware reads that stored flag and acts on it before serving real content. Rewrite flagged traffic to a tarpit instead of your actual route, which keeps the URL stable so the bot does not notice:

// inside middleware(), after the rate-limit check
import { isFlagged } from '@/lib/threat'

if (await isFlagged(ip)) {
  return NextResponse.rewrite(new URL('/tarpit', req.url))
}

The same pattern extends to fake API endpoints. A path like /api/v1/users/export that your real app never calls, but a scraper probing for data will, becomes a high-confidence trap.

Honeypots are powerful because they need no fingerprint and no machine learning. They exploit the gap between how a human and a script move through a site. But a careful scraper that only fetches linked, allowed pages at a human pace will avoid them. That is the gap layer three closes.

Layer three: origin fingerprinting

For the bot that spoofs its user agent, rotates its address, paces itself, and avoids your traps, you need the one thing it cannot rewrite: its TLS handshake. As covered above, that check has to run at the origin, in a Node runtime, not in edge middleware.

Next.js route handlers default to the Node.js runtime, which makes them the right home. The core SDK runs a two-tier check: a fast local pass on your server (suspicious headers, datacenter IP ranges, known bot user agents, missing client hints), and a deeper pass using JA3/JA4 fingerprinting to flag the case where a request claims to be Chrome but handshakes like curl.

npm install @webdecoy/node

// app/api/checkout/route.ts
export const runtime = 'nodejs' // the Edge Runtime cannot see the handshake

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { WebDecoy } from '@webdecoy/node'

const webdecoy = new WebDecoy({
  apiKey: process.env.WEBDECOY_API_KEY!,
  enableTLSFingerprinting: true,
  threatScoreThreshold: 70, // block at a threat score of 70 or higher
})

export async function POST(req: NextRequest) {
  const result = await webdecoy.protect({
    method: req.method,
    path: new URL(req.url).pathname,
    ip: req.headers.get('x-forwarded-for')?.split(',')[0] ?? '0.0.0.0',
    user_agent: req.headers.get('user-agent') ?? '',
    headers: Object.fromEntries(req.headers),
    timestamp: Date.now(),
  })

  if (!result.allowed) {
    // result.detection carries decision, confidence (0 to 100), and bot_type.
    return NextResponse.json({ error: 'Request blocked' }, { status: 403 })
  }

  return NextResponse.json({ ok: true })
}

One honest caveat about where each tier can run. The local pass works anywhere, including a route handler on Vercel, because it only reads headers and the address. The JA3/JA4 pass needs the client's actual handshake, and your function only sees that when it has socket access. Self-hosting behind nginx or Caddy, you forward the handshake details as headers and the SDK gets the full fingerprint. On Vercel's managed edge, you lean on the local signals and put the deep fingerprint check on a self-hosted origin or proxy.

Still on the Pages Router? The same package gives you a handler wrapper:

// pages/api/checkout.ts
import { withBotProtection } from '@webdecoy/nextjs'
import type { NextApiRequest, NextApiResponse } from 'next'

async function handler(req: NextApiRequest, res: NextApiResponse) {
  res.json({ ok: true }) // req.webdecoy holds the detection result
}

export default withBotProtection(handler, {
  apiKey: process.env.WEBDECOY_API_KEY!,
  blockThreshold: 70,
})

One decision from three signals

The point of three layers is that they cover each other's blind spots. Combine them into a single verdict rather than three disconnected checks:

// app/lib/decide.ts
type Signals = {
  edgeScreened: boolean   // passed the edge user-agent and rate gate
  honeypotHit: boolean    // touched a trap at any point
  threatScore: number     // 0 to 100, from result.detection.confidence
}

export function decide(s: Signals): 'allow' | 'challenge' | 'block' {
  if (s.honeypotHit) return 'block'           // touched a trap: automated by definition
  if (s.threatScore >= 70) return 'block'     // handshake or local signals say automation
  if (s.threatScore >= 40) return 'challenge' // suspicious, verify before trusting
  return 'allow'
}

A naive HTTP scraper trips the edge gate. A link-following scraper that lies about its user agent trips a honeypot. A polished headless browser that avoids the traps trips the fingerprint. To get past all three, a bot has to be honest, careful, and use a real browser TLS stack at the same time — a much smaller and more expensive population than the flood you started with.

Vercel BotID versus a self-hosted stack

If you are on Vercel you have probably seen BotID, the invisible bot-detection product powered by Kasada. It is genuinely good, and worth knowing where it fits.

BotID is a managed black box. You enable it on the routes you want protected and it makes a verdict at the edge, with no signals to inspect and no logic to tune. That is the appeal and the limitation: strong detection with almost no code, in exchange for visibility into why a request was flagged, portability off Vercel, and the ability to combine the verdict with your own honeypots and scoring. It is also a paid feature once you scale.

The self-hosted stack in this guide is the opposite trade: more code and more moving parts, in return for portability to any host, transparency about every signal, and thresholds that are yours to tune. They are not mutually exclusive — some teams run BotID on checkout and login for the managed guarantee, and run the edge gate plus honeypots plus origin fingerprinting everywhere else for coverage and insight.

Production checklist

Scope the matcher. Never run middleware on _next/static, images, or other assets. Wasted compute, and it can break caching.
Do not hard-block on user agent alone. Treat it as the cheap first pass, then escalate. A single spoofed header should not be enough to ban a visitor.
Allow the good bots on purpose. Verify Googlebot and Bingbot by reverse DNS rather than trusting the user-agent string, and decide deliberately which AI crawlers you keep. Some AI search engines send referral traffic worth having.
Watch your false positive rate. Log every block and challenge with the reason, and review the challenge bucket. If real users land there, loosen the thresholds in decide().
Fail open, not closed. If the fingerprint service is briefly unreachable, decide whether a timeout should allow or challenge. For most sites, allowing on timeout beats locking out real customers.
Measure the bill. The whole point was bandwidth and compute. Watch the usage graph for a week after launch so you can prove the layers are paying for themselves.

Wrapping up

The shape that works in Next.js is layered: a cheap edge gate that screens and rate limits, honeypot routes that catch the bots that lie, and an origin fingerprint check for the signal the edge cannot see. None of it requires a separate WAF or DNS surgery, and the one real constraint — that TLS fingerprinting cannot happen in edge middleware — is a reason to move that check to the origin, not a reason to skip it.

What is your site seeing from AI crawlers lately? Curious whether others are blocking outright or rate limiting and keeping the referral traffic.

Originally published at webdecoy.com.

Related reading:

How to Detect Browser-as-a-Service Scrapers in 2025

webdecoy — Tue, 16 Dec 2025 19:41:08 +0000

Browserbase just raised $40 million at a $300 million valuation. Their pitch to developers? Run thousands of headless browsers in the cloud with "stealth mechanisms to avoid bot detection." They're not alone.

A new category of infrastructure has emerged: Browser-as-a-Service (BaaS). These platforms provide cloud-hosted Chromium instances specifically designed to evade detection. They rotate residential IPs, spoof user agents, strip automation markers, and patch JavaScript APIs. Their entire value proposition is making your bot detection obsolete.

The market is exploding. Browserbase has 20,000+ developer signups running 50 million browser sessions. Skyvern automates browser workflows with computer vision and LLMs. Hyperbrowser markets itself as "purpose-built for AI agents that operate on websites with advanced detection systems."

Here's the uncomfortable truth: traditional bot detection cannot catch them. But behavioral analysis can.

The Rise of Browser-as-a-Service

What BaaS Platforms Actually Do

Browser-as-a-Service platforms provide cloud-hosted browser infrastructure for automation at scale. Unlike traditional scraping tools that send raw HTTP requests, BaaS platforms run real Chromium browsers that execute JavaScript, render pages, and maintain sessions exactly like legitimate users.

The major players in 2025:

Browserbase - The market leader with $67.5 million in total funding. Offers managed headless browsers with session persistence, proxy support, and their Stagehand SDK for AI agent development. Used by Perplexity, Vercel, and 11x.

Skyvern - Y Combinator-backed platform that combines computer vision with LLMs to automate browser workflows. Claims 64.4% accuracy on WebBench benchmarks. Specializes in form filling, login automation, and RPA tasks.

Hyperbrowser - Explicitly "purpose-built for AI agents that operate on websites with advanced detection systems." Focuses on stealth, persistence, and staying undetected.

Browser Use - Open-source alternative gaining traction. Provides browser automation primitives that integrate with various AI frameworks.

The Business Model: Stealth as a Feature

These platforms compete on evasion capability. From Browserbase's marketing: "stealth mechanisms to avoid bot detection." From Hyperbrowser: "engineered to stay undetected and maintain stable sessions over time, even on sites with aggressive anti-bot measures."

This is not subtle. Stealth is the product.

How BaaS Platforms Evade Traditional Detection

Understanding evasion techniques is essential for building detection that works.

Stripping navigator.webdriver

The navigator.webdriver property is set to true when a browser is controlled by automation tools. Every BaaS platform removes it:

// What detection checks for
if (navigator.webdriver === true) {
  flagAsBot();
}

// How BaaS platforms evade
Object.defineProperty(navigator, 'webdriver', {
  get: () => undefined
});

Dynamic User-Agent Generation

BaaS platforms generate different user agents for each session. Stytch's research revealed: Browserbase generates slightly different user-agents each session, which sometimes aligns with the underlying Chromium runtime but sometimes attempts to be deceptive.

This creates detectable inconsistencies. The user agent claims Chrome 120, but the TLS fingerprint reveals the true Chromium version.

Patching JavaScript APIs

Modern stealth frameworks patch dozens of browser APIs:

// Chrome object spoofing
window.chrome = {
  runtime: {},
  loadTimes: function() {},
  csi: function() {},
  app: {}
};

// Plugins array spoofing
Object.defineProperty(navigator, 'plugins', {
  get: () => [
    { name: 'Chrome PDF Plugin', filename: 'internal-pdf-viewer' },
    { name: 'Chrome PDF Viewer', filename: 'mhjfbmdgcfjbbpaeojofohoefgiehjai' },
    { name: 'Native Client', filename: 'internal-nacl-plugin' }
  ]
});

Puppeteer Stealth includes 17 separate evasion modules. BaaS platforms build on these with proprietary improvements.

Why Stealth Mode Fails Against Behavioral Analysis

BaaS platforms have solved the static fingerprinting problem. What they cannot solve: making automation behave like humans.

Mouse Movement Entropy

Human mouse movement is chaotic. We overshoot targets, correct course, accelerate irregularly, and move in curves. Automation moves efficiently:

// Human mouse movement characteristics
{
  movement_count: 147,
  linear_path_ratio: 0.12,    // Mostly curved paths
  velocity_variance: 0.84,    // Highly variable speed
  overshoots: 4
}

// BaaS automation characteristics
{
  movement_count: 8,
  linear_path_ratio: 0.91,    // Straight lines
  velocity_variance: 0.08,    // Constant speed
  overshoots: 0
}

Even with "human-like" randomization, statistical analysis reveals synthetic patterns.

Click Timing Distributions

Human reaction times follow specific distributions—200-400ms for simple targets with characteristic right-skewed distribution:

// Human click timing (ms from target appearing)
[247, 312, 289, 198, 267, 334, 223, 278, 301, 256]
// Mean: 271ms, Std Dev: 42ms

// BaaS automation click timing
[150, 180, 160, 170, 155, 175, 165, 145, 185, 158]
// Mean: 164ms, Std Dev: 13ms — too consistent

Honeypot Link Effectiveness

The most reliable detection: invisible traps that only automation follows.

<!-- Hidden from visual users, visible in DOM -->
<a href="/admin-backup-2024"
   style="position:absolute;left:-9999px;opacity:0;pointer-events:none;"
   tabindex="-1"
   aria-hidden="true">
  Admin Backup Portal
</a>

Human users never see this link. Bots parsing HTML will find it. Any interaction is definitive proof of automation.

We built WebDecoy around this approach. Honeypots plus behavioral analysis plus TLS fingerprinting.

Detection Techniques That Actually Work

TLS/JA3/JA4 Fingerprinting

Every TLS handshake reveals the true client identity. The cipher suites, their order, extensions, and protocol versions create a unique fingerprint.

Real Chrome 120 JA4:
t13d1517h2_8daaf6152771_b0da82dd1658

Browserbase session claiming Chrome 120:
t13d1516h2_8daaf6152771_a9f2e3c71b42
// Different hash reveals different TLS stack

Even when the user agent claims Chrome 120, the TLS fingerprint reveals the actual Chromium version. The mismatch is a strong bot signal. (Deep dive on TLS fingerprinting)

Browser Capability Verification

The claimed browser should support specific capabilities:

// If User-Agent claims Chrome 120
const expectedFeatures = {
  'Array.prototype.toSorted': true,      // Added Chrome 110
  'Array.prototype.toReversed': true,    // Added Chrome 110
  'structuredClone': true,               // Added Chrome 98
};

for (const [feature, expected] of Object.entries(expectedFeatures)) {
  const actual = eval(`typeof ${feature} !== 'undefined'`);
  if (actual !== expected) {
    flagAsInconsistent('capability_mismatch', feature);
  }
}

JavaScript Environment Consistency

Stealth patches leave traces:

// Check if navigator.webdriver was patched
const descriptor = Object.getOwnPropertyDescriptor(navigator, 'webdriver');

if (descriptor && descriptor.get &&
    descriptor.get.toString().includes('undefined')) {
  flagAsStealth();
}

// Check for override detection
const nativeCode = /\[native code\]/;
if (!nativeCode.test(navigator.plugins.toString())) {
  flagAsStealth();
}

Canvas/WebGL Fingerprint Anomalies

BaaS platforms run on cloud infrastructure without GPUs. They use software rendering that produces distinct fingerprints:

function detectSoftwareRendering() {
  const canvas = document.createElement('canvas');
  const gl = canvas.getContext('webgl');
  const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
  const renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);

  const softwareIndicators = [
    'SwiftShader', 'llvmpipe', 'Mesa',
    'Software Rasterizer', 'ANGLE'
  ];

  return softwareIndicators.some(i => renderer.includes(i));
}

Real users have real GPUs. Cloud browsers have software rendering.

Multi-Signal Correlation

No single signal is definitive. Combine weak signals into strong verdicts:

class BotDetector {
  constructor() {
    this.weights = {
      tls_mismatch: 40,
      software_renderer: 35,
      stealth_patches: 30,
      behavioral_anomaly: 50,
      honeypot_interaction: 100,
      mouse_entropy_low: 40
    };
  }

  calculateScore(signals) {
    return Object.entries(signals)
      .filter(([_, detected]) => detected)
      .reduce((sum, [signal]) => sum + (this.weights[signal] || 0), 0);
  }

  getVerdict(score) {
    if (score >= 100) return 'block';
    if (score >= 60) return 'challenge';
    if (score >= 30) return 'flag';
    return 'allow';
  }
}

If you don't want to build this yourself, WebDecoy's SDK handles the scoring, SIEM integration, and response automation out of the box.

Implementation Recommendations

Start with Honeypots

Honeypots provide the highest confidence signals with zero false positives. Deploy immediately:

Hidden form fields that trigger on any input
Invisible links to trap endpoints
CSS-hidden content that only parsers see

Layer Detection Methods

Honeypots (zero false positives, catches 70-80%)
TLS fingerprinting (fast, server-side)
Behavioral analysis (catches sophisticated evasion)
Multi-signal correlation (highest accuracy)

Use Progressive Challenges

Low confidence: Log and observe
Medium confidence: Rate limit
High confidence: CAPTCHA challenge
Definitive (honeypot): Block

The Arms Race Continues

Browser-as-a-Service is not going away. The market is growing, funding is flowing, and the platforms are getting more sophisticated.

But the fundamental asymmetry favors defenders who invest in behavioral analysis. BaaS platforms can fake technical fingerprints. They cannot fake being human.

The question is not whether you can detect BaaS scrapers. The question is whether your current solution is designed for this threat.

Originally published at webdecoy.com

Want to catch BaaS scrapers without building it yourself? Try WebDecoy — deploys in 5 minutes.

More on this topic:

What's your experience with BaaS scrapers? Drop a comment below.