Cybersecurity glossary
What is CAPTCHA?
Learn what CAPTCHA is, how challenge-response tests distinguish humans from bots, where attackers bypass them, and how to combine CAPTCHA with rate limits and risk-based authentication.
Definition
CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge-response control that presents a task intended to be easy for humans and difficult for automated clients, helping reduce bot-driven abuse.
Why CAPTCHA exists
Public forms are programmable interfaces. Without friction, bots can create accounts, stuff credentials, scrape content, spam comments, hoard inventory, and burn SMS or email costs at machine speed.
CAPTCHA was invented to insert a human-hard, machine-hard problem into that path. Distorted text, image selection, checkbox challenges, and later risk-based scores all pursue the same goal: raise the cost of automation without completely blocking real users.
CAPTCHA is useful. It is not a complete bot defense. Solving farms, improved computer vision, and headless browsers continuously erode any single challenge style.
How CAPTCHA works
Most modern deployments follow a token workflow rather than trusting the browser alone.
Trigger on a sensitive action
Registration, login risk, reset, posting, or checkout requests a challenge based on policy.
Present or score the user
Show a puzzle, collect behavioral signals, or both, depending on the CAPTCHA product.
Issue a short-lived token
On apparent success, the client receives a response token or assertion to send with the form.
Verify server-side
The application validates the token with the CAPTCHA provider or internal verifier before proceeding.
Enforce the decision
Allow, deny, or escalate to stronger friction such as MFA or manual review.
Tune with outcomes
Measure false blocks, solve rates, and whether abuse still succeeds after passing challenges.
If step four is missing, CAPTCHA is cosmetic. Attackers simply call the backend without a valid token.
Types of CAPTCHA and related challenges
Text and image puzzles
Classic distorted characters or object selection. Familiar, but increasingly solvable by automation and outsourced labor.
Checkbox / easy interactivity
Simple user gestures combined with browser signal collection. Convenient, with uneven strength against advanced bots.
Invisible risk scoring
Background analysis of device, behavior, and reputation that challenges only suspicious sessions.
Proof-of-work or delay
Forces clients to spend compute or time. Can deter naive scripts while affecting low-power legitimate devices.
Strengths and limits
| Aspect | Strength | Limit |
|---|---|---|
| Casual bots | Stops naive scripts that cannot solve challenges. | Dedicated attackers buy solves or emulate browsers. |
| User impact | Can be reserved for risky traffic only. | Hard puzzles hurt conversion and accessibility. |
| Implementation | Easy to add on many web forms. | Mobile apps, APIs, and alternate clients need equal coverage. |
| Security role | Raises cost as one control layer. | Does not fix weak passwords, missing authz, or logic flaws. |
Where attackers bypass CAPTCHA
Attackers may use human solving services that receive screenshots and return answers quickly. They may replay or farm valid tokens if tokens are not bound tightly to action, IP, or session. They may hit APIs that never required CAPTCHA while the website did. They may abuse authenticated sessions after one successful solve.
Another failure mode is over-trust: treating a passed CAPTCHA as proof of good intent for an entire day of high-value operations.
Practical deployment guidance
- Verify every CAPTCHA token on the server before creating accounts, authenticating, or performing costly actions.
- Apply CAPTCHA to all clients that can reach the same abuse-prone APIs, not only the marketing site forms.
- Use risk-based triggers after failed logins or anomalous behavior instead of challenging every user identically.
- Combine with rate limiting, device reputation, MFA, and business-flow limits.
- Provide accessible alternatives and measure completion rates for assistive-technology users.
- Bind tokens to the protected action and keep lifetimes short to reduce replay.
- Monitor successful abuses that occurred despite passed challenges; tune thresholds accordingly.
- Avoid leaking whether a failure was CAPTCHA, password, or account state in ways that help attackers.
CAPTCHA in an anti-abuse stack
Think of CAPTCHA as friction, not judgment. Rate limits constrain volume. Authentication and MFA protect accounts. Fraud engines evaluate outcomes. WAF and bot management classify clients. CAPTCHA adds an interactive or scored hurdle when automated risk is high.
For high-value flows such as ticket drops or limited inventory, CAPTCHA alone is rarely enough. Attackers will pay to pass it if the economic prize is larger.
The practical takeaway
CAPTCHA asks a client to prove it is likely human before the application continues. It remains a practical control against low-sophistication bots and a useful step-up challenge under risk.
It fails as a sole dependency. Verify tokens server-side, cover every client path, protect accessibility, and surround CAPTCHA with rate limits, identity controls, and outcome monitoring. The goal is higher attacker cost with minimal harm to real users—not a puzzle that false-promises “bots are solved.”
Related security terms
Brute-Force Attack
CAPTCHA is often used to raise the cost of automated password guessing.
Credential Stuffing
Large-scale login abuse that CAPTCHA alone rarely stops when solving farms are available.
Rate Limiting
A complementary control that constrains request volume with or without interactive challenges.
API Abuse
Broader misuse of application functions where bots automate valuable workflows.
Frequently asked questions
What is CAPTCHA in simple terms?
CAPTCHA is a test that tries to confirm a user is human before allowing an action such as login, signup, or form submission. It might ask someone to type distorted text, select images, or pass a risk check in the background.
Does CAPTCHA stop all bots?
No. CAPTCHA raises automation cost, but attackers use solving services, browser automation, stolen sessions, and accessibility or fallback gaps. It should be one layer in a broader anti-abuse strategy.
What is the difference between visible and invisible CAPTCHA?
Visible CAPTCHA shows an interactive challenge. Invisible or risk-based systems score behavior and device signals first, challenging users only when risk is high. Both still need server-side verification of tokens.
Can CAPTCHA hurt accessibility and conversion?
Yes. Difficult challenges frustrate legitimate users, especially people using assistive technologies. Prefer progressive friction, accessible alternatives, and challenges only on risky traffic.
Where should CAPTCHA be placed?
Common placements include account registration, login after failed attempts, password reset, comment posting, checkout, and other high-value or high-cost actions targeted by bots.
Is validating CAPTCHA in the browser enough?
No. Attackers can bypass client-only checks. The server must verify CAPTCHA tokens or risk assertions with the provider or internal validation service before performing the protected action.
What should replace CAPTCHA-only defense?
Combine bot management with rate limiting, device and IP reputation, MFA, fraud rules, WAF controls, and monitoring of successful abuse outcomes—not only failed challenges.
References
Explore authoritative guidance and frameworks related to captcha.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.