Unified Detection

Bot Threat Scoring & Automated Response Rules

Bot threat scoring combines every detection into one 0-100 risk score. Use response rules to monitor, challenge, or block traffic at thresholds you control.

0-20 Minimal
21-40 Low
41-60 Medium
61-80 High
81-100 Critical
Score Breakdown Score: 87
SQL Injection (25%)
+35
Honeypot Match (20%)
+25
Datacenter IP (15%)
+15
Bot User Agent (15%)
+12
Action: Revoke clearance · JA4 rule at WAF
The enforcement policy screen: token-enforced routes with minimum trust grades, and an explanation of what each grade asks of a real visitor

Policy in the product: token-enforced routes, and what each of the three trust grades asks of a real visitor.

Score Components

The unified score weighs seven factors to create a comprehensive risk assessment.

Component Weight Focus
Attack Signatures 25% SQL injection, XSS, command injection
Honeypot Match 20% Decoy link or endpoint interactions
IP Reputation 15% AbuseIPDB scores, threat lists
User Agent 15% Bot signatures and anomalies
Header Analysis 10% Missing or suspicious headers
Composite Fingerprint 10% JA4 TLS + canvas/WebGL device tiers
Behavior 5% Submission speed, mouse patterns

Threat Levels & Actions

Configure automated responses based on threat score thresholds.

MINIMAL

0-20

Allow requests

Legitimate visitors

LOW

21-40

Log for analysis

Monitor patterns

MEDIUM

41-60

Challenge with CAPTCHA

Review alerts

HIGH

61-80

Challenge or block

Notify security team

CRITICAL

81-100

Block immediately

Investigate source

Recommended thresholds: Financial sites: block at 60 · Standard sites: block at 75 · Public content: block at 85

Attack Detection

Signature Scoring

Attack signatures detected in requests add points to the threat score. Multiple signatures can combine for high scores.

SQL Injection +30-40
Command Injection +35-45
XSS Attempt +25-35
Multiple Honeypots +90-100
Score Explanation
{
  "total_score": 87,
  "level": "CRITICAL",
  "components": {
    "attack_signatures": {
      "weight": "25%",
      "contribution": 35,
      "signals": ["sql_injection"]
    },
    "honeypot_match": {
      "weight": "20%",
      "contribution": 25,
      "signals": ["endpoint_triggered"]
    },
    "ip_reputation": {
      "weight": "15%",
      "contribution": 15,
      "signals": ["datacenter_ip", "abuseipdb_score"]
    }
  },
  "recommended_action": "block_immediately"
}
Enforcement

A Queue of Judgments, Not a Config Screen

A score tells you how suspicious something looked. It does not tell you why. Enforcement decisions deserve evidence a human can check in three seconds, and that is only possible because deception produces explainable hits.

Decision Queue
[pending]  9f3c4a71
           device · 40 IPs · 3 sites · 2h ago

why: requested /wp-admin-backup.php at 03:41:12
     (a path that exists nowhere on your site,
     linked only from a hidden element on /pricing)

[ Deny for 30 days ]  [ Dismiss ]  [ Open actor → ]

Every benchmarked competitor answers “why did you think this was a bot?” with an opaque detection ID or a number. A honeypot hit explains itself in one sentence, and that sentence is the entire credibility of an enforcement decision. It must never collapse to “threat 92.”

  • Monitor mode builds the list

    A decoy hit in monitor mode writes a pending entry that affects nothing: never minting, never the edge config. By the time you enable enforcement, you are acting on a list you have already read.

  • Dismiss is as prominent as deny

    A queue that only lets you say yes is one people stop opening. Dismissals are cheap to reverse, and an actor you dismissed that later trips a second decoy is resurfaced rather than silently re-queued.

  • Enforce is a gate, not a toggle

    Four preconditions: clearance key installed, routes scoped, edge validator alive, WAF connected. Fail any one and the switch is disabled with a stated reason, rather than accepting a click that quietly does nothing.

  • Counters that mean something

    Every number shown as an outcome is an event count (mint attempts actually refused, requests actually challenged), never a row count dressed up as a result.

Two lanes, stated plainly. Browsers resolve to a device-tier identity and get session clearance tokens, revoked on every IP the moment a decoy is tripped. Clients that never open a browser, including everything the edge sensor catches, resolve only to a network-tier JA4 fingerprint, so they are handled by composite, auto-expiring WAF rules instead. Different evidence, different enforcement, and the product tells you which one applies rather than implying a single story.

Integrations

When WebDecoy detects a threat, automated actions execute across your security stack.

Cloudflare

WAF/Blocking

Composite signatures + graduated challenges

AWS WAF

WAF/Blocking

Composite signatures + graduated challenges

Fastly

WAF/Blocking

Access control lists

Vercel

Edge

Edge middleware + blocking

Slack

Notifications

Real-time alerts

CrowdStrike

SIEM

Falcon LogScale events

Datadog

SIEM

Event forwarding & metrics

Webhooks

Custom

POST to any endpoint

