Bot Defense: Building a Multi-Layered Anti-Bot Strategy
Enterprise Bot Defense from Prosopo
Multi-layered protection against credential stuffing, scraping and account takeover
What is Bot Defense?
Bot defence is the practice of keeping automated abuse off the parts of your service that cost you money, while leaving the automation you want working. It is the operational discipline around bot protection rather than a distinct technology.
The reason it needs a practice rather than a product is that the attacker adapts. Any single check has a counter, and the counters are cheap and widely distributed, so what holds up is a layered position where defeating one layer gains the attacker less than it costs them.
The layers, in the order they should be built
| Layer | What it does | What it costs you |
|---|---|---|
| Honeypot fields | Removes naive form spam | A few lines of markup |
| Rate limits on expensive endpoints | Caps volume per identifier | Tuning, and the risk of blocking shared addresses |
| Client coherence checks | Catches automation contradicting itself | Nothing visible to the user |
| Behavioural analysis | Asks whether a person was present | Needs a session to observe |
| Proof of work | Prices every attempt in CPU time | A brief delay on the client |
| Visible challenge | Resolves the genuinely ambiguous cases | Real friction. Reserve it |
Build upwards. The first two are nearly free and remove a large share of the volume, which means the expensive checks run against less traffic.
What distinguishes a defence from a purchase
Three things, and none of them are features:
Knowing which flows matter. Login, sign-up, password reset, checkout, search, and any API that writes. Protecting the whole site uniformly spends friction where there is nothing to protect and dilutes attention from where there is.
Watching the false-positive side. Catch rate is the number vendors quote, and the rejected-customer rate is what costs you revenue. You will not learn it from support tickets, because blocked users leave silently. Test with a screen reader, a privacy browser and a mobile network before you trust a configuration.
Keeping the wanted automation working. Search crawlers, uptime monitors, payment webhooks, customers' own integrations, and AI assistants fetching a page for a real person. Verify the ones that publish IP ranges against those ranges, and treat user-agent strings as unreliable.
Measuring whether it is working
Not by blocked-request counts, which go up when you tighten a threshold regardless of whether anything improved. Use outcomes:
- Failed-login volume on the authentication endpoint
- Fake or disposable account registrations getting through
- Completed checkouts versus inventory held by non-purchasing sessions
- Support contacts from users who could not get through, which is your false-positive signal
And expect to revisit it. A configuration that worked six months ago is a configuration an adversary has had six months to study.