When creating any project that’s exposed to the real world these days, it’s quite common to have to consider the impact that bots and spam will have on any form you make. There are many solutions to this, but the easiest to implement is CAPTCHA.
I started off using reCAPTCHA and hCaptcha in a lot of projects, but I found they weren’t particularly effective against the spam I was seeing in some of my forms. Most of the time, the content that would be sent through contact forms would be, ironically, adverts for captcha-solving services. I needed a good solution.
Initially, I turned to Turnstile, which, of all of the solutions right now, I find to be one of the most effective. It’s got a pretty good ecosystem, and integrations exist for just about every programming language, CMS and tool that relies on protecting some form of input from spam.
I do love Turnstile, it’s made by CloudFlare and is one of the most robust solutions out there, but it was whilst I was working on the early development of FormKid that I found a new solution. FormKid is still in development at present, but it essentially allows developers or anyone who has an HTML form to plug it into a FormKid endpoint and accept submissions. It has good spam protection, and one of the solutions to this is the use of CAPTCHA in forms. Initial plans involved using Turnstile, but one of the problems I had was that I didn’t want my users to have to register a project key in their own Turnstile account. That, for me, just adds unnecessary friction that goes against the ease of use of FormKid.
Then I found Cap. Cap is basically a proof-of-work captcha. Proof-of-work, in its simplest form, requires the visitor’s browser to perform a computational task before the form can be submitted. For most users, the experience is fairly invisible – depending on how it’s configured, users may simply tick a checkbox, or the challenge can run entirely in the background without any visible interaction.
Recent versions of Cap combine proof-of-work challenges with additional browser instrumentation checks, helping distinguish genuine browsers from automated scripts.
If it costs the spammer’s machine time and resources to solve that problem to submit the form, then, scaled up, the spammer loses out financially. This is all simplified considerably, but I’m sure you get the idea.
From the Cap website:
Imagine sending 10,000 spam messages costs $1, potentially earning $10 – a profitable venture. If Cap increases the computational cost so that sending those messages now costs $100, the spammer loses $90. This eliminates the financial incentive.
I recently migrated this blog to WordPress to take advantage of the ease of use and to allow me to take advantage of its writing features, as I do intend to write a lot more now, but whilst having a Cap instance set up, I realised that there weren’t any plugins that integrated the two – Cap and WordPress. So I made one.
The plugin allows you to enter your Cap instance URL, site key, secret key, and have any standard WordPress form (login, registration, lost password, comments) protected by Cap. It also has controls for colours so you can easily integrate it into your existing page design.
You can find more information about the plugin here, and also download it from the GitHub repo here.
If you use it and find any issues, feel free to open an issue on GitHub here.
I do plan to add more integrations, especially with popular form libraries, soon, so keep an eye on it, and you’ll see them added. I also aim to publish this in the official WordPress plugin repo shortly as well.
Finding the plugin useful?
If you found this useful, consider buying me a coffee. Every bit of support helps me keep building and writing.