Vad som faktiskt skyddar ett formulär: CAPTCHA, honeypot, tidsfälla, CSRF

Spam via kontaktformulär kommer sällan från en person som skriver för hand. Oftast är det programvara som hittar formulär, fyller i varje fält och skickar resultatet – tusentals gånger. Det finns flera försvar, och de verkar på mycket olika punkter. Att veta vad vart och ett verkligen gör hjälper dig att undvika två misstag: ett formulär utan verkligt skydd, och ett formulär som är så hårt bevakat att riktiga människor ger upp.

Honeypot och tidsfälla: osynliga filter

En honeypot är ett extra fält som människor aldrig ser, till exempel ett fält som heter ”website” och som döljs med CSS. Enkla botar fyller i varje fält, så en ifylld honeypot signalerar automatisering och servern kan i tysthet kasta meddelandet. Botar som skrivits för din webbplats, eller som renderar sidan som en webbläsare, hoppar över den. Dölj den ordentligt: ett fält som bara har flyttats utanför skärmen kan läsas upp av skärmläsare, nås med tabbtangenten eller fyllas i av autofyll. Använd aria-hidden, tabindex -1 och autocomplete off, plus en neutral etikett som ber alla som hamnar där att lämna fältet tomt.

En tidsfälla registrerar när formuläret levererades och avvisar inskick som kommer orimligt snabbt. Människor behöver några sekunder för att läsa och skriva; många skript skickar inom en bråkdel av en sekund. Tidsstämpeln måste kontrolleras på servern och skyddas mot manipulation, till exempel signerad eller sparad i sessionen – ett enkelt dolt tidsfält skriver boten helt enkelt om. Håll tröskeln låg, eftersom autofyll gör även riktiga människor snabba. Botar som helt enkelt väntar kommer igenom: en tidsfälla är ett filter, inte en mur.

CAPTCHA: verkningsfullt, men inte gratis

En CAPTCHA kräver bevis på att ingen bot är i farten – från bildpussel till kontroller som körs i bakgrunden; vanliga tjänster är reCAPTCHA, hCaptcha, Cloudflare Turnstile och Friendly Captcha. Den stoppar den mesta generiska automatiseringen, och därför är den så populär. Men varje synligt pussel är ett hinder där vissa besökare ger upp, och de flesta tjänster laddar ett skript från tredje part, vilket väcker frågor om integritet och samtycke. En CAPTCHA hjälper dessutom bara om den är korrekt konfigurerad: en offentlig webbplatsnyckel för test, en widget utan sitt skript eller en token som servern aldrig verifierar ser ut som skydd men är det inte. En gratisgranskning på formexposed.com pekar ut sådana fel utifrån.

Tillgänglighet är en del av den kostnaden. Bildpussel stänger ute blinda och många personer med nedsatt syn, ljudalternativ hjälper inte dövblinda, och kluriga logikuppgifter belastar personer med kognitiva funktionsnedsättningar. Framgångskriterium 1.1.1 i WCAG 2.2 kräver ett textalternativ som beskriver CAPTCHA:ns syfte och alternativa former för olika sinnen. Bakgrundskontroller undviker det mesta av detta, men när de blir misstänksamma är reservlösningen ofta ett visuellt pussel igen – testa den vägen med tangentbord och skärmläsare.

CSRF-token: skydd mot förfalskning, inte mot spam

En CSRF-token är ett slumpmässigt värde som servern lägger in i formuläret och förväntar sig att få tillbaka. Den utformades mot förfalskning av förfrågningar mellan webbplatser (cross-site request forgery), där en annan webbplats får en besökares webbläsare att skicka en förfrågan som besökaren aldrig avsåg. På ett offentligt kontaktformulär har den en bieffekt: botar som skickar direkt till formuläradressen utan att ladda sidan avvisas. Varje bot som hämtar sidan och skickar tillbaka token kommer igenom. De flesta ramverk och formulärplugin inkluderar CSRF-token ändå – låt dem vara på, men räkna dem inte som spamskydd.

Vad som måste ske på servern

• Validera varje fält på nytt på servern: obligatoriska fält, längd, e-postformat och inga radbrytningar i fält som hamnar i e-posthuvuden.
• Verifiera CAPTCHA- och proof-of-work-token vid varje inskick, hos den utfärdande tjänsten eller i din egen kod, och avvisa token som återanvänds.
• Begränsa inskick per IP-adress och tidsfönster. Det stoppar flöden från en källa; spam som är fördelad över många adresser kräver andra lager.
• Överväg proof-of-work: före inskicket löser webbläsaren en liten beräkningsuppgift. Besökarna ser inget pussel och ingenting spåras, men massinskick blir dyrt.

En vettig kombination: två eller tre lager

1. 1Börja med de osynliga lagren: en tillgänglig honeypot och en signerad tidsfälla, båda kontrollerade på servern.
2. 2Lägg till en hastighetsbegränsning per IP-adress så att en enskild källa inte kan översvämma formuläret.
3. 3Om riktad spam ändå kommer igenom, lägg till proof-of-work eller en CAPTCHA – helst en utan synligt pussel och med ett tillgängligt alternativ.
4. 4Behåll den CSRF-token som ditt ramverk tillhandahåller – som en bonus, inte som ett försvar.
5. 5Testa resultatet som besökare – bara med tangentbord, med skärmläsare, på en mobil – och kontrollera att riktiga meddelanden fortfarande kommer fram.

På många webbplatser tar honeypot, tidsfälla och hastighetsbegränsning tillsammans redan bort det mesta av den generiska spammen utan något synligt hinder; en CAPTCHA är reserven för när det inte räcker. På WordPress kombinerar det kostnadsfria formexposed-pluginet honeypot, tidskontroll och proof-of-work utan att behöva Google. För att se vad ditt formulär visar utåt – vilka lager som finns, om en CAPTCHA är verkningsfullt konfigurerad – behöver en gratisgranskning på formexposed.com bara en domän, inget konto. Den kan inte se din serverkod, så delen på serversidan förblir ditt ansvar.