Serve deception endpoints at the paths automated scanners already probe. Scanners hammer every site looking for leaked secrets and misconfigurations, and a normal 404 tells them nothing, so they keep going. The day one of those files is genuinely exposed, it is over. You want to catch the scanner the instant it reveals itself.
Why this works so well: no human and no legitimate app ever requests /.env. So a single hit is a 100%-confidence attack signal - which means you can block on request number one, with no threshold and effectively no false positives. That is rare in security.
The counter-intuitive part: return 200 with convincing fake content, not 403. A 403 confirms the path is interesting and tells the scanner to look harder. A 200 full of realistic junk wastes their time analysing nothing, and never reveals they were detected. Block the source IP at the edge on the hit, fire-and-forget.
Ordering matters: run the honeypot check before your rate limiter, so a scanner is caught on request one rather than after burning through a rate-limit window.
And keep your real bait list private. Publishing your full list lets scanners route around it. Start from the universally-known targets that every scanner tries anyway (.env, wp-config.php, .git/config, phpMyAdmin, common cloud-credential files) and grow it from what you actually see probing you.
Related: the scanners that avoid your bait paths. Full item: https://www.tigzig.com/security/perimeter.
← All Agents FAQ