Checkout automation controls

What we check

This check runs in the owner-requested safety test and looks for a control without testing how it enforces. We first use the bot-management and captcha fingerprints the crawl already recorded; only if there are none do we GET the checkout page once and look for a widget or header such as Turnstile, hCaptcha, reCAPTCHA, DataDome, PerimeterX, Kasada or Arkose, or a cf-mitigated / x-datadome header. A PASS confirms a control is installed, not how strictly it is tuned.

Why it matters

Checkout is where money moves, and card-testing and automated fraud concentrate there. A control in front of it is the baseline defence; without one, nothing slows automated abuse of the payment step.

How we check

PASS: a bot-management or captcha control was fingerprinted passively, or found on the checkout page (a known widget in the first 8 KB of markup, or a control header). FAIL (MEDIUM): the checkout was read and no such control was detected. SKIPPED: there was no checkout page or passive fingerprint to inspect, or the checkout could not be read. The probe sends at most one read-only GET.

How to fix it

1. Put a bot-management or challenge control in front of checkout (for example Cloudflare Turnstile, hCaptcha or DataDome).
2. Prefer an invisible or risk-based challenge so real shoppers and verified agents are not slowed.
3. Confirm the control is served on the checkout route, not only on the marketing pages.

What good looks like

The checkout page includes a challenge widget:

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<div class="cf-turnstile" data-sitekey="..."></div>

or the response carries a bot-management header such as cf-mitigated or x-datadome.

Sources

• Cloudflare Turnstile documentation
• OWASP Automated Threats to Web Applications (OAT handbook)