What Is a CAPTCHA? How Bot Challenges Work and Fail

A CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge a website uses to decide whether a request comes from a person or a program, and modern AI, cheap human solving labour and accessibility law have all eroded how much it can be trusted. CAPTCHAs still sit in front of millions of login, sign-up and checkout pages, usually as the only bot control. This guide explains how the main kinds of bot challenge work, from distorted text and image grids to invisible risk scores and privacy-preserving tokens, why each can be beaten, what accessibility rules require, and how to place challenges inside a layered defence. It also covers fake CAPTCHA pages used as malware lures. It is written for application security engineers, fraud and identity teams and product owners who choose or tune these controls. Wider bot strategy is covered in the Bot Management Guide; this page focuses on the challenge itself.

Key takeaways

A CAPTCHA raises cost, it does not prove humanity. OWASP lists CAPTCHA Defeat as automated threat OAT-009, solved by machine reading, prepared image databases and human farms. Treat a pass as one weak signal.
AI has caught up with the puzzles. W3C notes that image, logic and audio CAPTCHAs can be largely cracked by algorithms, and a 2024 academic study reported solving all reCAPTCHA v2 image challenges it tested.
Invisible checks only work with server-side verification. Token-based challenges must be verified on the server, once, within their validity window, with the expected hostname and action checked.
Accessibility is a requirement, not a preference. WCAG 2.2 SC 3.3.8 (Level AA) requires an alternative to cognitive function tests during authentication, and W3C recommends preferring non-interactive approaches.
Fake CAPTCHAs are now a malware delivery method. Users have learned to trust "verify you are human" pages, and ClickFix lures exploit that trust to make people paste and run commands.

What a CAPTCHA is and how the main types work

Every bot challenge asks the client to do something that is meant to be easy for a person, or for a genuine browser on a genuine device, and costly for automation. The types differ in what they measure and where the decision is made.

Type	How it works	What it measures	Main weakness
Text CAPTCHA	User types distorted characters from an image	Ability to read distorted text	OCR and machine learning; harder for humans than for machines
Audio CAPTCHA	User transcribes spoken characters	Ability to hear and transcribe	Speech recognition; W3C cites a 90% success rate against Google's audio reCAPTCHA
Image selection grid	User selects tiles showing an object	Object recognition	Modern image models; human solving farms
Puzzle or logic task	Slider, rotation, arithmetic or game	Interaction and reasoning	Scripted solvers; cognitive barrier for users
Checkbox and invisible challenge	Script collects browser and interaction signals, may escalate to a puzzle	Browser environment and behaviour	Real browsers driven by automation; signal spoofing
Risk score (for example reCAPTCHA v3)	No interaction; server receives a score per action	Provider's assessment of the traffic	Threshold tuning; scores are probabilistic
Proof-of-work	Browser computes a small cryptographic puzzle	Willingness to spend compute	Cheap for well-resourced attackers; costly on low-end devices
Privacy-preserving token (Privacy Pass, Private Access Tokens)	A trusted attester vouches for the client; origin receives an unlinkable token	That an attester checked the device or client	Only as good as the attester; not universally supported

Risk scores: Google's reCAPTCHA v3 documentation describes a score from 1.0 (very likely a good interaction) to 0.0 (very likely a bot), suggests 0.5 as a starting threshold, recommends naming an action for each place it runs and verifying that action on the backend, and says tokens expire after two minutes. That documentation now points to Google Cloud for current information, so check the provider's current product pages before integrating. Server verification: Cloudflare's Turnstile documentation is blunt that the widget alone does not protect a form and that tokens can be forged: the server must call the siteverify endpoint, tokens are valid for 300 seconds, each can be validated only once, and a replay returns timeout-or-duplicate.

Why CAPTCHAs fail

Machine solving: W3C's note on the inaccessibility of CAPTCHA says image, logic and audio CAPTCHAs can be largely cracked by both complex and simple algorithms, and that making text harder for OCR makes it harder for people too. The 2024 paper Breaking reCAPTCHAv2 (Plesner, Vontobel and Wattenhofer) reported solving 100% of image challenges with object detection models, against 68 to 71% in earlier work.
Human solving: OWASP's OAT-009 definition includes human farms. Challenges are relayed to paid workers and the answer is returned to the bot, so the cost per solve, not the difficulty, is what matters.
Token relay and replay: a token earned on one page or by one client is reused elsewhere. Short validity, single use and action and hostname checks limit this, but only if the server enforces them.
Real browsers: automation frameworks drive genuine browsers on residential connections, which pass environment checks that were designed to catch simple scripts.
Missing server-side checks: the most common implementation failure. If the server accepts the form without verifying the token, the challenge is decoration.
Single point of defence: a challenge on the login form does nothing for the API the mobile app uses, or for the password reset and sign-up endpoints next to it.

