Attraktive Alternative zu reCAPTCHA: Honeypot Erweiterung

Wer eigene Formulare ohne teure Premium-Plugins betreibt, kennt das Phänomen: Kaum ist die Seite live, füllt sich das Postfach mit Spam. Lange Zeit galt der Honeypot als die beste Lösung – unsichtbar für Menschen, effektiv gegen Bots und datenschutzfreundlich. Doch die Bots haben dazugelernt.

In diesem Beitrag teilen wir unsere Erfahrungen mit einer aktuellen Honeypot-Umgehung und zeigen, welche Alternativen wir zwischen DSGVO-Konformität, User Experience (UX) und technischer Machbarkeit evaluiert haben.

Hands typing code on a laptop keyboard in a dark room, capturing the essence of late-night programming. reCAPTCHA

Die Ausgangslage: Wenn der „Honigtopf“ leer bleibt

Bisher nutzten wir eine bewährte Methode: Ein verstecktes Eingabefeld (z. B. jobtitel), das für Menschen unsichtbar ist. Bots füllen blindlings alle Felder aus. Landet dort Text, weiß unser System (via n8n): Das ist ein Bot.

Das funktionierte Monate hervorragend, bis plötzlich eine Spam-Welle durchkam. Der Grund? Moderne Bots erkennen heute gezielt Felder, die technisch „versteckt“ sind.

Das Problem mit dem Standard-CSS

Häufig wird CSS genutzt, um das Feld aus dem Sichtbereich zu schieben:

CSS
.honeypot {
    position: absolute; /* Nimmt das Feld aus dem Textfluss */
    left: -9999px;      /* Schiebt es weit aus dem Bildschirm nach links */
    visibility: hidden; /* Macht es unsichtbar */
    display: none;      /* Entfernt es komplett aus dem Layout */
}

Die Schwachstelle: Bots scannen das CSS. Wenn sie display: none oder extreme negative Werte wie -9999px sehen, wissen sie: „Hier liegt eine Falle!“ Sie lassen das Feld einfach leer und umgehen den Schutz.

Warum nicht einfach Google reCAPTCHA?

Die naheliegende Lösung wäre Googles reCAPTCHA. Doch hier stoßen wir auf zwei große Hürden:

DSGVO-Konformität: Google reCAPTCHA (insbesondere v2 und v3) ist datenschutzrechtlich problematisch. Es überträgt Nutzerdaten (IP-Adresse, Browser-Fingerprint, Google-Cookies) an US-Server, um zwischen Mensch und Bot zu unterscheiden. Ohne explizite Einwilligung im Cookie-Banner darf es eigentlich nicht geladen werden – was die Usability massiv einschränkt.
User Experience: Wer möchte heute noch Ampeln oder Hydranten auf Bildern anklicken? Es stört den Konvertierungsprozess.

Die Evaluierung: Welche Optionen bleiben?

1. Serverseitige Intelligenz mit KI (z. B. n8n & LLMs)

Da unsere Formulare über das Automatisierungstool n8n laufen, könnten wir eine KI den Inhalt prüfen lassen.

Das Problem: Bei Kontaktformularen ist das okay, aber bei Bewerbungsprozessen greift Art. 22 DSGVO. Eine rein automatisierte Entscheidung (Ablehnung einer Bewerbung durch KI) ist rechtlich hochkomplex und ohne menschliche Instanz kaum zulässig.

2. Die „Honeypot Evolution“ (Unsere Wahl)

Anstatt den Honeypot technisch zu verstecken, „täuschen“ wir den Bot inhaltlich.

Die Strategie: Wir nennen das Honeypot-Feld nicht mehr jobtitel, sondern geben ihm einen Namen, den Bots lieben – zum Beispiel email. Das echte E-Mail-Feld bekommt einen leicht kryptischen Namen wie user_mail_id.
Anpassung des CSS: Wir verzichten auf display: none, da dies ein zu klares Signal für Bots ist. Stattdessen nutzen wir nur noch die Positionierung, um es für Menschen unsichtbar zu machen, aber für den Bot-Algorithmus „erreichbar“ erscheinen zu lassen.

HTML
<div class="plo-input-group plo-honeypot">
    <label for="email">Bitte dieses Feld leer lassen:</label>
    <input name="email" id="email" type="text" value="" tabindex="-1" autocomplete="off" />
</div>

Vorteil: Bots, die gezielt nach Mail-Feldern suchen, tappen in die Falle.
Wichtig: Durch tabindex=“-1″ verhindern wir, dass echte Nutzer per Tab-Taste in das Feld springen. autocomplete=“off“ sorgt dafür, dass Browser das Feld nicht automatisch mit der echten Mailadresse des Nutzers füllen.

Die Evolution hat gereicht

Für uns war die Honeypot Evolution der Sieger. Sie ist zu 100 % DSGVO-konform, da keine Daten an Drittanbieter fließen, sie benötigt kein JavaScript und beeinträchtigt die Barrierefreiheit nicht, sofern man sie korrekt umsetzt.

Seit der Umstellung auf die „Namens-Täuschung“ und das Entfernen von display: none ist unsere Spam-Quote wieder bei Null und verschwenden keine Zeit mehr damit unser CRM manuell zu reinigen.

Haben Sie ähnliche Probleme mit Spam in Ihren n8n-Workflows oder Webformularen? Gerne unterstützen wir Sie dabei, eine rechtssichere und technisch saubere Lösung zu implementieren.

Hier wartet Ihre Lösung

Jetzt kostenloses Beratungsgespräch buchen:

Termin vereinbaren!