CAPTCHA for TYPO3

Why choosing a CAPTCHA is a privacy question, not a technical one

CAPTCHA sounds like a trivial decision: protect the form against bots, install an extension, done. In practice, the question is which service you embed, which consent you trigger and which conversion rate you accept. For TYPO3 there are a dozen approaches that fall into three groups: visible CAPTCHAs with a visual task, invisible behavioural analyses such as reCAPTCHA v3 and purely server-side methods without user interaction such as honeypots or rate limiting. The right choice depends less on the strength of the bots than on the regulatory starting point and the audience of the form.

Typical use cases

A B2B software vendor runs a contact form with around 300 genuine enquiries per month and around 8,000 bot submissions. The vendor already uses Google Analytics, has a consent solution in place and does not lose any legal ground by adding reCAPTCHA v3. In this case, the invisible solution is effective: bots are blocked behind the scenes, real users see nothing, the conversion rate stays stable. Consent is already handled by the existing consent banner.

A municipal administration with online forms for citizen services faces the opposite situation: Google must not be embedded, consent banners should be kept minimal, and the form has to work even without JavaScript. Here reCAPTCHA is out of the question. The combination of a honeypot plus rate limiting on the reverse proxy plus a simple arithmetic task in the form catches 95 percent of bots, requires no external resource and does not trigger any consent obligation.

A third case is an educational institution with a strongly varying user base: students, lecturers, external applicants, some with visual impairments. Here accessibility matters more than any security gain, and a purely visual CAPTCHA is problematic. The solution is an hCaptcha setup with accessibility mode enabled or an sr_freecap instance with an audio alternative, complemented by a fully accessible labelling.

Technical architecture: three categories, three integration patterns

Visible CAPTCHAs such as sr_freecap or hCaptcha work through a request response mechanism: the extension generates or fetches a task, shows it to the user, and on submission the input is validated server-side. In TYPO3, integration happens through a validator in the form framework, through a Fluid ViewHelper extension or, in Powermail, through the captcha field plug-in. The technical challenge is session synchronisation and integration with existing Fluid templates.

Invisible CAPTCHAs such as reCAPTCHA v3 compute a score between 0 and 1 that describes the probability that the request is human. The score comes in as an additional field with the form submission, and the extension decides based on a configurable threshold whether the submission is accepted or discarded. The big advantage is that the user notices nothing, the disadvantage is the unavoidable data transfer to Google.

Honeypot-based solutions work without client-side logic: an invisible input field is added to the HTML form, hidden via CSS or tabindex=-1. Humans do not fill it in, bots very often do, and every submission with a populated honeypot is discarded server-side. Combined with IP-based rate limiting and a verifiable time interval between page view and submission, this blocks the majority of simple bots without bothering a single user.

Common problems and solutions

The first problem is the choice itself: teams reflexively reach for reCAPTCHA because it is well known and free, and miss the consent obligation. A clean decision requires a short assessment: which consent infrastructure is in place? Which audience should use the form? How high is the actual bot load? Gosign runs this assessment as part of a short audit and recommends the appropriate method per form instead of forcing a one-size-fits-all solution.

The second problem is the combination of multiple protective mechanisms. Anyone running a honeypot, a CAPTCHA and rate limiting in parallel creates redundancy but also failure points: a legitimate user stumbles at one of the three steps and loses trust in the form. The pragmatic answer is to layer methods and only activate the most demanding protection on suspicious behaviour, for example showing a CAPTCHA only once the honeypot has triggered or several submissions from the same IP have arrived in a short time.

The third topic is monitoring. Teams install a protection and forget that its effectiveness drops once bots develop adapted behaviour patterns. An effective CAPTCHA setup logs spam rate and false positive rate and updates the thresholds when the numbers shift. Gosign sets up this monitoring as part of the extension integration and delivers a monthly evaluation, so that it becomes visible when a vendor switch or an adjustment is needed.

Migration and version compatibility

In TYPO3 v12 and v13, the form framework is the central integration point for CAPTCHA solutions. Extensions that still rely on the old form builder or the mailform type from the core era have to be converted to the new framework on upgrade, which usually also forces a fresh choice of CAPTCHA approach. Powermail remains a popular alternative and ships its own CAPTCHA field types, which are maintained in parallel.

Anyone migrating from reCAPTCHA to a GDPR (UK: UK GDPR)-friendly solution saves not only a consent obligation but often gains load time as well: the reCAPTCHA script is several hundred kilobytes and is loaded by every page that contains a form. A honeypot setup works without any external script. Gosign has accompanied such migrations several times and, depending on the operating model, delivers either a pure honeypot setup or a combination with a local arithmetic task that is trivial for humans and a noticeable hurdle for bots.