Accessibility and user cost

W3C's Accessible Platform Architectures Working Group note (a Group Draft Note dated December 2021, not a W3C standard) sets out the problem: visual tests exclude people who are blind, visually impaired or dyslexic, audio tests exclude deaf and hard-of-hearing users, both tend to assume English, and repeated attempts weigh most heavily on people with anxiety or cognitive disabilities.

WCAG 2.2 turns part of this into a testable requirement. Success Criterion 3.3.8 Accessible Authentication (Minimum), Level AA, defines a cognitive function test as a task requiring the user to remember, manipulate or transcribe information, and requires an authentication method that does not depend on one unless an exception applies. The W3C Understanding document says CAPTCHAs fall under this whether they appear every time or only when triggered, that an audio CAPTCHA requiring transcription does not count as the alternative, and that object recognition tasks are excepted at AA but should still be avoided where possible. At AAA (SC 3.3.9) those exceptions do not apply. Where WCAG conformance is a legal or contractual obligation, a text or arithmetic CAPTCHA in a login flow with no alternative is a compliance finding.

Approach	WCAG 2.2 SC 3.3.8 position	W3C note view
Text transcription CAPTCHA	Cognitive function test; needs an alternative	Excludes many users and is machine-solvable
Audio transcription CAPTCHA	Cannot serve as the alternative	Barrier for deaf users and in noisy settings
Image object recognition	Excepted at AA, not at AAA; should be avoided	Machine-solvable; visual barrier
Non-interactive checks (risk signals, honeypots)	No user task	Preferred; weigh the data collection involved
Attestation tokens and WebAuthn	No cognitive task	Listed as promising alternatives

Privacy-preserving alternatives: Privacy Pass and Private Access Tokens

The IETF Privacy Pass architecture (RFC 9576, Informational, June 2024) separates four roles: the Client seeking access, the Origin that consumes tokens, the Attester that checks properties of the client, and the Issuer that issues tokens for attested clients. The client presents an unlinkable token rather than a cookie, so the origin learns that a check was passed without learning who passed it or linking it to the check. RFC 9577 defines the HTTP authentication scheme for presenting tokens and RFC 9578 the issuance protocols. RFC 9576 lists solving a CAPTCHA as one possible attestation, and W3C notes that Privacy Pass may still begin with a CAPTCHA.

Apple's Private Access Tokens apply this model with the device as the attested client. Apple says they prove a request comes from a legitimate device without disclosing the person's identity, and are meant to reduce how often CAPTCHAs are shown; iOS 16 and macOS Ventura support token type 2 using publicly verifiable RSA blind signatures. The origin sends an HTTP 401 with a WWW-Authenticate PrivateToken challenge and receives the token in the Authorization header. Apple's own advice is not to block the main page load on a token challenge and to keep the site usable for clients without support. In practice that makes tokens a way to skip the visible challenge for many users, not a complete replacement.

Where challenges fit in a layered defence

Use challenges as a step-up response to risk, not as the front door. A sensible order:

Map the flows attackers automate: login, sign-up, password reset, one-time code sending, checkout, gift card and voucher redemption, search and pricing pages. Include the APIs behind mobile apps.
Apply non-interactive controls first: per-account and per-source rate limits, breached password checks, device and session signals, and honeypot fields, as W3C suggests. These cost legitimate users nothing.
Challenge only on risk: show a visible challenge when signals cross a threshold, and prefer token-based or invisible challenges before puzzles.
Verify on the server, every time: call the provider's verification endpoint, reject reused or expired tokens, and compare hostname and action with what the page should send.
Offer accessible alternatives: at least one path with no cognitive function test, for example a passkey sign-in, an emailed link or a support route.
Pilot in monitor mode: log scores and outcomes for a few weeks before blocking, to set thresholds from your own traffic as the reCAPTCHA documentation recommends.
Keep a rollback: a feature flag that disables a challenge, or lowers its threshold, so a provider outage or false positive surge does not stop sign-ins or sales.

For logins, the strongest control is to make stolen passwords useless. In the 23andMe Breach, credential stuffing reached more than 18,000 accounts, and a day with over a million login attempts caused an outage; MFA was optional. A challenge might have slowed that attack, but phishing-resistant MFA and breached password checks would have removed its payoff. See the Password Spraying and Credential Stuffing Defence Guide and the Account Takeover Prevention Guide.

Fake CAPTCHA lures

Attackers copy the look of familiar "verify you are human" pages because users trust them. In ClickFix campaigns the fake page tells the visitor to press a key combination and paste a command to "complete verification", which runs malware with the user's own privileges (MITRE ATT&CK T1204.004 Malicious Copy and Paste). No genuine CAPTCHA ever asks a user to open a Run dialog, a terminal or PowerShell, and awareness training should state exactly that. Technical controls, detection and incident lessons are covered in the ClickFix and Fake CAPTCHA Paste-and-Run Attacks Guide; the information-stealer payloads often delivered this way are covered in the Lumma Stealer Guide.

