CAPTCHA:n finns där – men skyddar ingenting

Många webbplatsägare lägger till en CAPTCHA i sitt kontaktformulär, ser det lilla märket eller kryssrutan dyka upp och betraktar spamproblemet som löst. Sedan fortsätter skräpet att komma. Ofta är det inget fel på själva CAPTCHA:n – den är bara inte kopplad till något som skulle kunna stoppa en bot. Det här inlägget går igenom de typiska sätt på vilka reCAPTCHA, hCaptcha och Cloudflare Turnstile slutar som dekoration, och hur du kontrollerar dina egna formulär.

Var skyddet faktiskt sker

Alla tre tjänsterna fungerar enligt samma princip. Ett skript i webbläsaren kör sina kontroller och ger formuläret en token – en kort sträng som säger ”den här besökaren klarade det”. Token följer med formulärinskicket till din server. Först där fattas det verkliga beslutet: din server skickar token tillsammans med en hemlig nyckel till leverantören och får tillbaka ett svar – lyckat eller misslyckat, och för reCAPTCHA v3 även en poäng. Om någon länk i denna kedja saknas ser widgeten fortfarande helt normal ut, men en bot som skickar direkt till din formulärhanterare går rakt igenom.

Testnyckeln som släpper igenom allt

Google, hCaptcha och Cloudflare publicerar särskilda testnycklar så att utvecklare kan köra automatiserade tester utan att lösa pussel. Med den matchande testhemligheten lyckas verifieringen alltid – det är hela deras syfte. De är avsedda för lokala miljöer och staging-miljöer, men de överlever regelbundet flytten till produktion: en utvecklare klistrar in dem under bygget, webbplatsen går live och ingen byter ut dem. reCAPTCHA visar åtminstone ett meddelande i widgeten om att den bara är avsedd för test, men med en osynlig lösning är det knappt någon som tittar. Om både testnyckeln för webbplatsen och testhemligheten är aktiva går varje inskick igenom, oavsett om det kommer från en människa eller en bot; om bara webbplatsnyckeln är en testnyckel misslyckas i stället verifieringen och riktiga meddelanden kan avvisas.

En token som ingen kontrollerar

Den andra klassikern är en server som aldrig frågar leverantören. Widgeten körs, en token skapas och skickas, och sedan ignorerar formulärhanteraren den helt enkelt. Typiska källor är handskrivna formulär, kopierade kodsnuttar som bara täcker webbläsarsidan och halvfärdiga plugininställningar. En nära släkting: servern anropar visserligen verifieringstjänsten men kontrollerar bara att anropet gick igenom, inte vad svaret säger. Eller så är poängtröskeln för reCAPTCHA v3 satt till 0, vilket godtar varje poäng som tjänsten kan returnera. Vissa hanterare ”felar öppet”: om token saknas eller verifieringen misslyckas godtar de meddelandet ändå – och en bot utelämnar helt enkelt token.

När widgeten aldrig riktigt laddas

Andra felkonfigurationer förstör i stället webbläsarsidan. Om webbplatsnyckeln inte är registrerad för domänen – typiskt efter en flytt från staging till produktion, ett domänbyte eller en ny underdomän – vägrar leverantören att utfärda token och visar ett fel i widgeten eller i webbläsarkonsolen. Efter ett temabyte eller en pluginuppdatering kan widgetens markup fortfarande finnas på sidan medan skriptet som ger den liv är borta. Ett verktyg för cookiesamtycke kan ha samma effekt om det blockerar CAPTCHA-skriptet tills besökaren samtycker. Vad som händer sedan beror på servern: om den kräver en giltig token kan riktiga besökare inte längre skicka meddelanden och ingen märker de förlorade förfrågningarna; om den inte gör det passerar botar fritt.

Ytterligare två fall är lätta att missa. Med reCAPTCHA v3 visar märket i hörnet bara att skriptet är laddat någonstans på sidan – kanske av temat eller ett annat plugin – medan integrationen i själva formulärpluginet är avstängd. Och cachningsplugin kan spara en sida tillsammans med en token som är inbäddad i HTML-koden. CAPTCHA-token är bara giltiga i några minuter och kan bara verifieras en gång, så en cachad token misslyckas för riktiga besökare; den lockande ”lösningen” att stänga av kontrollen tar i tysthet bort skyddet.

En kort självkontroll

1. 1Öppna formulärsidan i ett privat fönster, öppna webbläsarens utvecklarverktyg och leta i konsolen efter fel från CAPTCHA-skriptet.
2. 2Kontrollera att widgeten faktiskt visas – en gång före och en gång efter att du har godkänt cookiebannern – och att formuläret inte kan skickas medan den saknas.
3. 3Kontrollera i leverantörens administrationskonsol att webbplatsnyckeln listar din livedomän (inklusive varianter som www), och att nycklarna i ditt formulärplugin eller din kod stämmer med den – inte nycklar från dokumentationen eller en staging-miljö.
4. 4Se i formulärpluginets inställningar till att CAPTCHA-integrationen är aktiverad för just det här formuläret; för reCAPTCHA v3, kontrollera att poängtröskeln ligger över 0.
5. 5Om du har tillgång till koden, leta upp verifieringen på serversidan och kontrollera att den avvisar inskicket när svaret är negativt eller token saknas.
6. 6Undanta formulärsidan från helsidescachning, eller se till att token skapas på nytt i webbläsaren.
7. 7Skicka ett riktigt testmeddelande och kontrollera att det kommer fram; upprepa kontrollen efter ändringar av temat, plugin eller samtyckesverktyget.

En CAPTCHA är ett lager, inte hela skyddet. I kombination med ett honeypot-fält, en tidskontroll och filtrering på serversidan lämnar en felkonfiguration på ett ställe inte formuläret vidöppet. Om du vill få en snabb bild av hur det står till med dina formulär, ange din domän på formexposed.com – rapporten visar om de delar av din CAPTCHA-konfiguration som syns utifrån är i ordning.