Most WordPress attacks start with reconnaissance. A bot or a script kiddie pokes around your site looking for old plugin paths, exposed backup files, or login forms that will accept a flood of guesses. That probing happens long before any real damage, and it leaves a trail. Honeypots and tripwires are a cheap way to catch that trail and turn it into an alert, instead of letting it slide by unnoticed in your logs.
None of this replaces a firewall, backups, or timely updates. Think of it as a smoke detector, not a fire suppression system. The payoff is simple: you find out something is probing your site while it is still just probing, not after it has found a way in.
Why decoys work
Automated attack tools are pattern matchers. They request known vulnerable paths, submit forms as fast as possible, and follow predictable scripts. Human attackers doing manual reconnaissance are only slightly more careful. Both behaviors are easy to trap because real visitors and legitimate crawlers almost never touch things that are deliberately hidden from normal navigation.
A honeypot is bait that looks valuable but isn’t. A tripwire is a sensor that fires when something touches bait it should never touch. Put the two together and you get a low noise, high signal alert system that costs almost nothing to run.
Form-level honeypots
The simplest and most battle-tested tripwire is a hidden field on any public form: comments, contact forms, registration. Real users never see or fill it in because it is hidden with CSS, but scripted bots that auto-fill every input on a page will populate it every time.
<input type="text" name="hp_website" value="" style="position:absolute;left:-9999px;" tabindex="-1" autocomplete="off">
On submission, reject anything that filled the field:
if ( ! empty( $_POST['hp_website'] ) ) {
// Silently drop it, or log the IP for later review.
wp_die( 'Spam detected.' );
}
This costs nothing in user experience and quietly filters a large share of automated spam and credential stuffing attempts before they ever reach your database.
Fake endpoints as tripwires
You can extend the same idea to whole URLs. Create a path that has no legitimate reason to be requested, like /wp-content/uploads/backup-old.zip or /hidden-admin/, and wire it to log and alert whenever it is hit. A small must-use plugin does this cleanly:
add_action( 'init', function() {
if ( '/hidden-admin-backup/' === $_SERVER['REQUEST_URI'] ) {
error_log( 'Tripwire hit from ' . $_SERVER['REMOTE_ADDR'] );
// Send a webhook notification here if you want real-time alerts.
status_header( 404 );
exit;
}
});
Because this path is never linked anywhere on your site, no legitimate visitor or search engine crawler should ever request it. Any hit is a strong signal that something is scanning your site directly, path by path, looking for weaknesses.
Good places to plant decoys
- Fake backup files with plausible names (
site-backup.sql,db-export.zip) - Old plugin or theme paths that sound outdated (
/wp-content/plugins/old-slider/) - A decoy admin path that is not your real
wp-admin - A fake
.envorconfig-backup.phpfile in a predictable location
Canary tokens
A canary token is bait that is meaningless on its own but triggers an alert the moment it is used. A classic example is planting a fake database credential in a comment inside wp-config.php, or a fake API key in a file that should never be read by anything but an attacker who got shell access. If that fake credential ever shows up in an authentication attempt against a service you control, you know your file system was read by someone who shouldn’t have had access.
You do not need a commercial canary token service to do this. A fake row in an unused database table, a fake admin user with an obviously fake email that alerts you the moment it logs in, or a decoy file that pings a webhook when it is requested, all work the same way. The value is not in the bait itself, it is in the alert that fires when the bait is touched.
Wiring up the alert
A tripwire that only logs quietly to a file nobody reads is not much use. Route the alert somewhere you will actually see it: email, a Slack or Discord webhook, or a monitoring dashboard. Keep the alert itself lightweight so it does not become another attack surface. A simple outbound HTTP call from the tripwire handler to a webhook URL, with the requesting IP and timestamp, is usually enough context to act on.
If your site sits behind Cloudflare, you can add a second layer here. Custom firewall rules can be set to log or challenge traffic hitting your decoy paths, giving you visibility at the edge before the request even reaches your origin. This is also a good reminder that keeping your origin IP unpublished matters: if attackers can bypass Cloudflare and hit your server directly, your tripwires and WAF rules at the edge won’t see the traffic at all.
Complementary checks with wp-cli
Tripwires catch reconnaissance. A separate but related habit is verifying that core files and plugins have not been quietly modified, which catches attacks that already succeeded. wp-cli makes this a one-line check you can run on a schedule:
wp core verify-checksums
wp plugin verify-checksums --all
Wire either command into a cron job that emails or webhooks you on failure, and you have a second tripwire layer that watches your file system itself rather than just your traffic.
Keep expectations realistic
Honeypots and tripwires are early warning, not defense. A determined attacker who already has valid credentials or a working exploit will not necessarily trip a decoy field or fake path. Treat this system as one more layer alongside real hardening: strong unique passwords, two factor authentication on admin accounts, prompt core and plugin updates, a proper firewall (a managed host like ServerBorn typically handles the server-level firewall and edge protection for you), and regular offsite backups. The decoys buy you time and visibility. The rest of your security posture is what actually stops the attack.
Takeaway
Attackers almost always look before they leap. Honeypot fields catch bots filling out forms they shouldn’t touch. Fake endpoints catch scanners probing paths no human would ever request. Canary tokens catch anyone reading files or credentials they should never see. None of it is expensive or complicated to set up, and all of it turns silent reconnaissance into a signal you can actually act on, often days or weeks before a real attack would otherwise announce itself.