Formular-Spam ist ein technisches Problem mit einer Conversion-Nebenwirkung. Jede zusätzliche Hürde, die ein Mensch überwinden muss, kostet Abschlüsse. Deshalb gilt die Reihenfolge: erst alles, was unsichtbar wirkt — und erst dann etwas, das der Besucher merkt.
Stufe 1: Honeypot
Ein zusätzliches Eingabefeld, das per CSS ausgeblendet und mit autocomplete="off" sowie tabindex="-1" versehen ist. Menschen sehen es nicht und füllen es nicht aus. Einfache Bots füllen jedes gefundene Feld. Ist das Feld befüllt, wird die Absendung verworfen.
Wichtig ist die Umsetzung: Das Feld wird nicht mit display:none im Formular-Markup als offensichtliche Falle benannt, sondern trägt einen plausiblen Namen wie „website“ oder „firma2“. Und es wird serverseitig geprüft, nicht im Browser — clientseitige Prüfungen kann ein Bot überspringen.
Der wichtigste Grundsatz: Jede Prüfung, die im Browser stattfindet, ist eine Bequemlichkeitsfunktion, keine Sicherheitsmaßnahme. Bots senden ihre Anfragen in aller Regel direkt an die Verarbeitungs-URL und führen kein JavaScript aus. Was zählt, passiert auf dem Server.
Stufe 2: Zeitmessung
Ein verstecktes Feld mit dem Zeitstempel des Seitenaufrufs. Wird das Formular in weniger als zwei bis drei Sekunden abgeschickt, war kein Mensch am Werk. Sinnvoll ist zusätzlich eine Obergrenze — ein Formular, das nach zwölf Stunden abgesendet wird, stammt meist aus einer automatisierten Wiederholung.
Der Zeitstempel gehört signiert oder serverseitig gespeichert, sonst kann er manipuliert werden. Ein einfacher Hash mit einem serverseitigen Geheimnis genügt.
Stufe 3: Inhaltliche Prüfung
- Links im Nachrichtenfeld: Mehrere URLs in einer Erstanfrage sind ein starkes Signal. Statt zu verwerfen, kann die Anfrage markiert werden.
- Feldlogik: Ein Name mit kyrillischen Zeichen bei rein deutschsprachigem Angebot, ein Telefonfeld voller Buchstaben, eine Nachricht ohne einen einzigen Leerzeichen-getrennten Satz.
- Pflichtfelder serverseitig prüfen: Klingt selbstverständlich, fehlt aber häufig — die Prüfung existiert nur im Browser.
- Feldlängen begrenzen: Verhindert nebenbei überlange Einträge in Datenbank und Benachrichtigungs-E-Mail.
Stufe 4: Rate-Limit und Herkunft
Eine Begrenzung pro IP-Adresse und Zeitfenster fängt den Großteil automatisierter Wellen ab. Sinnvoll sind gestaffelte Grenzen: wenige Absendungen pro Minute, etwas mehr pro Stunde. Dazu eine Prüfung, ob die Anfrage überhaupt von der eigenen Domain kommt — ein Abgleich der Herkunftsangaben und ein serverseitig erzeugtes, einmaliges Formular-Token.
Das Token schützt gleichzeitig gegen fremdinitiierte Absendungen und ist damit ohnehin gute Praxis.
Erst zum Schluss: Captcha
Wenn alle vorherigen Stufen aktiv sind und trotzdem Spam durchkommt, ist ein Captcha berechtigt — dann aber möglichst als unauffällige Variante, die nur bei Verdacht eine Interaktion verlangt. Zwei Punkte sind dabei zu beachten: Barrierefreiheit, weil bildbasierte Aufgaben Nutzer ausschließen, und Datenschutz, weil externe Dienste Daten des Besuchers übertragen und damit in die Einwilligungs- und Datenschutzerklärung gehören.
Eine datensparsame Alternative ist eine einfache, inhaltliche Frage aus dem eigenen Fachgebiet. Sie ist für Menschen trivial und für generische Bots wirksam — aber nur, solange die Seite kein lohnendes Ziel für gezielte Angriffe ist.
Was man messen sollte
Vor jeder Änderung: Wie viele Absendungen kommen an, wie viele davon sind echt? Nach der Änderung dieselbe Messung. Nur so wird sichtbar, ob eine Maßnahme Spam entfernt oder Anfragen. Eine Schutzstufe, die den Spam halbiert und die echten Anfragen um zwanzig Prozent senkt, ist ein Verlustgeschäft.
Welche Felder ein Formular überhaupt braucht, behandelt der Beitrag zur Formular-Optimierung.