CAPTCHA'en er der – men beskytter intet

Mange websiteejere tilføjer en CAPTCHA til deres kontaktformular, ser det lille badge eller afkrydsningsfelt dukke op og betragter spamproblemet som løst. Så bliver skraldet ved med at komme. Ofte er der ikke noget i vejen med selve CAPTCHA'en – den er bare ikke forbundet med noget, der kan stoppe en bot. Dette indlæg gennemgår de typiske måder, hvorpå reCAPTCHA, hCaptcha og Cloudflare Turnstile ender som pynt, og hvordan du tjekker dine egne formularer.

Hvor beskyttelsen faktisk sker

Alle tre tjenester fungerer efter samme princip. Et script i browseren kører sine kontroller og giver formularen et token – en kort streng, der siger “denne besøgende bestod”. Tokenet følger med formularindsendelsen til din server. Først dér sker den egentlige beslutning: Din server sender tokenet sammen med en hemmelig nøgle til udbyderen og får et svar tilbage – succes eller fejl, og for reCAPTCHA v3 også en score. Hvis et led i denne kæde mangler, ser widgetten stadig helt normal ud, men en bot, der sender direkte til din formularhandler, går lige igennem.

Testnøglen, der vinker alt igennem

Google, hCaptcha og Cloudflare offentliggør særlige testnøgler, så udviklere kan køre automatiserede test uden at løse opgaver. Med den tilhørende testhemmelighed lykkes verifikationen altid – det er hele deres formål. De er beregnet til lokale miljøer og staging-miljøer, men de overlever jævnligt flytningen til produktion: En udvikler indsætter dem under opbygningen, sitet går live, og ingen skifter dem ud. reCAPTCHA viser i det mindste en meddelelse i widgetten om, at den kun er til test, men med en usynlig opsætning er der næppe nogen, der kigger. Hvis både test-site key og testhemmelighed er aktive, slipper hver indsendelse igennem, uanset om den kommer fra et menneske eller en bot; hvis kun site key er en testnøgle, mislykkes verifikationen i stedet, og rigtige beskeder kan blive afvist.

Et token, som ingen kontrollerer

Den anden klassiker er en server, der aldrig spørger udbyderen. Widgetten kører, et token oprettes og indsendes, og så ignorerer formularhandleren det simpelthen. Typiske kilder er håndskrevne formularer, kopierede kodestumper, der kun dækker browsersiden, og halvfærdige plugin-indstillinger. En nær slægtning: Serveren kalder godt nok verifikationstjenesten, men kontrollerer kun, at forespørgslen gik igennem, ikke hvad svaret siger. Eller scoretærsklen for reCAPTCHA v3 er sat til 0, hvilket accepterer enhver score, tjenesten kan returnere. Nogle handlere “fejler åbent”: Hvis tokenet mangler, eller verifikationen mislykkes, accepterer de alligevel beskeden – og en bot udelader bare tokenet.

Når widgetten aldrig rigtig indlæses

Andre fejlkonfigurationer ødelægger i stedet browsersiden. Hvis site key ikke er registreret for domænet – typisk efter en flytning fra staging til produktion, et domæneskifte eller et nyt underdomæne – nægter udbyderen at udstede tokens og viser en fejl i widgetten eller i browserkonsollen. Efter et temaskifte eller en plugin-opdatering kan widget-markuppen stadig være på siden, mens det script, der bringer den til live, er væk. Et cookiesamtykkeværktøj kan have samme virkning, hvis det blokerer CAPTCHA-scriptet, indtil den besøgende giver samtykke. Hvad der så sker, afhænger af serveren: Hvis den insisterer på et gyldigt token, kan rigtige besøgende ikke længere sende beskeder, og ingen bemærker de tabte henvendelser; hvis ikke, slipper bots frit igennem.

To tilfælde mere er lette at overse. Med reCAPTCHA v3 viser badget i hjørnet kun, at scriptet er indlæst et sted på siden – måske af temaet eller et andet plugin – mens integrationen i selve formularpluginet er slået fra. Og cache-plugins kan gemme en side sammen med et token, der er indlejret i HTML'en. CAPTCHA-tokens er kun gyldige i få minutter og kan kun verificeres én gang, så et cachet token fejler for rigtige besøgende; den fristende “løsning” at slå kontrollen fra fjerner stille og roligt beskyttelsen.

Et kort selvtjek

1. 1Åbn formularsiden i et privat vindue, åbn browserens udviklerværktøjer, og se i konsollen efter fejl fra CAPTCHA-scriptet.
2. 2Kontroller, at widgetten faktisk vises – én gang før og én gang efter accept af cookiebanneret – og at formularen ikke kan sendes, mens den mangler.
3. 3Kontroller i udbyderens administrationskonsol, at site key angiver dit live-domæne (inklusive varianter som www), og at nøglerne i dit formularplugin eller din kode passer til det – ikke nøgler fra dokumentation eller en staging-opsætning.
4. 4Sørg i formularpluginets indstillinger for, at CAPTCHA-integrationen er aktiveret for netop denne formular; for reCAPTCHA v3 skal du kontrollere, at scoretærsklen er over 0.
5. 5Hvis du har adgang til koden, så find verifikationen på serveren, og kontroller, at den afviser indsendelsen, når svaret er negativt, eller tokenet mangler.
6. 6Udeluk formularsiden fra helsidecaching, eller sørg for, at tokenet oprettes på ny i browseren.
7. 7Send en rigtig testbesked, og kontroller, at den kommer frem; gentag kontrollen efter ændringer af tema, plugins eller samtykkeværktøj.

En CAPTCHA er ét lag, ikke hele beskyttelsen. Kombineret med et honeypot-felt, en tidskontrol og filtrering på serveren efterlader en fejlkonfiguration ét sted ikke formularen på vid gab. Hvis du hurtigt vil se, hvor dine formularer står, så indtast dit domæne på formexposed.com – rapporten viser, om de dele af din CAPTCHA-opsætning, der er synlige udefra, er i orden.