Detection Source Types

Reference table of all detection sources in WebDecoy.

---

Detection Sources Overview

A detection row carries one source value. Charts and source filters use a narrower vocabulary than the rows do: several row-level values bucket into a broader category rather than having a slice of their own.

Filter and chart vocabulary

These are the seven categories you can filter and chart by:

Source	Code	Icon	Description
Decoy Link	decoy_link	Link	Hidden honeypot link was accessed
Endpoint	endpoint	API	API honeypot received a request
Detection Script	bot_scanner	Robot	JavaScript scanner detected automation
SDK	sdk	Code	Server-side SDK submitted a detection
Agent	agent	Shield	Legacy: SSH honeypot agents were retired, so only older rows land here
Edge Worker	edge_worker	Cloud	An edge sensor (Cloudflare Worker, Netlify edge function, Vercel drain, Fastly log stream) saw an automated client in front of your origin
Unknown	unknown	Sensors	A source this build of the dashboard has not been taught yet

unknown is deliberately part of the vocabulary rather than a bug. If the server reports a source the UI does not recognise, it stays visible and obviously unlabelled instead of being quietly folded into a real category and inflating its count.

Row-level values that bucket into the above

Source	Code	Icon	Buckets into
WordPress	wordpress_plugin	Globe	SDK
Tripwire	sdk_tripwire	Flag	SDK
PHP sensor	php_sensor	Code	SDK
Cloudflare history import	cloudflare_logs	Cloud	Edge Worker
Netlify edge function	netlify_edge	Cloud	Edge Worker
Vercel log drain	vercel_drain	Cloud	Edge Worker
Fastly log streaming	fastly_logs	Cloud	Edge Worker
Shopify pixel and app	page_view, behavioral, shopify_app, shopify_script	Robot	Detection Script
Form honeypot field	honeypot_field, shopify_honeypot	Link	Decoy Link
Honeypot Agent (retired)	honeypot_agent	Shield	Agent

Rows show the value above; charts show the bucket. A WordPress detection therefore appears as “WordPress” on the detection itself and inside the SDK slice on a chart.

LLM referrals are not a source

Earlier versions of this page listed llm_referral as a source code. It is not one. An LLM referral is a flag on a detection whose source is bot_scanner or decoy_link, carried in metadata as is_llm_referral alongside llm_platform. Filtering by source will not find them; the AI Referrals views will. See LLM Referral below.

---

Decoy Link (decoy_link)

Description

Detections from hidden honeypot URLs that legitimate users cannot see or access.

Typical Data

Field	Example
URL	/admin/backup.zip
Method	GET
Trigger Action	Log, Block, Poison, Redirect
Click Count	Incremented on each access

Common Scenarios

• Bot crawling hidden links
• Scanner probing common admin paths
• Attacker following disallowed robots.txt paths

MITRE Mapping

Usually mapped to:

• TA0043 (Reconnaissance)
• TA0001 (Initial Access)

---

Endpoint (endpoint)

Description

Detections from fake API endpoints that capture detailed request information including POST bodies.

Typical Data

Field	Example
URL	/api/v1/admin/users
Method	POST, PUT, DELETE, PATCH
Body	Captured request body
Content-Type	application/json
Attack Signatures	SQL injection, XSS, etc.

Endpoint-Specific Fields

Field	Description
request_body (metadata)	Captured body content, when body capture is on
request_body_size	Size in bytes
content_type	Content-Type header value
has_auth_header	Whether Authorization header present
attack_signatures (metadata)	Detected attack patterns

Common Scenarios

• API vulnerability scanning
• SQL injection attempts
• Authentication bypass attempts
• Data exfiltration probing

MITRE Mapping

Usually mapped to:

• TA0001 (Initial Access) - for exploit attempts
• TA0006 (Credential Access) - for auth attacks
• TA0007 (Discovery) - for enumeration

---

Detection Script (bot_scanner)

Description

Detections from the JavaScript-based scanner running in visitors’ browsers.

Typical Data

Field	Example
Triggers	Flags the script raised, such as webdriver or headless
Client score	0-100, computed in the browser
Fingerprint	Canvas, WebGL, and audio characteristics (in metadata)

Scored Triggers

These are the trigger names the scorer weighs (from ingest/internal/services/unified_scorer.go):

