Er din formular beskyttet? Hvad et formulartjek kan se, og hvad det ikke kan

En formular uden beskyttelse samler spam, og en formular med en beskyttelse, der intet gør, samler den samme spam og får dig til at føle dig sikker. Det gratis formulartjek besvarer den første halvdel af spørgsmålet: Hvilken bot-beskyttelse leverer siden? Denne artikel forklarer, hvordan du læser resultatet, og hvor svaret ender.

Hvad tjekket gør

Du indtaster adressen på en side med en formular. Tjekket læser først sidens robots.txt; forbyder den hentningen, eller kan den ikke læses, stopper tjekket dér. Ellers henter det den ene side, med et tydeligt navn (SilentShieldFormCheck), uden cookies, med højst tre omdirigeringer og højst 1 MB. Derefter leder det i HTML'en efter kendetegn fra kendte udbydere: scriptadresser, elementklasser og feltnavne. Det kender Google reCAPTCHA, hCaptcha, Cloudflare Turnstile, Friendly Captcha og SilentShield. Der gemmes intet, hverken adressen eller resultatet.

De fem resultater

• Hver formular har et kendetegn. I hver fundet formular indeholder HTML'en kendetegnet for en kendt udbyder. Beskyttelsen er placeret i formularen.
• Kun nogle formularer har et kendetegn. Listen viser, hvilke der mangler det.
• Et udbyderscript indlæses, men ingen formular har et kendetegn. Siden indlæser en udbyders script, men ingen af dens formularer indeholder et kendetegn. Om og hvilken formular scriptet beskytter, kan man ikke se uden at køre JavaScript.
• Intet fundet i den leverede HTML. Siden har formularer, men hverken et kendetegn eller et script fra en kendt udbyder.
• Ingen formular i den leverede HTML. Formularerne kan først blive oprettet af et script i browseren, og det kan tjekket ikke se.

Hvad tjekket ikke kan se

Tjekket læser den HTML, din server leverer. Det kører ikke JavaScript. Det har fire følger, du bør have i baghovedet.

• En formular eller widget, som et script opretter i browseren, findes ikke for tjekket. „Intet fundet“ betyder derfor „intet i den leverede HTML“, aldrig „ubeskyttet“.
• Det kan ikke se, om din server kontrollerer svaret. En widget i formularen uden kontrol på serveren stopper ingen.
• Beskyttelse, der sidder foran siden, for eksempel en firewall eller en hastighedsgrænse, efterlader intet spor i HTML'en.
• Sider bag et login er uden for rækkevidde, fordi tjekket kun henter offentlige sider, uden cookies.

Et rigtigt eksempel: vores egen tilmeldingsside

Da vi kørte tjekket mod vores egen tilmeldingsside, meldte den første version to udbydere, hvis script blev „indlæst“. Siden indlæser ingen af dem. Årsagen lå i selve sidens data: Et menupunkt med teksten „Alternativ til hCaptcha.“ stod i et inline-script, og tjekket tog ordet for en udbyders kode. Vi ændrede reglen, så et inline-script kun tæller, når det kalder en udbyder (et render- eller execute-kald), og den samme side melder nu, at der ikke blev fundet noget i den leverede HTML. Lærdommen er grunden til, at tjekket kun nævner kendsgerninger: Et ord på en side er ikke en udbyder.

Hvad du gør med resultatet

1. Hvis der er et kendetegn, så afprøv den anden halvdel: Send formularen udefra med manglende eller forkert svar, og se, om din server afviser den. Et kendetegn viser kun, at en widget er placeret.
2. Hvis et udbyderscript indlæses uden kendetegn i formularen, så se på, hvordan widgetten tilføjes. Mange opsætninger tilføjer den først i browseren, efter at siden er indlæst.
3. Hvis intet blev fundet, så slut ikke, at formularen er åben. Se i din servers logs, og se på, hvad der faktisk kommer ind, og undersøg, om beskyttelsen kører på serveren eller foran siden.
4. Hvis du vil erstatte en synlig opgave, så sammenlign mulighederne på siden CAPTCHA-sammenligning, og se med konverteringsberegneren, hvad en synlig opgave koster.

Tjekket er et første blik på den leverede HTML, ikke en revision. Brug det til at se, hvad din side siger om sig selv, og afprøv resten ved at sende formularen.