Filtering spam form submissions

[36degrees]

Also known as: captcha, recaptcha, honeypot, rate limiting, bot detection

What

A consistent approach to filtering out spam form submissions across GOV.UK - especially if the approach requires some interaction from the user (e.g. clicking a checkbox, performing a task)

Why

We discourage users from using traditional CAPTCHAs in the Service Manual but do not offer any alternative other than linking to some high-level concepts (rate limiting, honeypots)

Services need to be run efficiently, and dealing with spam form submissions adds an overhead to the running of a service - leading to longer response times, higher costs to the taxpayer.

This is not a trivial problem, but is the sort of thing we should be looking to solve once rather than every service team having to solve it themselves.

[heathd]

We have recently started experiencing some "Card testing" attacks on GOV.UK Pay and are considering implementing an option to activate Captcha challenges on affected payment types. We are also exploring whether we can trigger capture activation automatically based on heuristics (rather than having them active all the time).

[spikeheap]

Hi @heathd, I don't suppose you could share your experience mitigating card testing attacks, and whether you ended up using Captcha and/or other approaches?

We've not had much joy with rate limiting because the attacks we've seen originate from a large botnet, but have had more joy with form honeypots.

[querkmachine]

I'm unsure if they're publicly available anywhere, but there have been some internal show and tell presentations on how spam requests are detected and handled for the "Report a problem with this page" form that appears at the bottom of GOV.UK pages.

I'm not sure of the details, but I believe their approach was to use a honeypot to catch the simplest stuff and then use server-side analysis to flag submissions that looked suspicious. Notably, not immediately discarding them, just deleting them.

The honeypot they use looks like this:

<div class="govuk-visually-hidden" aria-hidden="true">
    <label for="giraffe">This field is for robots only. Please leave blank</label>
    <input id="giraffe" name="giraffe" type="text" pattern=".{0}" tabindex="-1" autocomplete="off">
</div>

Should also note that the draft of WCAG 2.2 includes a new Accessible Authentication criterion that would seem to forbid many kinds of CAPTCHA, such as requiring a user to transcribe distorted text, transcribe audio, or answer spacial or visual puzzles. Object recognition tests (which are probably the most common these days) are allowed, but it's still noted that these require cultural context and still may not be easy for users to complete.