Trigger	Indicates
webdriver	WebDriver automation
puppeteer / playwright / selenium	That automation framework
phantom / nightmare	PhantomJS / Nightmare.js
automation / domautomation	Generic automation markers
cdp / cdc	Chrome DevTools Protocol artifacts (including ChromeDriver cdc_ properties)
headless	Headless browser (ignored on mobile)
software_renderer	Software WebGL renderer such as SwiftShader
no_plugins / low_mouse_count	Weak anomalies, ignored on mobile
claude_extension, chatgpt_extension, copilot_extension, …	AI browser extensions

Stealth Signals (Pro script)

The Pro script also reports stealth-plugin evidence:

Signal	Indicates
lie_tampering plus lie_<type> subtypes	Native functions or properties modified by a stealth plugin (8 points each, capped at 30)
audio_mocked / audio_zero / no_audio_context	AudioContext anomalies
worker_mismatch (metadata)	Main-thread and Web Worker navigator values disagree

Common Scenarios

• Headless browser scraping
• Automated testing tools on production
• Bot networks using browser automation

MITRE Mapping

Usually mapped to:

• TA0043 (Reconnaissance) - for scraping
• TA0009 (Collection) - for data theft

---

WordPress Plugin (wordpress_plugin)

Description

Detections from the WebDecoy WordPress plugin’s server-side analysis.

Typical Data

Standard detection fields (IP, user agent, score, threat level) plus the flags the plugin’s server-side analysis raised, such as a rate-limit hit, a tripwire path, or a filled honeypot form field.

Common Scenarios

• Comment spam bots
• Login brute force attacks
• Registration spam
• Card testing on WooCommerce

These rows are recorded whether or not anything was blocked

From plugin version 2.3.2 onward, monitor mode is the default: the plugin detects, logs and reports everything and blocks nothing until an admin turns blocking on. A full stream of wordpress_plugin detections next to an empty block list is the expected state on a fresh install.

MITRE Mapping

Usually mapped to:

• TA0006 (Credential Access) - for login attacks
• TA0001 (Initial Access) - for form exploits

---

SDK (sdk)

Description

Detections submitted by a server-side SDK such as @webdecoy/node and its framework adapters. The PHP package reports as php_sensor.

Typical Data

Standard detection fields (IP, user agent, path, score) plus the request signals the SDK collected. See the Sensor Protocol for the exact wire fields.

Common Scenarios

• Custom server-side bot detection
• Middleware-based protection
• API gateway integration
• Custom threat analysis

MITRE Mapping

Depends on detection context. Typically:

• TA0043 (Reconnaissance)
• TA0001 (Initial Access)

---

Tripwire (sdk_tripwire)

Description

A hidden honeypot path was requested: scanner-bait such as /.env, /.git/config or /wp-config.php, planted by the WordPress plugin or an SDK. These paths exist nowhere on your site, so a request for one is a deterministic signal of automated intent rather than a heuristic guess. The SDK reports it with confidence 100.

Charts bucket these into SDK; the detection row says Tripwire.

Typical Data

Field	Example
Path	/.env
Rule	tripwire
Action	DENY, THROTTLE, CHALLENGE, LOG
Dry run	Whether the rule was in dry-run / monitor mode

Scoring

A tripwire hit contributes a flat +40 to the threat score under the signal tripwire_triggered, at confidence 0.95. It is scored on the same footing as a decoy or endpoint hit: proof rather than inference.

Why it matters for enforcement

A tripwire hit is the one signal that can durably lock out a device. When the hit is live (not dry run), the action is DENY, and the request carries a wd_clearance cookie, the actor’s clearance fingerprint is added to the deny list, with the path recorded as the reason (tripwire:/.env). Heuristic rules such as filter and rate-limit rules never do this, so the deny list is fed by the deception signal alone.

MITRE Mapping

Usually mapped to TA0043 (Reconnaissance) and TA0007 (Discovery).

---

LLM Referral

Not a source of its own. An LLM referral is a detection with is_llm_referral set in its metadata; its source stays bot_scanner or decoy_link, whichever recorded it.

Description

Recorded when a visitor arrives from an AI platform. These represent human visitors who clicked a link shared by an AI chatbot (e.g., ChatGPT, Perplexity, Claude).

Typical Data

