English
Deutsch
PolskiThanks, AI! The classic CAPTCHA is dead – how to protect forms now
Management Summary
Form protection limits spam, automated bulk submissions and abusive website operations. Server-side checks, rate limits and risk signals work together in contact, registration, login and reservation flows. The purpose is to preserve secure, accessible service for legitimate requests. AI weakens classic image puzzles as evidence of human origin, so individual CAPTCHA checks cannot replace controls over the underlying operation.
Contents
- What the research actually demonstrates
- A valid attempt is not necessarily a legitimate operation
- The first boundary belongs on the server
- Apply limits to the actual source of harm
- Invisible checks are still signals
- Protection must preserve access
- Measure completed legitimate operations
- Related article
- Own products: Form checks and spam protection
- Frequently asked questions
- Sources
Select traffic lights, decipher distorted letters, identify bicycles: the classic CAPTCHA once served as a small entrance exam between people and machines. AI has substantially weakened that distinction. “Dead” is deliberately provocative: the target is the assumption that a solved image puzzle provides dependable proof of humanity. CAPTCHA services and modern risk assessments can still contribute to protection. A single puzzle should no longer carry the security decision.
The useful starting point is the unwanted operation. Contact forms face spam and email abuse. Registration flows face bulk account creation. Login forms protect existing accounts. The same visible challenge cannot adequately address these different objectives. Protection needs to follow the consequences of an accepted request.
What the research actually demonstrates
The 2024 paper Breaking reCAPTCHAv2 reported a 100% success rate within its experimental setup, using image classification and segmentation techniques. This demonstrates a specific weakness in visual challenges. It does not establish a universal bypass of every service, configuration or later version.
A more recent study, Robot Visions, published in September 2026, reports 92.6% success across 500 real-world reCAPTCHA sessions. Individual challenge results were 58% for Type A and 43.5% for Type B. These measurements describe different levels: a session can contain multiple challenges. Session success must not be presented as accuracy on every individual puzzle.
The phrase “Zero Cost” also needs qualification. The models ran locally without paid model APIs. Hardware, electricity and implementation effort still have costs. For defenders, the significant change is the lower barrier to automated solving.
A valid attempt is not necessarily a legitimate operation
A correctly solved puzzle establishes neither an authorised purchase nor a harmless message. Human-operated spam also exists, while some legitimate automation is welcome. The relevant distinction is permitted activity versus abuse, rather than simply manual activity versus software.
OWASP recommends layered defences. Practical protection combines request limits, suspicious-flow detection and limits on the consequences of accepted operations. An apparently ordinary connection should not unlock unlimited email delivery.
The first boundary belongs on the server
The decisive check belongs at the endpoint that stores data, sends messages or creates accounts. Disabling a browser button does not protect that endpoint. A visible verification badge without a checked server response is equally insufficient.
Cloudflare Turnstile requires server-side validation through Siteverify. Tokens remain valid for five minutes and can only be validated once. The integration also needs to check the expected hostname and, where applicable, the expected action. The protected operation should begin only after the relevant checks succeed.
Missing, expired and replayed tokens need a controlled error path. A new verification attempt should preserve completed form fields. Service outages require a deliberate policy: retry, a restricted review queue or an alternative contact route. Automatically treating unchecked messages as trusted would defeat the protection.
Apply limits to the actual source of harm
A contact form can limit requests by session, destination mailbox and time window, alongside IP-based controls. Repeated identical messages, unusually large attachments or many links can trigger additional checks. Rules must match normal activity: a legitimate detailed enquiry should not acquire a spam label merely because of length.
For registrations, initial quotas and gradual access to expensive features can constrain damage. Email confirmation demonstrates control of a mailbox, not human origin. Reservation systems need controls over accounts, bookings and unreleased capacity. These are architecture examples, not universal numerical thresholds.
IP blocking alone is especially weak against distributed attacks. Shared networks also create false-positive risks. For login protection, OWASP highlights MFA and modern passkey support in the defence against password-related attacks. Replacing an image puzzle does not replace strong authentication.
Invisible checks are still signals
reCAPTCHA v3 returns a risk score and action information. The backend must validate the response and expected action. Appropriate thresholds depend on actual traffic and the consequences of an incorrect decision. A score is neither verified identity nor proof of harmless intent.
Honeypots, completion time and browser characteristics can add useful evidence. However, autofill can produce a fast legitimate submission. A badly designed hidden field can interfere with assistive technology. An individual indicator should therefore not become an unquestionable verdict.
Proof-of-work mechanisms place computational effort on the requesting device. This can increase the cost of bulk automation without proving human origin. Slower phones, battery consumption and accessibility remain part of the evaluation. The added burden needs to justify the amount of abuse actually prevented.
Protection must preserve access
The W3C discussion of CAPTCHA accessibility describes barriers created by interactive tasks. Vision, hearing, motor abilities and cognitive load can all affect completion. An audio alternative does not automatically remove every obstacle. Keyboard operation, clear errors and an alternative contact route belong in the design.
External services also require a concrete review of data flows, contractual conditions and retention. Invisible does not mean data-free. A general privacy-compliance claim cannot replace examination of the actual integration. Technical convenience and deployment suitability are separate questions.
Measure completed legitimate operations
Useful monitoring separates spam, legitimate completions, abandoned checks and false positives. A high blocking rate alone does not establish effective protection. A high solving rate does not establish exclusively legitimate traffic either. Changes should start with limited exposure and preserve a route back to the previous configuration.
For a small contact form, the starting point can remain manageable: server-side input validation, appropriate rate limits, controlled delivery, observable failures and additional risk assessment when justified. The essential change is from a single humanity test to an operation with bounded consequences.
Related article
AI and LLM prompt injection: What it is and who can be affected
Own products: Form checks and spam protection
Disclosure: products from LW IT Solutions. formexposed.com checks publicly detectable protection features of contact forms. form.exposed provides a direct entry point to the free passive form check. No messages are submitted through the inspected form. Missing visible protection does not, however, prove that server-side controls are absent.
formconfirmed.com adds spam protection without image puzzles: browser proof of work, timing and honeypot signals, plus optional AI content analysis provide several components. Server-side token validation remains necessary for integration. The products address two stages of the workflow described here: inspecting existing protection and protecting ongoing form submissions. Rate limits and rules for the underlying operation remain important additional controls.
Frequently asked questions
Are all CAPTCHAs ineffective?
No. Challenges can still make automated abuse harder. Research undermines the assumption that classic image tasks provide reliable proof of humanity. Effectiveness depends on integration, attack conditions and additional controls.
Is an invisible CAPTCHA sufficient?
An invisible service remains one component. Server-side validation, rate limits and rules for the protected operation are still necessary. A risk score cannot replace authorisation.
Can a honeypot alone stop AI bots?
An extra field may detect simple automation. Programs adapted to a form can avoid such traps. Autofill and assistive technologies also require careful design and false-positive testing.
Which checks matter before deployment?
The endpoint must handle missing, invalid and replayed evidence correctly. Legitimate submissions using keyboards, mobile devices and ordinary completion patterns also need testing. Blocking abuse and preserving access belong in the same acceptance process.
Sources
Sources checked on 2 November 2026. The W3C publication is a Group Draft Note discussing accessibility barriers, not a legal compliance certificate. The protective workflows are editorial examples rather than an assessment of a specific product.
Related articles