Recommended Setup

Start with these integration combinations for effective protection.

Basic Protection

For most websites and applications.

  • Cloudflare or AWS WAF for blocking
  • Slack for real-time alerts
  • Block threshold at 75

Comprehensive Security

For high-security or financial applications.

  • WAF integration (Cloudflare/AWS)
  • SIEM (CrowdStrike or Datadog)
  • Slack + custom webhooks
  • Block threshold at 60

Why Automate Bot Blocking

Manual bot response is too slow. Automated rules block attackers in milliseconds.

Sub-Second Response

Automated rules trigger within 100ms of detection. By the time a human reviews an alert, the attacker has already moved on.

Edge-Level Blocking

WebDecoy pushes a composite actor signature to your WAF and defaults to a challenge: the safe, cheap layer that stops datacenter and scripted bots before they reach your origin. Browser-grade rotators are caught by session clearance instead, so real users who share a fingerprint pass invisibly.

Scales Automatically

Handle thousands of concurrent attacks without manual intervention. Rules scale with your traffic and threat volume.

Frequently Asked Questions

Common questions about threat scoring and automated bot blocking.

How is the threat score calculated?

The threat score (0-100) combines seven weighted factors: attack signatures (25%), honeypot matches (20%), IP reputation (15%), user agent analysis (15%), header analysis (10%), composite fingerprint from JA4 TLS plus canvas/WebGL device signals (10%), and behavioral signals (5%). Multiple detections combine to push scores into critical ranges, and a single fingerprint seen rotating across many IPs escalates the score further.

What actions can be triggered based on threat scores?

You configure automated responses at each threshold: allow normal traffic (0-20), log for monitoring (21-40), challenge with CAPTCHA (41-60), challenge or block (61-80), and block immediately (81-100). Actions can include revoking the actor's session clearance, pushing a composite fingerprint rule to your WAF for datacenter bots, Slack alerts, SIEM forwarding, and custom webhooks.

How does the Cloudflare WAF integration work?

When WebDecoy confirms an actor worth acting on, it writes a composite signature into your Cloudflare WAF (the JA4 combined with the actor's network and path scope, never a bare fingerprint) and defaults to a Managed Challenge, reserving outright blocks for honeypot-grade evidence. Every rule starts in monitor mode, carries an automatic expiry, and is reversible in one click; verified bots like Googlebot are always allowlisted, and "verified" now means a Web Bot Auth signature or a published IP range that checks out, never a user-agent string. The integration uses the Cloudflare API (Bot Management is required for the JA4 field) and is opt-in per route. This rule layer targets datacenter and scripted bots; browser-grade rotators are handled by session clearance, which a decoy hit revokes on every IP.

How does the verified-crawler allowlist work?

Turning on "allow AI crawlers" or "allow search engines" used to mean matching a user-agent substring, which is a spoofing hole: copying the GPTBot header is one line of code. Now an agent passes the allowlist only by proving its identity: a source IP inside the operator's published ranges with forward-confirmed reverse DNS, or a valid Web Bot Auth (RFC 9421) signature. The IP-range and rDNS path does the work today (it is what Google recommends for verifying Googlebot, and few operators sign yet), while signature verification runs alongside it and strengthens as adoption grows. An agent that only claims an identity fails the allowlist, and one that claims an identity it cannot prove is scored as agent impersonation. WebDecoy runs both checks itself, so this works on any zone rather than only Cloudflare.

Do I have to start blocking to get value from enforcement?

No, and you should not. Monitor mode runs with pass-through semantics: a decoy hit writes a pending deny-list entry with its evidence attached, but that entry never affects clearance minting or the edge config. You accumulate a reviewable list of confirmed bots while blocking nothing. When you do flip to Enforce, the UI tells you exactly what will happen ("14 pending devices will be denied, review them first"), and only the entries you approved are promoted. Enforce itself is gated on four preconditions and refuses with a stated reason if any of them fail, rather than accepting a click that silently does nothing.

Can a route require a minimum trust level?

Yes. Session clearance tokens now carry a graded trust level (clean, human-likely, or attested-human) along with the evidence that earned it, and a route scope can require a minimum. A session below the bar is challenged rather than passed. This is enforced today by the edge validator; SDK-side minimum-trust enforcement is in progress. Evidence only ever raises a grade and a high threat score caps it, so sessions that produce no evidence behave exactly as they did before.

Can I customize the threat score thresholds?

Yes. You set your own thresholds for each action. Financial and high-security sites typically block at score 60, standard business sites at 75, and public content sites at 85. You can also configure different thresholds for different paths or endpoints.

How do I send bot detections to my SIEM?

WebDecoy supports native integrations with Splunk, Elastic Security, CrowdStrike Falcon LogScale, and Datadog. You can also use universal formats like Syslog and CEF. Detection events include full context: threat score, attack signatures, IP metadata, and user agent analysis.

Ready to automate bot blocking?

Configure threat scoring rules that integrate with Cloudflare, AWS WAF, and your SIEM.

Get Started Free