By Greg Nowak. Last updated 2026-08-11.
A passed CAPTCHA or Turnstile challenge is reassuring, but it is not a verdict on the visitor. Modern automation can run JavaScript, operate through a real browser and behave normally for the few seconds needed to clear a checkpoint.
The useful question comes next. What did that session actually do? Did it create one account or hundreds? Browse a handful of products or work methodically through the catalogue? Leave a genuine review or add to a coordinated publishing pattern?
Cloudflare made that distinction explicit when it launched Precursor in July 2026. Instead of judging a visitor at one moment, the system continuously evaluates client-side behavioural signals across the journey. Challenges still have a role, but as one piece of evidence rather than the final decision.
A passed challenge answers one narrow question
Turnstile evaluates browser and client-side signals around a sensitive action such as signup, login or checkout. A pass means the interaction satisfied the challenge. It does not prove that later requests are harmless, the account belongs to a trustworthy person or the transaction makes sense for the business.
That distinction matters because abuse often consists of actions that look ordinary in isolation. One new account is unremarkable. Hundreds of accounts spread across proxy addresses may be used for promotion abuse or spam. A product search is expected; systematic catalogue extraction is different. A customer review may be valuable, while coordinated review generation can distort decisions and damage reputation.
OWASP’s account-creation threat description links bulk registration to content spam, malware distribution, reputation damage and manipulation of reviews, surveys and search results. The job is not merely to make a form harder to submit. It is to stop a useful business capability from being exploited at scale.
Start with the endpoint
Controls should reflect what each endpoint lets a visitor accomplish. OWASP recommends mapping application endpoints to specific automated threats before choosing defences. A login route, search function, review form and checkout have different risks, so they should not share one blunt threshold.
| Endpoint | What to watch after the challenge | Controls worth considering |
|---|---|---|
| Signup | Account velocity across sessions, addresses and device signals | Email or phone verification, identity and device limits, honeypots |
| Login | Repeated attempts against one identity or many identities | Per-account rate limits, breached-password checks, step-up authentication |
| Search or catalogue | Systematic traversal, sustained request rates and repeated query patterns | Identity-aware quotas, behavioural signals, differentiated API access |
| Reviews or comments | Coordinated publishing, concentration among new accounts and reputation patterns | Delayed publishing, reputation checks, review queues |
| Cart or checkout | Rapid purchases, repeated payment attempts and inventory reservation | Purchase limits, queues, server-side transaction checks |
This matches the layered approach in the OWASP Bot Management and Anti-Automation Cheat Sheet: network signals at the edge, session and identity controls in the application, and account or transaction rules in the backend. A request can look acceptable at one layer and still fail a business rule at another.
Validate the token where the decision happens
Showing a challenge in the browser is only half the implementation. Before processing the protected action, the application must send the token to Turnstile’s verification service and validate the response on the server. Cloudflare’s guidance for integrating Turnstile, WAF and Bot Management treats the widget and server-side validation as two required parts of the same control.
This deserves a careful review because a visible widget can create false confidence. If the backend accepts a signup, login or checkout without successful token verification, automation may bypass the page and call the route directly. Every route that performs the protected operation needs coverage, including less obvious alternatives to the main form.
The surrounding tools contribute different evidence. The WAF works with network-level signals. Bot Management evaluates requests for signs of automation. Turnstile adds browser and client-side information. None of them replaces the application’s own authorization, velocity limits or transaction rules.
Correlate activity, but do not treat an IP address as a person
IP limits remain a useful basic control, but they are a poor identity system. Proxy pools allow one operation to rotate through many addresses. Shared networks create the opposite problem by placing many legitimate users behind the same address. An IP-only rule can therefore miss distributed abuse while inconveniencing genuine visitors.
Cloudflare’s Ephemeral IDs tutorial describes a short-lived, account-scoped signal that can help correlate high-volume activity when IP addresses change. The ID is returned during server-side Siteverify processing and can be logged alongside protected events such as signup, login or checkout. It is most useful when combined with IP reputation and behavioural evidence.
There is a limit worth making explicit: an Ephemeral ID is not guaranteed to represent one unique device. Privacy-focused browsers may expose fewer signals, which can cause legitimate users to share an identifier. Cloudflare therefore recommends conservative thresholds and using the signal to identify high-volume patterns. It should change the confidence of a decision, not become an unquestioned identity claim.
Match the response to the risk
Good bot management does not mean blocking everything unusual. Legitimate crawlers, monitoring tools, accessibility technology and privacy-hardened browsers can all behave differently from typical consumer traffic. OWASP recommends a graduated response: observe low-confidence activity, ask for stronger verification when confidence rises, restrict specific actions at higher confidence and preserve evidence for confirmed abuse.
This also helps protect conversion. A suspicious session might still browse while checkout is restricted. A new account could be created but prevented from publishing until its email is verified. A questionable review can enter moderation instead of being accepted or rejected immediately. The intervention stays tied to the possible harm.
Honeypot fields add a low-friction application signal. Rate limits become more useful when they consider several keys, including endpoint, session, authenticated identity and network attributes. No detector needs to be perfect if bypassing one control still leaves sensible limits around the underlying capability.
Roll out with evidence and a rollback path
Begin with an endpoint inventory and a baseline. Record request volumes, existing failure rates, challenge outcomes and the conversion steps the business cares about. Add structured decision logs that capture the route, request or session reference, relevant signals, applied rule and result. Keep personal data to a minimum and retain raw signals only as long as needed.
Where practical, run new rules in observation mode first. Compare their decisions with known abuse, support reports and changes in legitimate completion rates. Then tighten enforcement endpoint by endpoint, starting with rules that have clear business meaning: account velocity, verified contact details, per-identity quotas or purchase limits.
Every rule needs an owner, an explainable threshold and a rollback condition. A sophisticated rule that quietly rejects valuable customers has failed. So has an alert that nobody reviews. Monitoring needs to show both outcomes: whether abuse declined and whether legitimate journeys remained intact.
The operational question is what happened next
Precursor’s session-level model reflects a wider change in web operations. An isolated request or completed challenge tells only part of the story. The sequence of actions, interpreted in context, is what reveals intent.
For a focused engagement, Greg can map abuse risks to individual endpoints, check server-side Turnstile validation, improve session correlation without relying solely on IP addresses, and combine Turnstile with WAF rules, rate limits, honeypots and application checks. The result should be a staged, observable control system with documented thresholds and rollback paths, not simply another widget added to a form.
The bot may pass the CAPTCHA. Your application still decides what it is allowed to do next.
Related on GrN.dk
- Google’s AI Search toggle needs a test plan, not a gut decision
- If the Facts Need JavaScript, AI Search May Miss the Full Page
- Search Console Can See Social Posts—Your Reports Need a New Map
Need help with this kind of work?
Review your bot defences with Greg Get in touch with Greg.
