Das CAPTCHA ist da – und schützt nichts

Viele Website-Betreiber bauen ein CAPTCHA ins Kontaktformular ein, sehen das kleine Badge oder die Checkbox erscheinen und halten das Spam-Problem für erledigt. Dann kommt der Müll trotzdem. Oft ist das CAPTCHA selbst gar nicht das Problem – es ist nur mit nichts verbunden, was einen Bot aufhalten könnte. Dieser Beitrag zeigt die typischen Wege, auf denen reCAPTCHA, hCaptcha und Cloudflare Turnstile zur reinen Dekoration werden, und wie Sie Ihre eigenen Formulare prüfen.

Wo der Schutz tatsächlich entsteht

Alle drei Dienste funktionieren nach demselben Prinzip. Ein Skript im Browser führt seine Prüfungen durch und übergibt dem Formular ein Token – eine kurze Zeichenkette, die besagt: „Dieser Besucher hat bestanden“. Das Token wird mit dem Formular an Ihren Server geschickt. Erst dort fällt die eigentliche Entscheidung: Ihr Server sendet das Token zusammen mit einem geheimen Schlüssel an den Anbieter und erhält eine Antwort – Erfolg oder Misserfolg, bei reCAPTCHA v3 zusätzlich einen Score. Fehlt ein Glied dieser Kette, sieht das Widget trotzdem völlig normal aus, aber ein Bot, der direkt an Ihr Formular-Skript sendet, kommt ungehindert durch.

Der Testschlüssel, der alles durchwinkt

Google, hCaptcha und Cloudflare veröffentlichen spezielle Testschlüssel, damit Entwickler automatisierte Tests laufen lassen können, ohne Rätsel zu lösen. Zusammen mit dem passenden Test-Secret gelingt die Prüfung immer – genau dafür sind sie da. Gedacht sind sie für lokale Umgebungen und Staging-Systeme, aber sie überleben regelmäßig den Umzug in den Live-Betrieb: Während der Entwicklung eingefügt, geht die Seite online, und niemand tauscht sie aus. reCAPTCHA blendet im Widget immerhin einen Hinweis ein, dass es nur für Tests gedacht ist, aber bei einer unsichtbaren Einbindung schaut kaum jemand hin. Sind Test-Site-Key und Test-Secret beide aktiv, kommt jede Nachricht durch, egal ob von Mensch oder Bot; ist nur der Site Key ein Testschlüssel, scheitert stattdessen die Prüfung – und echte Nachrichten werden womöglich abgewiesen.

Ein Token, das niemand prüft

Der zweite Klassiker ist ein Server, der den Anbieter nie fragt. Das Widget läuft, ein Token wird erzeugt und mitgeschickt – und das Formular-Skript ignoriert es einfach. Typische Ursachen sind selbst geschriebene Formulare, kopierte Code-Schnipsel, die nur den Browser-Teil abdecken, und halb fertige Plugin-Einstellungen. Eng verwandt: Der Server ruft den Prüfdienst zwar auf, kontrolliert aber nur, ob die Anfrage durchging, nicht, was in der Antwort steht. Oder die Score-Schwelle für reCAPTCHA v3 steht auf 0 und akzeptiert damit jeden Wert, den der Dienst liefern kann. Manche Skripte lassen außerdem im Zweifel durch: Fehlt das Token oder schlägt die Prüfung fehl, wird die Nachricht trotzdem angenommen – und ein Bot lässt das Token einfach weg.

Wenn das Widget nie richtig lädt

Andere Fehlkonfigurationen legen stattdessen den Teil im Browser lahm. Ist der Site Key nicht für die Domain registriert – typisch nach dem Wechsel von Staging auf Live, nach einem Domainumzug oder bei einer neuen Subdomain –, stellt der Anbieter keine Tokens aus und zeigt einen Fehler im Widget oder in der Browser-Konsole. Nach einem Theme-Wechsel oder Plugin-Update kann das Markup des Widgets noch in der Seite stehen, während das Skript fehlt, das es zum Leben erweckt. Ein Cookie-Consent-Tool kann denselben Effekt haben, wenn es das CAPTCHA-Skript blockiert, bis der Besucher zustimmt. Was dann passiert, hängt vom Server ab: Verlangt er ein gültiges Token, können echte Besucher keine Nachrichten mehr senden, und niemand bemerkt die verlorenen Anfragen; verlangt er keins, kommen Bots ungehindert durch.

Zwei weitere Fälle übersieht man leicht. Bei reCAPTCHA v3 zeigt das Badge in der Ecke nur, dass das Skript irgendwo auf der Seite geladen wird – vielleicht vom Theme oder einem anderen Plugin –, während die Integration im Formular-Plugin selbst ausgeschaltet ist. Und Caching-Plugins können eine Seite samt einem im HTML eingebetteten Token zwischenspeichern. CAPTCHA-Tokens gelten nur wenige Minuten und lassen sich nur einmal prüfen, also scheitert ein gecachtes Token bei echten Besuchern; die naheliegende „Lösung“, die Prüfung abzuschalten, entfernt den Schutz still und leise.

Ein kurzer Selbsttest

1. 1Rufen Sie die Formularseite in einem privaten Fenster auf, öffnen Sie die Entwicklertools des Browsers und suchen Sie in der Konsole nach Fehlern des CAPTCHA-Skripts.
2. 2Prüfen Sie, ob das Widget tatsächlich erscheint – einmal vor und einmal nach der Zustimmung im Cookie-Banner – und ob sich das Formular ohne Widget nicht absenden lässt.
3. 3Prüfen Sie in der Verwaltungskonsole des Anbieters, dass der Site Key Ihre Live-Domain samt Varianten wie www enthält und dass die Schlüssel im Formular-Plugin oder im Code damit übereinstimmen – nicht mit Schlüsseln aus einer Dokumentation oder vom Staging-System.
4. 4Stellen Sie in den Plugin-Einstellungen sicher, dass die CAPTCHA-Integration für genau dieses Formular aktiv ist; prüfen Sie bei reCAPTCHA v3, dass die Score-Schwelle über 0 liegt.
5. 5Wenn Sie Zugriff auf den Code haben, suchen Sie die serverseitige Prüfung und stellen Sie sicher, dass sie die Nachricht ablehnt, wenn die Antwort negativ ist oder das Token fehlt.
6. 6Nehmen Sie die Formularseite vom Full-Page-Caching aus oder sorgen Sie dafür, dass das Token frisch im Browser erzeugt wird.
7. 7Senden Sie eine echte Testnachricht und prüfen Sie, ob sie ankommt; wiederholen Sie den Test nach Änderungen an Theme, Plugins oder Consent-Tool.

Ein CAPTCHA ist eine Schutzschicht, nicht der ganze Schutz. Zusammen mit einem Honeypot-Feld, einer Zeitprüfung und serverseitiger Filterung steht das Formular nicht gleich offen, wenn an einer Stelle etwas falsch eingestellt ist. Wenn Sie schnell sehen möchten, wo Ihre Formulare stehen, geben Sie Ihre Domain auf formexposed.com ein – der Bericht zeigt, ob der von außen sichtbare Teil Ihrer CAPTCHA-Einrichtung in Ordnung ist.