Field	Example
Score	0 (always)
is_llm_referral	"true"
llm_platform	ChatGPT, Perplexity, Claude, etc.
Referrer	https://chatgpt.com/c/abc123
Page URL	The landing page URL

Tracked Platforms

Platform	Domains
ChatGPT	chat.openai.com, chatgpt.com
Perplexity	perplexity.ai, www.perplexity.ai
Google Gemini	gemini.google.com
Claude	claude.ai
DeepSeek	deepseek.com, www.deepseek.com, chat.deepseek.com
Microsoft Copilot	copilot.microsoft.com
You.com	you.com, www.you.com
Phind	phind.com, www.phind.com
Kagi	kagi.com, www.kagi.com
Meta AI	meta.ai, www.meta.ai
Grok	grok.com, www.grok.com

Common Scenarios

• User asks ChatGPT a question, ChatGPT links to your site, user clicks the link
• Perplexity search results include your page as a source
• AI assistant recommends your product/service with a link

Key Difference from Other Sources

LLM referral detections are not threats. They have a score of 0 and are used for analytics purposes: understanding how AI platforms drive traffic to your site.

---

Edge Worker (edge_worker)

Description

A Cloudflare Worker running in front of your origin reported an automated client. Edge sensors (this Worker, and the other edge rows that bucket here) are the sources that can see a client which never executes JavaScript: Googlebot’s crawl pass, GPTBot, ClaudeBot, CCBot, curl, most scrapers.

bot_scanner runs in the visitor’s browser, so it structurally cannot observe these clients. The two sources see different populations and neither replaces the other. See the Cloudflare Edge Sensor guide to install it.

Typical Data

• User agent, path, and IP as seen at the edge, before your origin
• Request-shape signals a browser would normally satisfy: missing Accept-Language, absent fetch metadata, header ordering
• Cloudflare’s own verifiedBotCategory where available
• Whether the client presented a valid Web Bot Auth signature

Edge-Specific Behaviour

Reporting is gated on configuration. The Worker only reports when it is served an enabled config carrying a scanner id. A deployed Worker with reporting off classifies every request and sends none of them. Check Reporting: On on the integration card.

Volume is bounded deliberately. Repeated reports for the same client and path are capped at the edge, so counts are a floor rather than an exact total. The cap is per Worker isolate, and Cloudflare creates isolates freely under concurrency, so the effective limit is higher than the configured number.

Weak signals are sampled. Strong signals (a known crawler, a valid signature, a crawler path) are never sampled away.

Common Scenarios

• An AI training crawler indexing your content, invisible to every other source
• A search engine’s crawl pass, with timestamps you can reconcile against Search Console
• A client claiming to be Googlebot from an address Google does not own

MITRE Mapping

Usually mapped to TA0043 (Reconnaissance).

---

Source Comparison Table

Source	Server-Side	Client-Side	Body Capture	Attack Signatures
decoy_link	Yes	No	No	Basic
endpoint	Yes	No	Yes	Full
bot_scanner	No	Yes	No	Automation
wordpress_plugin	Yes	Yes	Limited	Full
sdk	Yes	No	Custom	Custom
sdk_tripwire	Yes	No	No	Path only, deterministic
edge_worker	Yes (edge)	No	No	Crawler and tool identification

---

Which sources are reporting for you

Every source in this reference is a sensor, and the Sensors page (sidebar, under Countermeasures) lists the ones actually reporting for each of your sites: edge workers, the WordPress plugin, the SDKs, detection scripts, decoy links, and tripwires. Per sensor it shows the last time it was seen and its detection counts over 24h and 7d.

That page is the right place to answer “why do I have no edge_worker rows”, because it distinguishes a sensor that is installed and silent from one that was never installed. See Cloudflare Edge Sensor.

---

Filtering by Source

In the Dashboard

1. Go to Detections
2. Click Filters
3. Select Source filter
4. Check desired sources

Remember that the filter uses the seven-category vocabulary above. Selecting SDK includes WordPress and Tripwire rows.

Via API

GET /api/organizations/{org_id}/detections?source=endpoint

Multiple sources (repeat the parameter):

GET /api/organizations/{org_id}/detections?source=endpoint&source=bot_scanner

The API matches row-level source values exactly. source=sdk does not include wordpress_plugin rows; list each value you want.