Hvad beskytter egentlig en formular: CAPTCHA, honeypot, tidsfælde, CSRF

Spam via kontaktformularer kommer sjældent fra en person, der taster i hånden. For det meste er det software, der finder formularer, udfylder alle felter og sender resultatet – tusindvis af gange. Der findes flere forsvar, og de virker på meget forskellige punkter. Når du ved, hvad hvert af dem reelt gør, undgår du to fejl: en formular uden reel beskyttelse og en formular, der er så tungt bevogtet, at rigtige mennesker giver op.

Honeypot og tidsfælde: usynlige filtre

En honeypot er et ekstra felt, som mennesker aldrig ser, f.eks. et felt kaldet “website”, der er skjult med CSS. Simple bots udfylder alle felter, så en udfyldt honeypot afslører automatisering, og serveren kan stille kassere beskeden. Bots, der er skrevet til netop dit site, eller som gengiver siden som en browser, springer den over. Skjul den ordentligt: Et felt, der blot er flyttet uden for skærmen, kan blive læst op af skærmlæsere, nået med Tab-tasten eller udfyldt af autoudfyld. Brug aria-hidden, tabindex -1 og autocomplete off samt en neutral etiket, der beder enhver, der havner dér, om at lade feltet være tomt.

En tidsfælde registrerer, hvornår formularen blev leveret, og afviser indsendelser, der kommer usandsynligt hurtigt. Mennesker har brug for et par sekunder til at læse og skrive; mange scripts sender inden for en brøkdel af et sekund. Tidsstemplet skal kontrolleres på serveren og beskyttes mod manipulation, f.eks. signeret eller gemt i sessionen – et almindeligt skjult tidsfelt bliver bare omskrevet af botten. Hold tærsklen lav, da autoudfyld også gør rigtige mennesker hurtige. Bots, der bare venter, slipper igennem: En tidsfælde er et filter, ikke en mur.

CAPTCHA: effektiv, men ikke gratis

En CAPTCHA beder om bevis for, at der ikke er en bot på færde – fra billedopgaver til kontroller, der kører i baggrunden; kendte tjenester er reCAPTCHA, hCaptcha, Cloudflare Turnstile og Friendly Captcha. Den stopper det meste generiske automatisering, og derfor er den så populær. Men hver synlig opgave er en forhindring, hvor nogle besøgende giver op, og de fleste tjenester indlæser et tredjepartsscript, hvilket rejser spørgsmål om privatliv og samtykke. En CAPTCHA hjælper også kun, hvis den er sat korrekt op: en offentlig test-site key, en widget uden sit script eller et token, som serveren aldrig verificerer, ligner beskyttelse, men er det ikke. En gratis kontrol på formexposed.com påpeger sådanne fejl udefra.

Tilgængelighed er en del af prisen. Billedopgaver lukker blinde og mange svagsynede ude, lydalternativer hjælper ikke døvblinde, og vanskelige logikopgaver belaster mennesker med kognitive funktionsnedsættelser. WCAG 2.2-succeskriterium 1.1.1 kræver et tekstalternativ, der beskriver CAPTCHA'ens formål, og alternative former til forskellige sanser. Kontroller i baggrunden undgår det meste af dette, men når de bliver mistænksomme, er reserveløsningen ofte igen en visuel opgave – test den vej med tastatur og skærmlæser.

CSRF-token: beskyttelse mod forfalskning, ikke mod spam

Et CSRF-token er en tilfældig værdi, som serveren lægger ind i formularen og forventer at få tilbage. Det blev designet mod cross-site request forgery, hvor et andet website får en besøgendes browser til at sende en forespørgsel, som den besøgende aldrig havde til hensigt. På en offentlig kontaktformular har det en sideeffekt: Bots, der sender direkte til formularens adresse uden at indlæse siden, afvises. Enhver bot, der henter siden og sender tokenet tilbage, slipper igennem. De fleste frameworks og formularplugins indeholder alligevel CSRF-tokens – lad dem være slået til, men regn dem ikke som spambeskyttelse.

Hvad der skal ske på serveren

• Valider alle felter igen på serveren: obligatoriske felter, længde, e-mailformat og ingen linjeskift i felter, der ender i mailheadere.
• Verificer CAPTCHA- og proof-of-work-tokens ved hver indsendelse, hos den udstedende tjeneste eller i din egen kode, og afvis tokens, der genbruges.
• Begræns indsendelser pr. IP-adresse og tidsvindue. Det stopper oversvømmelser fra én kilde; spam fordelt over mange adresser kræver andre lag.
• Overvej proof-of-work: Før afsendelse løser browseren en lille regneopgave. Besøgende ser ingen opgave, og intet spores, men masseindsendelse bliver dyr.

En fornuftig kombination: to eller tre lag

1. 1Start med de usynlige lag: en tilgængelig honeypot og en signeret tidsfælde, begge kontrolleret på serveren.
2. 2Tilføj en rate limit pr. IP-adresse, så en enkelt kilde ikke kan oversvømme formularen.
3. 3Hvis målrettet spam stadig slipper igennem, så tilføj proof-of-work eller en CAPTCHA – helst en uden synlig opgave og med et tilgængeligt alternativ.
4. 4Behold det CSRF-token, dit framework stiller til rådighed – som en bonus, ikke som et forsvar.
5. 5Test resultatet som besøgende – kun med tastatur, med skærmlæser, på en telefon – og kontroller, at rigtige beskeder stadig kommer frem.

På mange sites fjerner honeypot, tidsfælde og rate limit tilsammen allerede det meste generiske spam uden nogen synlig forhindring; en CAPTCHA er reserven, hvis det ikke er nok. På WordPress kombinerer det gratis formexposed-plugin honeypot, tidskontrol og proof-of-work uden brug af Google. For at se, hvad din formular viser udefra – hvilke lag der er til stede, om en CAPTCHA er virksomt konfigureret – kræver en gratis kontrol på formexposed.com kun et domæne, ingen konto. Den kan ikke se din serverkode, så serversiden forbliver din opgave.