Nexren ShieldWhat problem does bot protection solve?
Bot protection tries to tell whether a request comes from a real person or from automation. The goal is not to block every bot. You let wanted bots, such as search engine crawlers, through, and you stop the ones that scrape content, test stolen passwords or hoard stock.
There is no single definitive answer. Each method yields one signal, and attackers try to imitate that signal. The practical goal is to push the cost of an attack above its payoff. A WAF catches known attack patterns; bot protection looks at who is sending the request.
Which bot types exist?
| Type | Example | Typical response |
|---|---|---|
| Good crawlers | Search engine bots | Allow, verify identity |
| Scrapers | Price and content harvesters | Rate limit, require verification |
| Credential stuffing | Replaying leaked passwords on login forms | Protect the login path separately, multi-factor authentication |
| Scalpers | Bots that grab limited stock | Strong verification on the purchase path |
| Volumetric bots | HTTP flood generators | Automatic verification, rate limits |
Credential stuffing is especially hard because the requests look like ordinary logins. Each IP sends only a few attempts, so total volume stays low.
Which layers detect bots?
The layers complement each other; when one is evaded, the others still shift the score.
- IP reputation. Known malicious ranges and data-center blocks carry a suspicion score. This layer is cheap, but it can also affect legitimate users behind shared NAT addresses.
- TLS and HTTP fingerprints. The client's TLS handshake and HTTP/2 settings reveal which software stack it runs. See the TLS fingerprinting guide for details.
- Behavior. Mouse and touch movement, typing rhythm, page flow. Humans are irregular; simple bots are too regular.
- Challenges. You ask the client to do some work: solve a puzzle, compute something, run JavaScript.
How do challenge types compare?
| Type | User cost | Privacy | Accessibility | Main weakness |
|---|---|---|---|---|
| Image/click CAPTCHA | High, a puzzle every time | Often a third-party script and cookies | Poor | ML models and human solver services |
| Proof-of-work | Low, a few seconds of CPU | No third-party data needed | Good, no interaction | Parallel solving farms |
| Time-lock (RSW) PoW | Low, a few seconds of CPU | No third-party data needed | Good | Specialized hardware (ASIC/FPGA) |
| Invisible, risk-based | Zero for most users | Collects behavioral data | Usually good | Signals can be imitated |
The W3C covers the accessibility problems of image CAPTCHA in its note "Inaccessibility of CAPTCHA". For users with visual or cognitive disabilities, a puzzle is a direct barrier.
Why is proof-of-work alone not enough?
Proof-of-work (PoW) asks the client for a small computation. For a user the cost is a few seconds of CPU time. For an attacker the cost multiplies with the number of requests, which makes mass automation expensive.
The economics cut both ways, though. An attacker can solve the puzzle on their own servers, fast and in parallel. If a native program solves it instead of the browser, it can run faster than JavaScript. A multi-core "solving farm" cuts the per-request cost even further.
What is the time-lock (RSW) idea?
A time-lock puzzle ties the answer to steps that must be computed in sequence. In the construction Rivest, Shamir and Wagner proposed in 1996, each step uses the result of the previous one (repeated modular squaring). The steps cannot run in parallel, so adding 1,000 processors does not shorten the time.
An analogy: ordinary PoW says "roll the dice a thousand times", and a thousand people can split the job. A time-lock says "double this number a thousand times, one after another"; each step depends on the last, so team size does not help. Only hardware that performs a single step faster, such as an ASIC or FPGA, gains an advantage. A time-lock therefore closes the parallelism that makes solving cheap, but it does not close hardware acceleration.
Why do privacy and accessibility decide the choice?
Image CAPTCHAs usually load a third-party script and share visitor data with that party. That can affect cookie notices and KVKK obligations; see KVKK and security logs. A no-interaction proof-of-work needs no clicks, no image selection and no third-party cookie.
Two tests help on accessibility: can the puzzle be solved by keyboard and screen reader, and does the verification demand cognitive effort? Interaction-free methods fare better on both. On the other hand, clients that cannot run JavaScript cannot pass; document that limit openly.
How Nexren Shield handles this
Nexren Shield verifies in layers:
- Bot score. A heuristic score, behavioral telemetry and IP reputation combine. For reputation, the Spamhaus DROP and FireHOL level1 lists refresh daily.
- TLS and HTTP fingerprints. JA3/JA4 and HTTP/2 fingerprints feed the risk assessment at verification time.
- Risk model. A logistic-regression model with hand-set starting weights adds at most 30 points to the score.
- Challenge. A no-image, no-click, privacy-friendly proof-of-work. The time-lock (RSW) puzzle runs in WebAssembly: it performs sequential modular squarings, cannot be parallelized, and a GPU does not help. The default is t=75,000 squarings. It runs alongside a BLAKE2b PoW.
- Nightly rule evolution. Bot rules go through an evolution process that runs every night.
- Verified search crawlers. Google, Bing, Yandex, Apple, Baidu and DuckDuckGo crawlers are verified by forward-confirmed reverse DNS and handled separately.
Real browsers usually pass in a few seconds. Clients that cannot run JavaScript or solve the puzzle are blocked.
Honest limits. We found bypasses in internal bot test matrices, so we do not claim 100% blocking. Against the time-lock, ASIC or FPGA hardware could in theory be faster. The risk model's weights are hand-set starting values. Treat bot protection as a companion to the WAF and rate limits. For the mode that switches on during an attack, see the Under Attack guide.
Which method should you choose?
It depends on your audience and risk:
- Public content site: background risk scoring, a light PoW when suspicion rises.
- Login and sign-up forms: PoW plus a rate limit, and multi-factor authentication for sensitive actions.
- APIs: no puzzles; use tokens and rate limits.
- Limited-stock sales: strong verification at the purchase step and a per-session limit.
In every case, measure: the blocked share, the time visitors take to pass, and complaints. Starting in a log-only monitoring mode lets you see false positives before you block anything.
Sources
Related product pages:Technology
Frequently asked questions
Why is image CAPTCHA no longer enough?
Image recognition models and paid human-solver services can solve these puzzles. Legitimate users lose time, and blind or low-vision users hit a barrier.
Does proof-of-work solve the bot problem on its own?
No. If an attacker runs many processors in parallel, the compute cost per request drops sharply. A time-lock puzzle makes that parallelism harder but does not remove it.
Will bot protection block search engine crawlers?
A well-designed system treats verified search crawlers separately. Verification relies on a reverse DNS lookup confirmed by a forward lookup, not on the User-Agent alone.
Does bot protection raise GDPR or KVKK issues?
Behavioral data and IP addresses can count as personal data. State what you collect, how long you keep it and your legal basis; see the KVKK guide for details. This article is not legal advice.
Do mobile apps and API clients pass this verification?
Browser-based verification runs JavaScript. Background API clients need separate paths: API tokens, rate limits and excluded paths. One rule does not cover them all.
Related guides
What Is a WAF? How a Web Application Firewall Works
A WAF (web application firewall) inspects the HTTP requests headed for your application against a set of rules and blocks attacks such as SQL injection and XSS before they reach the app.
TLS Fingerprinting (JA3, JA4): What It Proves and What It Doesn't
A TLS fingerprint is a short digest built from fields in the client's handshake message (the ClientHello).
API Security: What Rate Limiting and a WAF Do and Do Not Solve
API security covers two separate jobs: filtering bad traffic from outside and getting the application's authorization logic right.
When to Enable Under Attack Mode: Decision Guide and Side Effects
Under Attack mode asks every visitor to pass a short verification before reaching your site.