Cloudflare Precursor Moves Bot Detection from a Request to a Session
Cloudflare’s Precursor analyses behaviour across a browsing session before a sensitive action occurs. The technique may catch modern automation, but it also raises privacy, accessibility and failure-mode questions.
Cloudflare made Precursor generally available on 13 July as an optional capability for Enterprise Bot Management customers. Unlike a one-time challenge at login or checkout, Precursor collects client-side signals throughout a session and produces a behavioural assessment that can inform a later security decision.
The company describes signals such as mouse and scroll patterns, typing cadence and page visibility. It says the technology does not record the actual keys a user types. The capability can complement Turnstile and other bot controls, with a clearance token connecting the earlier assessment to a protected action.
Modern bots can pass a snapshot test
Automation now runs real browsers, executes JavaScript and can use residential networks or human-assisted solving. A single request may therefore look legitimate. Behaviour over time is harder to imitate consistently.
Session-level analysis can provide earlier evidence for account creation, scraping, credential stuffing, checkout abuse and other workflows. It may also reduce friction if trusted-looking sessions avoid an explicit challenge.
Behaviour is personal data in context
Even when raw keystrokes are not captured, timing and interaction patterns describe a person. Organisations should understand exactly which signals are collected, where processing occurs, how long data and derived scores persist, and whether the information is used for other purposes.
Before enabling the feature, involve privacy and accessibility owners. Update notices and records of processing where required, apply retention limits and document the legal basis. Assess whether users with assistive technology, motor impairments, remote desktops or unusual devices receive different outcomes.
A score needs a decision policy
Bot detection is probabilistic. Blocking every low-confidence session can exclude legitimate users; allowing every uncertain session defeats the control.
Design graduated responses:
- permit low-risk browsing with monitoring;
- rate-limit or restrict high-cost functions;
- require a stronger challenge for suspicious account actions;
- step up identity verification for sensitive changes;
- block only when multiple signals justify it;
- provide an accessible recovery path for false positives.
Measure the result by confirmed abuse prevented, customer friction and support cases—not only by the percentage of traffic labelled automated.
Test the dependency and the bypass
Precursor injects client-side code and depends on a browser completing the collection flow. Content-security policies, script blockers, slow devices and network failures may interfere. Decide how the application behaves when no score is available.
Security teams should test whether an attacker can jump directly to the protected endpoint, reuse a clearance token, split activity across sessions or manipulate the signals. Server-side authorisation, rate limits and transaction monitoring remain necessary.
Useful defence, with a broader boundary
Precursor reflects an important shift: web security is moving from isolated requests towards continuous session context. That can make abuse detection more effective, but it also expands observation of legitimate users.
The right deployment is transparent, measured and layered. Use behavioural evidence to choose proportionate controls, validate accessibility and privacy effects, and preserve server-side protections that do not depend on a browser score.
