CAPTCHA

A CAPTCHA is a test designed to tell whether the thing on the other side of a form is a person or an automated program.

The idea is to ask for something easy for a human and awkward for a script: reading distorted text, picking the images that contain a given object, or simply behaving in a way that looks human to a scoring engine that never shows a puzzle at all.

Its purpose is not to authenticate anybody. It is to make a repetitive action expensive enough that doing it a million times stops being worthwhile.

What it is used for

Stopping bulk account creation. The classic case: a script that registers thousands of accounts to abuse a free tier, to post spam, or to sit waiting.

Slowing down credential attacks. Against credential stuffing it does not make a stolen password wrong, it makes trying millions of them slow.

Protecting anything that costs money to run. Search endpoints, sign-up mail, SMS sending, password reset. Every one of those is a way to spend the operator’s budget from outside.

Keeping forms from becoming a spam relay. Contact forms and comment boxes are automated targets, and always have been.

Where it fits, and where it does not

A CAPTCHA is a friction control. It belongs next to rate limiting, which does the same job by a different route, and it does not replace it: rate limiting works on requests that never reach a form at all, such as an API called directly.

It is worth being plain about its limits, because it is often deployed as though it were a boundary:

It can be solved. Commercial services exist that will answer challenges at scale, and modern image recognition handles many classic puzzles. Determined, well-funded automation is not stopped by it; opportunistic automation is.

It only sits where you put it. A challenge on the web form and none on the API endpoint behind it protects nothing, and that gap is one of the most common findings of its kind.

It costs real users something. Every challenge is friction on people who were going to complete the form legitimately, and it falls hardest on those using assistive technology. Accessibility is not a footnote here: a visual-only challenge locks out users who cannot see it.

A worked example

A site lets anybody register to reach gated content.

Without a challenge, a script submits the registration form continuously, filling the database with accounts that exist only to post links.

With a challenge, the same script has to solve something for every attempt. The cost per account stops being zero, and for most operators that is the end of the campaign.

The account that a determined attacker still creates is a different problem, and the control for that one is what happens after registration rather than during it.

Where this shows up in an audit

Two findings recur. The first is the challenge that guards the page and not the request: the underlying endpoint accepts a direct call with no token at all. The second is the challenge that is validated client-side, where the answer is checked in the browser and the server takes the result on trust. Both are the same mistake in different clothes, which is treating a control as a boundary because it looks like one on screen.