What is a website honeypot, and does your site need one?

Most website security works by filtering: look at each request, decide whether it seems malicious, act on the guess. Firewalls, rate limiters and bot detectors all share that shape, and they share its weakness — they are sometimes wrong in both directions. A honeypot works the other way around. Instead of judging traffic, you add something to your site that no legitimate visitor will ever touch: a path like /backup.zip that was never linked anywhere, a credential that was never valid. Then you watch it.

The power of this is that a hit needs no interpretation. A guest looking for a room does not request /wp-admin on a site that does not run WordPress. There is no threshold to tune, no false-positive rate to argue about, no model to retrain. The door exists for nobody, so anyone opening it has announced themselves.

What a honeypot catches that a firewall does not

Reconnaissance. Before anything is exploited, somebody walks through your site working out what it runs and where the interesting parts live. Nothing about that is an attack yet — every request looks ordinary on its own — so nothing blocks it, and the only record is a few dozen lines in an access log nobody reads. Trap paths make that walk visible while it is happening, which is the window in which knowing actually helps.

• Scanners asking for /.env, /.git/config, /backup.zip — the first requests of every automated sweep
• A person methodically enumerating your admin surface over several minutes
• A leaked or stolen credential being tried — if it is one you planted, the try is proof, not suspicion
• Tools probing API routes that were never published anywhere

Honeytokens: the same idea, applied to credentials

A honeytoken is a credential that looks real, works nowhere, and sits where somebody only finds it by looking where they should not — a config file, a database row, a code comment. Nobody legitimate ever holds one. So the moment one is used, you know two things at once: someone got somewhere they should not have been, and they are far enough along to be trying credentials. That is not a signal to weigh. It is a fact.

Does an ordinary business site need this?

If your website takes bookings or payments, it is being scanned today — not because anyone chose you, but because scanning everything is free. The honest question is not whether probing happens; it is whether you would currently know. For most small operations the true answer is no: the evidence lands in logs that are rotated away unread. A honeypot layer is the cheapest way to change that answer, because it produces one loud, unambiguous signal instead of a stream of maybes.

That is the product PharosHub sells: trap paths and honeytokens installed into your own site with one npm package, correlated into plain-language incidents, and an email when one is sprung. No proxy, no DNS change, no agent — and if our code ever fails, your site continues untouched, because a safety layer that can break the thing it protects is worse than none.