Community Magazine Evolving Joomla: User-friendly, Privacy-first, Independent Built-in-Captcha coming to Joomla Core
With the release of Joomla 5, the reCAPTCHA plugins were removed from Joomla core, for a number of good reasons. The downside was that the Joomla core was left without a captcha integrated by default, meaning that forms could only be protected against spam using third-party plugins. The good news is: that is going to change again. We’re introducing a better, native and user-friendly solution, built in Joomla’s core and not depending on third-party services.
For a CMS like Joomla, which has traditionally been well positioned in the area of security, this is a serious problem: it undermines the strong market position the CMS holds in this field. This issue was also discussed during the Joomla 8 Sprint in August 2025. The solution was clear: Joomla needs an effective captcha again.
Learning from the past
The former core captchas were based on Google’s reCAPTCHA service. At the time of its initial implementation, the service was attractive because it was hosted by Google, continuously adapted to new spam bots, and free of charge.
However, there were also numerous problems: users could not simply activate the captcha but first had to register their site with Google. As part of modernization efforts, Google gradually phased out older captcha versions and recently introduced the requirement to provide a payment method in order to use reCAPTCHA—so the hurdles for site operators kept getting higher and higher.
Even more important, however, was reCAPTCHA’s impact on the user experience: in the age of AI, spam bots are becoming better and better at solving the tasks they are given. As a result, the tasks that end users had to solve also became increasingly complex. This is a problem affecting the entire “traditional” captcha industry: the idea of using a captcha to prove that a user is actually human is increasingly turning out to be a dead end.
A new captcha solution for the Joomla core therefore needed to be independent of third-party services, so that it could be activated with just a click—and it needed to use a mechanism that does not aim to test the “humanness” of users.
Proof-of-Work Captchas
Joomla 6.1 therefore introduces a captcha based on the Proof-of-Work (POW) method: Joomla generates a math task that the visitor’s computer must solve. Generating the task and verifying the solution is very fast and requires hardly any resources, while finding the solution itself is computationally expensive and therefore takes significantly longer. To solve the captcha, visitors do not have to prove that they are human, but “only” that they are willing to invest the necessary computing power to solve the task. Automated form spamming is a business model that only works through sheer volume—if sending a single message becomes slow and computationally expensive, the business model no longer works.
For human visitors, on the other hand, the user experience is significantly better than with traditional captchas: their browser automatically solves the required computational task in the background while the user fills out the form. A pleasant advantage of this approach is that a Proof-of-Work captcha is also fully accessible.
Integration in Joomla 6.1
Joomla 6.1 adds such a Proof-of-Work captcha plugin, based on the open-source library ALTCHA. However, the captcha plugin is deliberately designed in such a way that the core could replace the current Altcha-based implementation with an alternative system if the need arises in the future. ALTCHA operates completely independent from hosted services, meaning no registration with an external provider is required, no API keys are needed, and there are no conflicts with local data protection laws.
In subsequent versions of Joomla, the Proof-of-Work implementation is planned to be complemented by a so-called rate-limiting mechanism: if multiple POW challenges are requested from a single source (or, more specifically, an IP address) within a short period of time—i.e. if a form is submitted multiple times—the complexity of the tasks to be solved will increase with each new submission. This makes it even less attractive for spammers to invest the computing time required to solve the challenges, as the necessary resources would continue to increase with every submission.
Some articles published on the Joomla Community Magazine represent the personal opinion or experience of the Author on the specific topic and might not be aligned to the official position of the Joomla Project
About the author
By accepting you will be accessing a service provided by a third-party external to https://magazine.joomla.org/
Comments 3
I see that the PHP ALTCHA library Joomla has merged in the core is already two versions out of date and has known vulnerabilities which make it ineffective against anything but the most naive bots. You can surely update the ALTCHA PHP library before 6.2 ships, but this raises a big question on its long-term maintenance.
Is the PHP ALTCHA library bound by the same b/c promise as every other dependency included in core Joomla, i.e. it can only be updated on a major release (once every two years)? If not, what is your plan for maintaining and updating this plugin considering that the PHP library is now a core dependency?
This is not flamebait. I would like an honest reply, so I can decide if it makes sense for me to continue developing my own ALTCHA plugin, or if I can deprecate it in favour of the core integration.
First of all, the vulnerable version of Altcha has already been updated in the 6.1.x branch, see the commit in question.
Regarding the long term support strategy: that's not specifically related to the Altcha librar, but a general challenge associated with 3rd party libraries. Every new package, regardless whether it's backend or frontend, could cause a challenge to the project in the future if the upstream maintainers decide to stop maintaining a package version branch before Joomla can stop supporting it. If a package version becomes unsupported but needs to be adjusted because of compatibility (i.e. issues with new PHP versions) or security reasons, we always have the possibility to start maintaining a fork until the support period of the J! version branch has ended – and that's exactly the solution that has been chosen numerous times in the past and probably would be the option of choice for the Altcha lib too.
Thank you for replying.
To be clear, I was not questioning the ability of the volunteer developers or the way dependencies are handled. I wanted to know if the plugin updates are to be handled as out-of-band updates (like com_joomlaupdate, though it's not been necessary in nearly a decade), or as regular updates within the CMS. It's the latter, and that's fine. I appreciate the clarity.