Was ein Formular wirklich schützt: CAPTCHA, Honeypot, Zeitfalle, CSRF

Spam über Kontaktformulare kommt selten von einem Menschen, der von Hand tippt. Meist ist es Software, die Formulare aufspürt, jedes Feld ausfüllt und das Ergebnis abschickt – tausendfach. Dagegen gibt es mehrere Schutzmaßnahmen, und sie setzen an ganz unterschiedlichen Stellen an. Wer weiß, was jede davon wirklich leistet, vermeidet zwei Fehler: ein Formular ohne echten Schutz und ein Formular, das so streng bewacht ist, dass echte Menschen aufgeben.

Honeypot und Zeitfalle: unsichtbare Filter

Ein Honeypot ist ein zusätzliches Feld, das Menschen nie sehen, etwa ein per CSS verstecktes Feld namens „website“. Einfache Bots füllen jedes Feld aus; ist der Honeypot befüllt, deutet das auf Automatisierung hin, und der Server kann die Nachricht stillschweigend verwerfen. Bots, die eigens für Ihre Website geschrieben wurden oder die Seite wie ein Browser darstellen, überspringen ihn. Verstecken Sie ihn sauber: Ein Feld, das nur aus dem sichtbaren Bereich geschoben wurde, lesen Screenreader womöglich vor, per Tab-Taste ist es erreichbar, und Autofill befüllt es vielleicht. Nutzen Sie aria-hidden, tabindex -1 und autocomplete off, dazu eine neutrale Beschriftung, die jeden, der dort landet, bittet, das Feld leer zu lassen.

Eine Zeitfalle merkt sich, wann das Formular ausgeliefert wurde, und weist Einsendungen ab, die unplausibel schnell eintreffen. Menschen brauchen ein paar Sekunden zum Lesen und Tippen; viele Skripte senden in Sekundenbruchteilen. Der Zeitstempel muss auf dem Server geprüft und gegen Manipulation geschützt sein, etwa signiert oder in der Session gespeichert – ein einfaches verstecktes Zeitfeld überschreibt der Bot schlicht. Halten Sie die Schwelle niedrig, denn mit Autofill sind auch echte Menschen schnell. Bots, die einfach abwarten, kommen durch: Eine Zeitfalle ist ein Filter, keine Mauer.

CAPTCHA: wirksam, aber nicht umsonst

Ein CAPTCHA verlangt einen Nachweis, dass kein Bot am Werk ist – vom Bilderrätsel bis zur Prüfung im Hintergrund; verbreitet sind etwa reCAPTCHA, hCaptcha, Cloudflare Turnstile und Friendly Captcha. Es hält den Großteil generischer Automatisierung ab, deshalb ist es so beliebt. Doch jedes sichtbare Rätsel ist eine Hürde, an der manche Besucher abbrechen, und die meisten Dienste laden ein Skript eines Drittanbieters, was Fragen zu Datenschutz und Einwilligung aufwirft. Außerdem hilft ein CAPTCHA nur, wenn es richtig eingerichtet ist: Ein öffentlicher Test-Site-Key, ein Widget ohne sein Skript oder ein Token, das der Server nie prüft, sieht nach Schutz aus, ist aber keiner. Ein kostenloser Check auf formexposed.com zeigt solche Fehler von außen auf.

Zu diesen Kosten gehört die Barrierefreiheit. Bilderrätsel schließen blinde und viele sehbehinderte Menschen aus, Audio-Alternativen helfen taubblinden Menschen nicht, und knifflige Logikaufgaben belasten Menschen mit kognitiven Einschränkungen. WCAG 2.2, Erfolgskriterium 1.1.1, verlangt eine Textalternative, die den Zweck des CAPTCHAs beschreibt, sowie alternative Formen für andere Sinne. Prüfungen im Hintergrund umgehen das meiste davon – werden sie aber misstrauisch, ist der Ausweg oft wieder ein visuelles Rätsel. Testen Sie diesen Weg mit Tastatur und Screenreader.

CSRF-Token: Schutz vor Fälschung, nicht vor Spam

Ein CSRF-Token ist ein Zufallswert, den der Server ins Formular schreibt und zurückerwartet. Gedacht ist er gegen Cross-Site Request Forgery: Eine fremde Website bringt den Browser eines Besuchers dazu, eine Anfrage zu senden, die dieser nie beabsichtigt hat. Bei einem öffentlichen Kontaktformular hat er einen Nebeneffekt: Bots, die direkt an die Formularadresse senden, ohne die Seite zu laden, werden abgewiesen. Jeder Bot, der die Seite abruft und das Token mitschickt, kommt durch. Die meisten Frameworks und Formular-Plugins bringen CSRF-Tokens ohnehin mit – lassen Sie sie aktiv, aber verbuchen Sie sie nicht als Spamschutz.

Was auf dem Server passieren muss

• Prüfen Sie jedes Feld auf dem Server erneut: Pflichtfelder, Länge, E-Mail-Format und keine Zeilenumbrüche in Feldern, die in Mail-Header gelangen.
• Verifizieren Sie CAPTCHA- und Proof-of-Work-Tokens bei jeder Einsendung, beim ausstellenden Dienst oder im eigenen Code, und weisen Sie wiederverwendete Tokens ab.
• Begrenzen Sie Einsendungen pro IP-Adresse und Zeitfenster. Das stoppt Fluten aus einer Quelle; Spam, der über viele Adressen verteilt ist, erfordert andere Schichten.
• Erwägen Sie Proof-of-Work: Vor dem Absenden löst der Browser eine kleine Rechenaufgabe. Besucher sehen kein Rätsel, nichts wird getrackt, aber Massenversand wird teuer.

Sinnvoll kombinieren: zwei oder drei Schichten

1. 1Beginnen Sie mit den unsichtbaren Schichten: einem barrierefreien Honeypot und einer signierten Zeitfalle, beide serverseitig geprüft.
2. 2Ergänzen Sie ein Rate Limit pro IP-Adresse, damit eine einzelne Quelle das Formular nicht fluten kann.
3. 3Kommt weiterhin gezielter Spam durch, nehmen Sie Proof-of-Work oder ein CAPTCHA hinzu – möglichst ohne sichtbares Rätsel und mit barrierefreier Alternative.
4. 4Behalten Sie das CSRF-Token Ihres Frameworks – als Zugabe, nicht als Verteidigung.
5. 5Testen Sie das Ergebnis aus Besuchersicht – nur mit Tastatur, mit Screenreader, auf dem Smartphone – und prüfen Sie, ob echte Nachrichten weiterhin ankommen.

Auf vielen Websites entfernen Honeypot, Zeitfalle und Rate Limit zusammen bereits den Großteil des generischen Spams, ohne sichtbare Hürde; ein CAPTCHA ist die Reserve, wenn das nicht reicht. Unter WordPress vereint das kostenlose formexposed-Plugin Honeypot, Zeitprüfung und Proof-of-Work und kommt ohne Google aus. Was Ihr Formular von außen zeigt – welche Schichten vorhanden sind, ob ein CAPTCHA wirksam eingerichtet ist –, sehen Sie mit einem kostenlosen Check auf formexposed.com: Domain eingeben, kein Konto nötig. Ihren Servercode sieht der Check nicht; der serverseitige Teil bleibt Ihre Aufgabe.