Decision guidance

Situation	Reasonable choice	Trade-off
Small site, contact or comment form spam	Honeypot field, rate limits and a non-interactive challenge	Little data collection; determined spammers still get through
Consumer login under credential stuffing	Risk-based step-up challenge, breached password checks, passkeys and MFA	Needs tuning; the challenge alone will be solved at scale
Sign-up abuse and fake accounts	Challenge plus phone, email and device reputation and velocity checks	Friction at the most sensitive conversion point
High-value retail, ticketing or limited stock	Dedicated bot management with challenges as one response	Cost; see the Bot Management Buyer's Guide
Public sector or WCAG-bound service	Non-interactive checks and tokens, with no-cognitive-test alternatives	Must document the accessibility alternative
Legitimate automation and AI agents	Authenticate them instead of challenging them, for example with signed requests	Requires agent identity, not a puzzle; see the Web Bot Auth and HTTP Message Signatures for Agents guide

Third-party scripts: any hosted challenge runs the provider's script on your page and sends interaction and device data to the provider. Review it as you would any third-party script: data protection terms, content security policy, and what happens when it fails to load.

Where identity fits

Bot challenges try to tell people from programs, but much legitimate traffic is now programs acting for people: API clients, partner integrations and AI agents. Challenging them is pointless and blocking them breaks business. The durable answer is to give automated clients an identity, an API key, an OAuth client or a signed request, and to reserve challenges for anonymous traffic. See the Bot vs AI Agent Traffic Management Guide.

Detection and measurement

Challenge solve rate by flow and source: a sudden rise in solved challenges from one network or device family suggests a solver.
Time to solve: human solves vary; machine and farm solves cluster at unusually consistent times.
Verification failures: tokens rejected as invalid, expired or duplicate (for example timeout-or-duplicate), and action or hostname mismatches.
Outcome after challenge: logins that pass the challenge but fail the password at a high rate are credential stuffing, whatever the challenge said.
User cost: abandonment at the challenge step and support contacts about it, split by assistive technology where you can measure it.

Useful KPIs: share of automated attempts stopped before the challenge (by rate limits and reputation), false positive rate on known-good users, conversion loss attributable to challenges, percentage of protected flows with server-side verification confirmed by test, and number of flows with an accessible alternative.

Framework mapping

Framework	Reference	How it applies
OWASP Automated Threats	OAT-009 CAPTCHA Defeat	The threat of solving anti-automation tests
MITRE ATT&CK	T1110.004 Credential Stuffing; T1204.004 Malicious Copy and Paste	Login automation that challenges target; fake CAPTCHA lures
NIST SP 800-53 Rev. 5	AC-7 Unsuccessful Logon Attempts; SC-5 Denial-of-service Protection; SI-4 System Monitoring	Rate limiting, abuse resilience and monitoring of automated traffic
NIST CSF 2.0	PR.PS-04; DE.CM-01	Logging and monitoring of network services for automated abuse
W3C WCAG 2.2	SC 3.3.8 (AA); SC 3.3.9 (AAA)	Accessible authentication requirements for challenges
CIS Controls v8.1	Control 16 Application Software Security	Building abuse resistance into web applications

Common failure patterns

Client-side only: the widget is on the page but the server never verifies the token, or accepts any token, so bots skip the challenge entirely.
One threshold for every flow: the same score cut-off on a newsletter form and a password reset, rather than per-action thresholds tuned from monitored traffic.
Challenging the wrong endpoint: the web login is protected, but the mobile API, the password reset and the one-time code sender are not.
No accessible path: a text or arithmetic CAPTCHA is the only way to sign in, failing WCAG 2.2 SC 3.3.8 and locking out real customers.
Trusting a pass: treating a solved challenge as proof of a human and waiving other checks, when solving services sell passes cheaply.
Training users to obey challenges: security awareness that never mentions fake CAPTCHA pages leaves users ready to follow paste-and-run instructions.

Practitioner checklist

Inventory every flow and API that is automated by attackers and record which control protects each.
Confirm by test that every challenge token is verified server-side, once, within its validity window, with hostname and action checked.
Put rate limits, breached password checks and reputation signals in front of challenges.
Show visible challenges only on risk, and prefer token-based or invisible challenges.
Provide an authentication path with no cognitive function test to meet WCAG 2.2 SC 3.3.8.
Run new challenges in monitor mode first and keep a feature flag to roll back.
Monitor solve rates, solve times and post-challenge outcomes per flow.
Give legitimate automation an identity instead of challenging it.
Tell users that a real CAPTCHA never asks them to paste or run a command.

CAPTCHA and bot challenges: how they work and where they fail