Bot Protection: How to Detect & Block Malicious Bots
What is Bot Protection?
Bot protection is deciding which automated traffic to allow. Not blocking bots — that framing causes bad decisions, because a large share of automated traffic is wanted: search engine crawlers, uptime monitors, payment webhooks, partner integrations, and increasingly AI assistants fetching a page on behalf of a real person.
The job is separating automation you want from automation you do not, and doing it without rejecting customers.
What it is defending against
| Abuse | What the attacker gains |
|---|---|
| Credential stuffing | Working account credentials, replayed from breaches elsewhere |
| Scalping and inventory hoarding | Limited stock bought before customers can reach it |
| Scraping | Your pricing, catalogue or content, at no cost to them |
| Spam and fake accounts | Distribution for their content, or abuse of a signup offer |
| Click fraud | Your advertising budget |
| Card testing | Confirmation of which stolen card numbers are live |
None of these exploit a vulnerability. They use working features at machine speed, which is why a WAF does not address them and patching does not either.
How the decision gets made
Four families of signal, with different robustness:
Reputation — is this address a known data centre, proxy or previous offender. Cheap, and the easiest for an attacker to escape by renting residential proxy access. Useful for exclusion, dangerous for conviction: plenty of real users arrive through corporate VPNs and carrier NAT.
Client coherence — does the client's claimed identity hold together. See device fingerprinting; contradictions are durable where matching is not.
Behaviour — does the interaction look like a person was there. See behavioural analysis. Hardest to forge, needs a session to observe.
Cost — proof of work charges CPU time per attempt. It does not identify anyone; it changes the attacker's arithmetic, which is the only approach that works when the attacker's identity is unknowable.
Good products weigh these against each other. A product that convicts on any single one, especially reputation, generates false positives on real customers.
Catch rate needs a second number
Vendors quote catch rate. The number you should ask for alongside it is the false-positive rate, because the two are a trade and catch rate alone can be bought by rejecting anything unusual.
False positives are also the error you will not see. A rejected customer does not file a support ticket; they leave. And the users most likely to be rejected are those whose setup looks atypical — privacy browsers, assistive technology, older devices, mobile networks, and anyone outside the regions a model was tuned on.
Where to put it
Protect the flows that cost you money rather than the whole site: login, sign-up, password reset, checkout, search, and any API endpoint that writes. Verify server-side — a verdict reported by the browser is one the attacker controls. And keep a path for the automation you want, since blocking Googlebot or a customer's own integration is a self-inflicted outage.