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:
