Kontaktformulär är en vanlig väg in för automatiserad spam. Ett modernt skydd bör därför inte bygga på en enda kontroll i webbläsaren. Cloudflare Turnstile är ett exempel på ett verktyg som kan lägga till en botkontroll utan att användaren normalt behöver lösa en traditionell bild-captcha, men den viktiga säkerhetsdelen sker på servern.

Cloudflare är tydliga med att server-side validation via Siteverify är obligatorisk. Widgeten i webbläsaren genererar en token, men formulärets backend måste sedan skicka token till Cloudflares verifierings-API och endast acceptera formuläret när verifieringen lyckas. Källa: Cloudflare Turnstile – server-side validation.

Varför räcker inte widgeten i frontend?

En angripare behöver inte använda din formulärsida. En bot kan försöka skicka en egen HTTP-begäran direkt till formulärets endpoint. Om servern bara kontrollerar att ett fält finns, eller helt litar på JavaScript i webbläsaren, kan kontrollen kringgås.

Cloudflare anger att tokens kan förfalskas om de inte verifieras på serversidan. Därför ska backend behandla Turnstile-token som en uppgift som måste kontrolleras, inte som ett bevis i sig.

Det grundläggande flödet

Ett säkert grundflöde kan beskrivas i fem steg. Först renderas Turnstile på formulärsidan. När besökaren passerar kontrollen skapas en token. När formuläret skickas följer token med till din server. Servern anropar Siteverify med sin hemliga nyckel och den mottagna token. Först när svaret visar en lyckad verifiering behandlar du formuläret vidare, exempelvis genom att skicka mejl eller skapa ett lead.

Den hemliga nyckeln ska aldrig ligga i klientkod eller skickas till webbläsaren. Cloudflare rekommenderar också att hostnames begränsas till domäner du faktiskt kontrollerar och att olika miljöer hålls separerade. Källa: Cloudflare Turnstile – Get started.

Tokens gäller bara i fem minuter och en gång

Turnstile-tokens är enligt Cloudflares dokumentation giltiga i 300 sekunder, alltså fem minuter. De är dessutom single-use: samma token kan inte valideras flera gånger. Om en token är för gammal eller redan använd ska servern avvisa begäran och klienten behöver få en ny token.

Det här är viktigt när du bygger långa formulär. Om en användare kan ha sidan öppen länge bör frontend kunna återställa widgeten och skapa en ny token när den gamla har gått ut.

Fail closed när verifieringen misslyckas

Om Siteverify inte svarar med godkänd verifiering bör backend inte gå vidare med formulärets normala åtgärd. Annars riskerar ett nätverksfel eller ett manipulerat anrop att bli en genväg runt skyddet. Visa i stället ett begripligt felmeddelande och låt användaren försöka igen.

Logga gärna typen av verifieringsfel och tidpunkt för felsökning, men lägg inte hemliga nycklar eller känsliga formulärdata i onödigt detaljerade loggar.

Implicit eller explicit rendering

Cloudflare stödjer både implicit rendering, där ett element med rätt klass automatiskt blir en widget när skriptet laddas, och explicit rendering där din kod själv bestämmer när och var widgeten skapas. Den explicita modellen passar ofta bättre i dynamiska formulär, SPA-appar eller när formuläret visas i en modal.

Vilken klientmodell du väljer förändrar inte grundregeln: token måste verifieras på servern via Siteverify. Källa: Cloudflare Turnstile – client-side rendering.

Lägg flera lager mot spam

Turnstile bör ses som ett lager, inte hela anti-spamstrategin. Du kan komplettera med rate limiting på endpointen, validering av fältlängder och format, ett osynligt honeypot-fält som vanliga användare aldrig fyller i och enklare regler för uppenbart missbruk. För formulär som skapar konton eller skickar känsliga förfrågningar kan det också vara rimligt att begränsa hur många försök samma session eller IP-adress får göra under en kort period.

Var försiktig med regler som automatiskt blockerar riktiga användare. Ett honeypot-fält behöver exempelvis vara korrekt dolt även för hjälpmedel, och rate limits bör sättas utifrån det faktiska trafikmönstret.

Validera även själva formulärdatan

En godkänd Turnstile-token betyder inte att namn, e-postadress, meddelande eller andra värden automatiskt är säkra. Backend ska fortfarande validera de fält som tas emot, sätta rimliga längdgränser och hantera utdata korrekt. Anti-bot och datavalidering löser olika problem.

Praktisk checklista före lansering

Kontrollera att widgetens sitekey bara används på rätt domän, att secret key endast finns på servern, att varje submit verifieras via Siteverify och att ett misslyckat svar verkligen stoppar formulärhanteringen. Testa också en utgången token, en återanvänd token och en begäran utan token. Cloudflare tillhandahåller särskilda testnycklar för utvecklingsmiljöer så att du kan testa beteendet utan att använda produktionsnycklar.

Ett bra formulärskydd gör två saker samtidigt: det höjer kostnaden för automatiserad spam och lämnar så lite friktion som möjligt för riktiga besökare. Servervalideringen är den del som gör att kontrollen faktiskt kan litas på.