Ett effektivt spamfilter ska stoppa botar utan att tvinga riktiga kunder genom svåra bildtest eller blockera hjälpmedel. Vi jämför moderna alternativ och visar hur flera skyddslager kan minska både spam och förlorade leads.
De flesta tror att mer formulärspam kräver en hårdare CAPTCHA. I praktiken kan den hårdaste kontrollen bli ännu ett hinder för kunden som använder skärmläsare, har strikt spårningsskydd eller inte kan tolka en bildutmaning. Det bästa alternativet till reCAPTCHA är därför sällan en ensam produkt, utan ett försvar i flera lager där osäkra signaler vägs samman utan att riktiga förfrågningar försvinner.
Fel skydd kostar åt båda håll. Ett svagt filter fyller inkorgen och stjäl arbetstid, medan ett aggressivt filter kan kasta bort ett offertunderlag som aldrig går att återskapa. Målet bör inte vara att gissa vem som är kund, utan att stoppa tydligt missbruk och ge tveksamma inskick en säker reservväg.
Alternativ till reCAPTCHA: vad händer innan formuläret når er server?
Det korta svaret är att både reCAPTCHA och Cloudflare Turnstile skapar en token i besökarens webbläsare. Token följer med formuläret till er server, som i sin tur måste verifiera den hos leverantören. En kontroll som bara körs i JavaScript kan kringgås genom att en bot skickar data direkt till formulärets endpoint, alltså den serveradress som tar emot meddelandet.
Integrationen skapar samtidigt ett externt beroende. Tredjepartsskript kan blockeras, nätverket kan brytas och en token kan hinna bli ogiltig om formuläret tar tid att fylla i. Därför hade vi skapat token nära själva inskickningen, kontrollerat förväntat värdnamn och formulärflöde på servern samt kartlagt vilka externa anrop och dataflöden lösningen medför. För integritetsfrågor bör verksamheten kontrollera aktuell leverantörsdokumentation och använda IMY:s vägledning på imy.se; den här texten är inte juridisk rådgivning.
Reservvägen avgör om kontrollen blir ett skydd eller en kundfälla. Om skriptet inte laddas ska formuläret förklara vad som gick fel, behålla redan ifyllda uppgifter och erbjuda ett nytt försök eller en alternativ kontaktväg. En saknad token kan höja risknivån, men bör inte automatiskt leda till att ett fullt rimligt kundmeddelande raderas utan återkoppling.
Honeypot fungerar bäst som en tyst signal, inte som ensam spärr
Ett tomt extrafält kan fånga enkla bottar utan att besökaren behöver lösa en uppgift. Fältet ska inte vara obligatoriskt, ska ligga utanför tangentbordsordningen och ska inte presenteras för skärmläsare. Servern behöver dessutom tåla att fältet saknas helt, eftersom olika webbläsare och skyddsverktyg kan påverka vilka fält som skickas.
Fallgropen är autofyllnad. Webbläsare och lösenordshanterare kan fylla oväntade fält, särskilt om honeypotens namn liknar telefon, adress eller företag. Ett ifyllt fält bör därför höja riskpoängen eller skicka meddelandet till karantän i stället för att utlösa en osynlig radering.
Inskickningstid är användbar av samma skäl: en bot kan skicka formuläret orimligt snabbt, men det kan även en riktig användare som klistrar in en färdig text. Honeypot, tidsindikator, dubbletter och innehållsmönster blir starkare tillsammans än var för sig. Det ger ett tillgängligt CAPTCHA-alternativ där majoriteten av besökarna aldrig behöver märka att kontrollen finns.
Serverbaserad filtrering ska rangordna risk – inte gissa vem som är kund
Ett bra serverfilter börjar med sådant som går att förklara: validering av fält, dubblettidentifiering, rimlig trafikbegränsning och verifiering av eventuella CAPTCHA-token. Därefter kan svagare signaler vägas in, exempelvis många länkar, upprepad identisk text eller flera täta försök. Först vid förhöjd risk behöver en interaktiv kontroll visas.
IP-adressen räcker inte som identitet. Kontor, mobiloperatörer och VPN-tjänster kan låta många riktiga besökare dela adress, så en ren IP-spärr riskerar att blockera hela grupper. Kombinera hellre adressen med formulärsession, endpoint, tidsfönster och upprepade identiska inskick. Språk, kostnadsfria e-postdomäner eller förekomsten av en länk är däremot för svaga kännetecken för att ensamma avgöra om någon är kund.
Varje beslut bör få en strukturerad orsakskod, till exempel ”ogiltig token” eller ”upprepad identisk text”. Undvik att kopiera hela kundmeddelandet till tekniska loggar; lagra i stället osäkra inskick i en skyddad granskningskö med begränsad åtkomst. Då går falska positiva träffar att återställa och reglerna kan justeras utan att värdefulla förfrågningar redan har försvunnit.
reCAPTCHA, Turnstile, honeypot eller egen riskbedömning?
Metoderna är inte helt utbytbara. reCAPTCHA och Turnstile bedömer besökaren innan er server godkänner formuläret, medan honeypot och serverbaserad riskscoring använder egna signaler. Den robustaste lösningen låter inte en enda signal fatta hela beslutet.
Google reCAPTCHA v3
reCAPTCHA v3 ger en extern riskbedömning utan att normalt visa en traditionell bildutmaning.
- Arbetar vanligtvis utan synlig kryssruta och kan ge mindre friktion än äldre CAPTCHA-varianter.
- Stöd för actions gör att kontaktformulär och andra flöden kan bedömas med olika regler.
- En låg extern poäng kan vara svår att förklara, vilket gör hårda gränsvärden riskabla.
- Lösningen lägger till Google-beroenden och kräver en plan för blockerade skript, integritet och innehållssäkerhet.
Passar: webbplatser som redan använder Googles ekosystem och behandlar poängen som en signal, inte ett automatiskt avslag.
Cloudflare Turnstile
Turnstile kan användas i osynliga eller synliga lägen och kräver inte att hela webbplatsen ligger bakom Cloudflares proxy.
- Kan ofta köras utan bildpussel och anpassas efter olika risknivåer.
- Går att integrera även när webbplatsen använder annan hosting eller infrastruktur.
- Är fortfarande en extern klientkontroll som kan påverkas av skriptblockering och nätverksfel.
- En godkänd token säger inget om huruvida meddelandets innehåll är relevant.
Passar: verksamheter som vill ha ett friktionsfritt första skydd men behålla serverregler och en fungerande reservväg.
Honeypot-fält
Honeypoten är ett dolt extrafält som enkla bottar fyller i, medan vanliga besökare lämnar det tomt.
- Kräver normalt ingen extern tjänst och har relativt låg teknisk komplexitet.
- Ger en tyst signal som kan kombineras med tid, upprepningar och avvikande formulärdata.
- Mer avancerade bottar kan identifiera eller ignorera dolda fält.
- Fel implementation kan störa tangentbord, skärmläsare eller webbläsarens autofyllnad.
Passar: som ett enkelt baslager där ett ifyllt fält höjer risken men inte ensamt kastar meddelandet.
Egen serverbaserad riskscoring
En egen riskmotor kan väga samman formulärets beteende, innehåll och resultat från Turnstile eller reCAPTCHA.
- Kan kombinera honeypot, tid, textmönster, länkar, upprepningar, frekvens och tokenresultat.
- Gör besluten observerbara genom orsakskoder och regler som kan justeras utan synlig friktion.
- Kräver löpande uppföljning när både spam och legitima kundmeddelanden förändras.
- Aggressiva regler för språk, domäner, länkar eller IP-adresser kan skapa falska positiva träffar.
Passar: verksamheter där en missad förfrågan är kostsam och osäkra ärenden kan granskas i stället för att raderas.
Använd Turnstile eller reCAPTCHA v3 som en tidig signal, komplettera med honeypot och låt servern väga samman resultatet. Leverera låg risk, skicka osäkra fall till granskning och blockera endast tydligt automatiserat missbruk.
Bygg ett spamfilter i flera lager
-
Verifiera reCAPTCHA- eller Turnstile-token på servern
Token som skapas i webbläsaren är inte ett godkännande i sig. Låt backend verifiera den mot Googles respektive Cloudflares Siteverify API med den hemliga nyckeln och kontrollera bland annat värdnamn och förväntat flöde. En saknad eller ogiltig token ska ge en orsakskod och vägas mot övriga signaler.
-
Kör kontrollen nära inskickningen – inte vid sidladdning
Skapa token när användaren interagerar med formuläret eller trycker på skicka, så att den inte hinner bli inaktuell under ett långt offertunderlag. Turnstiles explicita rendering och reCAPTCHAs programstyrda körning ger bättre kontroll över tidpunkten. Vid fel ska fokus flyttas till ett begripligt meddelande, fälten behållas och användaren kunna försöka igen.
-
Använd honeypot som risksignal, inte som automatisk dom
Lägg till ett vanligt textfält med neutralt namn, dölj det visuellt med CSS och använd
tabindex="-1"samtaria-hidden="true"för att hålla det borta från tangentbord och hjälpmedel. Backend ska acceptera att fältet saknas och väga en eventuell träff mot inskickningstid, länkar och upprepningar. -
Poängsätt beteenden och välj flera utfall
Bygg en enkel riskmodell där ogiltig token, honeypot, länkmönster, identiska texter och täta försök bidrar till helheten. Låg risk kan gå till e-post eller CRM, osäkra ärenden till en granskningskö och tydligt missbruk nekas. Akismet eller OOPSpam kan läggas till som ytterligare signal, aldrig som ensam beslutsfattare.
-
Begränsa trafik utan att blockera delade kundnätverk
Rate limiting, alltså begränsning av hur tätt anrop får komma, kan placeras i Cloudflare WAF, NGINX, Laravel Rate Limiter eller motsvarande lager. Kombinera IP med formulärtyp, sessionscookie, e-postmönster och kortlivade räknare i exempelvis Redis. Logga orsaken bakom markeringen så att spärren går att justera när den träffar fel.
Om ni söker ett alternativ till reCAPTCHA är en serververifierad Turnstile en rimlig start, men även den behöver kompletteras med en tyst honeypot och en backend som rangordnar risk. Spara osäkra inskick i en separat kö och granska återkommande felträffar innan reglerna skärps. Så här hade ett erfaret team angripit problemet: skydda först de riktiga kontaktvägarna, gör varje stopp förklarbart och låt endast tydligt missbruk möta en stängd dörr.
