The first three layers refuse traffic. This one listens to it. A honeypot is a path, form field or endpoint that has no legitimate use, so any access to it is a signal rather than an interpretation.

A honeypot turns a silent probe into an early warning without touching real visitors.

What this layer is

  • A decoy path such as /backup.zip or /wp-admin.php that no visitor and no crawler should request.
  • A hidden form field that only an automated agent fills (we use one on the enquiry form).
  • A record of what arrived: address, user agent, timing, follow-up requests.

What our own logs already show

In our own window: 71,191 requests, of which 40,263 were refused and 33,133 matched known scan paths; the top five probe paths were /v1/graphql (857), /api/graphql (845), /graphql (831), /api/config (814) and /actuator/loggers (533). Those paths are the raw material: a honeypot simply gives a subset of them a dedicated, unambiguous lane.

Where we disagree with the textbook

Honeypot write-ups often promise fingerprinting — canvas hashes, font lists, plugin inventories. On a static site there is nothing to run: no JavaScipt payload is served to a scanner, no cookie jar exists, and the only durable signals are the address, the user agent, the request order and the timing. Claiming more than that would be theatre.

The second caution is liability. A decoy must never be indexed (keep it out of robots.txt sitemaps and out of navigation), must answer exactly like a normal missing path so it cannot be fingerprinted itself, and whatever you record about visitors becomes data you are responsible for. We already mask visitor addresses in public output for that reason.

How to verify

  • Our form honeypot is documented in the lead service; a submission that fills it is dropped and logged, never delivered.
  • Published scan-path counts come from the same log, with definitions in /data/live.json.
  • Visitor addresses in public data are always masked before publication.
Sources: our own access log, lead service and public data files; OWASP automated threats for where honeypots sit in an abuse-control model (owasp.org); RFC 9309 for why a decoy must stay out of crawler guidance (rfc-editor.org).

Do honeypots stop scanners?

No. They detect and inform. Refusal stops the request; a honeypot tells you it happened.

Is a hidden form field a honeypot?

Yes, and the cheapest one: automated submissions fill it, humans do not, and the message can be dropped without a challenge.

What can I fingerprint on a static site?

Address, user agent, timing and request order. Browser-side fingerprinting needs a payload - and serving one to a scanner is its own risk.

Related reading: Five Layers of Scanner Defence, Tested on Our Own Site · Layer 5: Closing the Loop in Public

More on this site: live signals · dated reports · how to verify us