Is your form protected? What a form check can see, and what it cannot

A form without protection collects spam, and a form with a protection that does nothing collects the same spam while feeling safe. The free form protection check answers the first half of that question: which bot protection does the page deliver? This article explains how to read the result and where its answer stops.

What the check does

You enter the address of a page with a form. The check reads the robots.txt of that site first; if it forbids the fetch, or cannot be read, the check stops there. Otherwise it fetches that one page, with a clear name (SilentShieldFormCheck), no cookies, at most three redirects and at most 1 MB. It then looks in the HTML for the markers of well-known providers: script addresses, element classes and field names. It knows Google reCAPTCHA, hCaptcha, Cloudflare Turnstile, Friendly Captcha and SilentShield. We keep neither the address nor the result.

The five results

• Every form carries a marker. In each form found, the HTML contains the marker of a known provider. The protection is placed in the form.
• Only some forms carry a marker. The list shows which forms are missing it.
• A provider script is loaded, but no form carries a marker. The page loads the script of a provider, yet none of its forms contains a marker. Whether, and which, form the script protects is not visible without running JavaScript.
• Nothing detected in the delivered HTML. The page has forms, but no marker and no script of a known provider.
• No form in the delivered HTML. The forms may be created by a script in the browser, which the check does not see.

What the check cannot see

The check reads the HTML your server delivers. It does not run JavaScript. That has four consequences you should keep in mind.

• A form or widget that a script creates in the browser does not exist for the check. “Nothing detected” therefore means “nothing in the delivered HTML”, never “unprotected”.
• It cannot tell whether your server verifies the answer. A widget in the form with no check on the server stops nobody.
• Protection that sits in front of the page, such as a firewall or a rate limit, leaves no trace in the HTML.
• Pages behind a login are out of reach, because the check fetches only public pages, without cookies.

A real example: our own sign-up page

When we ran the check against our own sign-up page, the first version reported two providers whose script was “loaded”. The page loads neither. The cause was the data of the page itself: a menu entry reading “Alternative to hCaptcha.” sat in an inline script, and the check took the word for a provider's code. We changed the rule so that an inline script only counts when it calls a provider (a render or execute call), and the same page now reports that nothing was detected in the delivered HTML. The lesson is the reason the check names only facts: a word on a page is not a provider.

What to do with the result

1. If a marker is present, test the other half: submit the form from outside with the answer missing or wrong, and see whether your server rejects it. A marker only shows that a widget is placed.
2. If a provider script is loaded without a marker in the form, look at how the widget is attached. Many setups add it in the browser after the page loads.
3. If nothing was detected, do not conclude that the form is open. Look at your server logs and at what actually arrives, and check whether protection runs on the server or in front of the page.
4. If you decide to replace a visible challenge, compare the options on the CAPTCHA comparison page and see what a visible challenge costs you with the conversion calculator.

The check is a first look at the delivered HTML, not an audit. Use it to find out what your page says about itself, and test the rest by submitting.