Shield · Enforcement

In-page enforcement

Shield scores every visit and recommends allow, monitor, challenge or block. With in-page enforcement switched on, the SDK acts on that recommendation the moment a risky visitor submits a sign-up, login, checkout, lead or password-reset form — on any install type: JavaScript snippet, npm, Google Tag Manager, WordPress, WooCommerce or Shopify.

Nothing changes in your snippet. The setting travels inside the responses the SDK already receives, so there is no extra request, and the decision itself is made by Shield's servers, never by rules shipped to the browser. Requires SDK 1.2.0 or later; the v1.js CDN URL always serves it.

What it is, and what it is not

Friction against bots and casual abuse — not a security boundary.

This is friction. It stops bots and casual abuse that run your page in a real browser, which is most of it. It does not stop anyone who posts to your endpoints directly, disables JavaScript, or edits the page. For the sign-ups, logins and payments that matter, confirm the session on your server with the verify endpoint, one call from your backend. It returns the same recommendation, and since SDK 1.2.0 also whether the visitor passed a Turnstile challenge.

Switch it on

Settings → Enforcement in the Shield dashboard.

Tick Enforce in the page and choose what happens for each recommendation:

Shield saysOptions
blockStop the submit and show your message (default) · Redirect to a URL · Do nothing
challengeTurnstile challenge (default when a site key is set) · Slow down · Stop · Do nothing
monitorDo nothing (default) · Slow down

allow is never touched. Then pick the forms in scope. Shield recognises sign-up, login, checkout and payment, lead and contact, and password-reset forms from their fields and button text — the same classification the Events page shows as the event name. A form Shield cannot classify is never touched.

The four actions

StopThe submit is cancelled and your message appears under the form in an element with the class findip-shield-notice, which you can style. The page's own submit handlers do not run.
Slow downThe submit is cancelled, a countdown of the configured number of seconds appears under the form, and the form is submitted once automatically when it reaches zero. Scripted sign-ups that fire many submits per second get exactly one, late.
ChallengeA Cloudflare Turnstile widget appears under the form. When the visitor completes it, the SDK sends the token to Shield, Shield verifies it with your Turnstile secret, records the pass on the session, and the form submits. The pass lasts for the rest of the session. Without a Turnstile site key this action falls back to slowing down.
RedirectAs soon as Shield's decision for the page is block, the visitor is sent to the URL you configure — typically a page that explains the situation and offers a way to contact you. The SDK never redirects from the target page itself, so it cannot loop.

Every action is recorded on the event. The Events page shows a badge such as Blocked, Slowed, Challenged or Challenge passed next to the event name, so you can see how often enforcement fires and on which forms.

Turnstile setup

Free, and loaded only when a challenge is needed.

  1. In your Cloudflare account open Turnstile and create a widget for your domain. The free plan is enough.
  2. Copy the site key and secret key into Settings → Enforcement in Shield. The site key is shown to visitors; the secret never leaves Shield.
  3. Set When Shield says challenge to Ask for a Turnstile challenge.

Shield loads Turnstile only when a challenge is actually needed, so pages that never trigger one do not load it at all. If Cloudflare's verification service cannot be reached, the challenge fails open and the submit goes through; the outcome is recorded as such.

Fail-open rules

The SDK never blocks by accident.

It leaves a submit alone when:

  • enforcement is off, or the page has not yet received Shield's response for this visit (for example a submit within the first few hundred milliseconds),
  • the recommendation is allow, or the form is not in scope,
  • the visitor already passed a challenge in this session,
  • a challenge cannot be rendered or verified.

Forms submitted from JavaScript with form.submit() do not fire a submit event and are therefore not intercepted; requestSubmit() and normal button submits are.

Combining it with your server

Turn friction into a decision no client can bypass.

Put the session ID in a hidden field and call the verify endpoint from your backend before creating the account or taking the payment:

{
  "verified": true,
  "risk_status": "available",
  "risk_score": 72,
  "recommendation": "challenge",
  "challenge_passed": true,
  "challenge_passed_at": "2026-09-08T09:12:44.000Z"
}

A backend that accepts challenge only when challenge_passed is true, and rejects block, turns the in-page friction into a decision no client can bypass.