Irgendwann steht man vor der immer gleichen Wahl. Google reCAPTCHA einbauen und damit jeden Formularbesucher erst einmal bei einem externen Dienst vorbeischicken. Oder hCaptcha, Cloudflare Turnstile, was gerade sonst noch so auf dem Markt herumsteht oder die Web-Agentur gerade so in der Empfehlungsschublade “Haben wir schon immer bei Kunden installiert” hat. Unterschiedliche Logos, ähnliche Idee: Ein Drittanbieter soll entscheiden, ob da ein Mensch ein Kontaktformular ausfüllt oder ein Bot mit zu viel Tagesfreizeit.
Technisch kann das funktionieren. Datenschutzrechtlich zieht man sich damit aber schnell eine kleine Karawane an Folgefragen ins Haus. Welche Daten fließen beim Laden des Formulars? Was verarbeitet der Anbieter? Ist ein Auftragsverarbeitungsvertrag erforderlich? Wie sieht es mit Drittlandtransfers aus? Muss der Dienst erst nach einer Einwilligung geladen werden? Und warum steht auf der Website jetzt ein Cookie-Banner, obwohl man eigentlich nur verhindern wollte, dass das Kontaktformular für Viagra-Angebote, SEO-Wunder und angebliche Erbschaften aus Übersee missbraucht wird?
Wir hatten darauf schon lange keine besondere Lust mehr. Kein Consent-Popup nur wegen eines CAPTCHA. Keine Datenschutzerklärung, die sich seitenlang mit einem Dienst beschäftigt, der im Kern eine recht schlichte Frage beantworten soll: Bist du ein Mensch oder ein Bot? Aber ewig ohne diesen Schutz online zu sein, ist auch zeit- und nervenaufreibend. Denn ungeschützte Formulare sind ein gefundenes Bot-Fressen. Die Antwort darauf muss aber nicht zwingend über die Infrastruktur eines großen US-Anbieters laufen. Und sie muss auch nicht bedeuten, dass Besucher erst Busse, Ampeln und Zebrastreifen sortieren dürfen, bis das Formular endlich abgeschickt werden kann. Der Dude: “Und gehört jetzt die Klingel im angrenzenden Bildbereich mit zum Fahrrad oder doch nicht?”
Der Ausweg heißt ALTCHA – und ist erfreulich unspektakulär
ALTCHA ist ein Open-Source-CAPTCHA, das einen anderen Ansatz verfolgt als die üblichen Verdächtigen. Keine Bilderrätsel, keine heimliche Auswertung von Mausbewegungen und kein externer Dienst, der beim Besuch des Formulars schon einmal technisch mit am Tisch sitzt. Stattdessen bekommt der Browser eine kleine Rechenaufgabe. Das Prinzip nennt sich Proof of Work. Wer bei dem Begriff jetzt an Mining-Farmen, Grafikkartenpreise und Leute denkt, die in der Garage Kryptowährungen schürfen: keine Sorge. Hier geht es um eine winzige Aufgabe, die ein normaler Browser im Hintergrund in kurzer Zeit löst.
Für echte Besucherinnen und Besucher fällt das praktisch nicht auf. Für Bots, die zehntausend Formulare pro Minute versenden wollen, wird die Sache dagegen deutlich teurer. Genau das ist der Zweck der Übung: Nicht beweisen, dass ein Mensch besonders menschlich aussieht, sondern automatisierte Massenanfragen unattraktiv machen. ALTCHA kann vollständig selbst betrieben werden. Der Challenge-Server stellt Aufgaben bereit und prüft die eingereichten Antworten. Es ist also kein SaaS-Dienst, bei dem man sich in das nächste Dashboard eines Drittanbieters einloggen und am Ende des Monats eine Rechnung für seine eigenen Formularaufrufe zahlen darf oder eben mit den personenbezogenen Daten seiner Webseitenbesucher dafür bezahlt.
Der entscheidende Vorteil: Die technische Verarbeitung kann auf der eigenen Infrastruktur bleiben. Keine Einbindung eines externen CAPTCHA-Anbieters, keine zusätzlichen Skripte von dort und keine Datenübermittlung nur deshalb, weil jemand eine Nachricht über ein Kontaktformular schicken möchte. Das macht die Welt nicht automatisch datenschutzfrei. Auch ein selbst betriebener Server verarbeitet Verbindungsdaten und unter Umständen IP-Adressen. Aber man weiß wenigstens, wo die Daten verarbeitet werden, wie der Dienst konfiguriert ist und wer im Zweifel zuständig ist. Das ist in der Datenschutzpraxis schon deutlich mehr wert als die übliche Antwort: „Das macht halt Google.“
Warum wir GateCHA statt der Roh-Bibliothek genommen haben
ALTCHA liefert die eigentlichen Bausteine. Das genügt, wenn man für eine einzelne Website ein CAPTCHA integrieren will und keine Scheu vor etwas eigener Entwicklungsarbeit hat. Sobald mehrere Webauftritte an einem zentralen CAPTCHA-Dienst hängen sollen, wird es aber schnell etwas weniger charmant. Dann braucht man eine saubere Trennung zwischen den einzelnen Websites, eine Schlüsselverwaltung, Schutz gegen missbräuchliche Anfragen und idealerweise einen Ort, an dem man auch in sechs Monaten noch nachvollziehen kann, was da eigentlich eingerichtet wurde. Genau dafür gibt es GateCHA.
GateCHA ist eine schlanke, unter MIT-Lizenz angebotene Serversoftware rund um das ALTCHA-Protokoll. Es bringt ein Dashboard, einen Login und – für uns entscheidend – getrennte API-Keys pro Website mit. Jede Website erhält ihren eigenen Schlüssel. Dieser Schlüssel kann auf konkrete Domains beschränkt werden. Wenn ein Projekt Probleme macht oder ein Key ausgetauscht werden muss, bleibt der Rest davon unberührt.
Dazu kommen Rate-Limits pro Key und eine adaptive Schwierigkeit. Wenn eine Quelle auffällig viele Anfragen stellt, kann GateCHA die Rechenaufgabe für diese Quelle anheben. Ein normaler Besucher merkt davon im Idealfall nichts. Ein Bot merkt es schon. Und zwar in Form von mehr Rechenaufwand, was bei automatisierter Masse genau die richtige Sprache ist.
Der praktische Vorteil für Menschen, die nicht aus jedem CAPTCHA ein Plattformprojekt machen wollen: GateCHA kommt als fertig kompilierte Binary. Kein Docker-Zirkus, keine Abhängigkeitssammlung, kein Kubernetes-Cluster für ein Kontaktformular. Herunterladen, ausführbar machen, konfigurieren, starten. Ganz fertig ist es damit natürlich nicht – irgendwas ist immer –, aber erstaunlich nah dran.
Der Server steht. Fast überall.
Unser Datenschutz Dude betreibt unsere Instanz auf einem Uberspace-Account. Dort lassen sich eigene Dienste ohne Root-Rechte im Benutzerkontext betreiben. Eine eigene Subdomain mit Zertifikat ist ebenfalls schnell davor geschaltet. Das ist aber keine Uberspace-Spezialität. Das Grundprinzip funktioniert auf praktisch jedem (kleinen) vServer oder in einer vorhandenen Serverumgebung der Haus-IT:
- GateCHA auf dem eigenen Server bereitstellen.
- Den Dienst dauerhaft über systemd, Supervisor oder eine vergleichbare Lösung betreiben.
- Einen Reverse Proxy davorschalten.
- Eine eigene Subdomain einrichten, zum Beispiel ‘captcha.eure-domain.de‘.
- Notwendige Zertifikate, z.B. Let’s Encrypt aktivieren.
- Für jede angeschlossene Website einen eigenen API-Key erstellen.
- Das GateCHA-Widget (in diesem Fall nicht das ALTCHA-Widget) im Frontend einbinden und die Lösung beim Formularversand serverseitig prüfen.
Das klingt länger, als es ist. Wer ohnehin mit Servern, SSH und Reverse Proxies arbeitet, hat den grundsätzlichen Teil an einem Nachmittag stehen. Einschließlich der unvermeidlichen Viertelstunde, in der man eine Fehlermeldung anstarrt, obwohl eigentlich nur eine Variable oder eine Domain fehlt. Zwei Einstellungen verdienen dabei besondere Aufmerksamkeit:
Erstens: ‘GATECHA_SECRET_KEY‘ sollte dauerhaft gesetzt sein und einen Neustart überleben. Fehlt der Schlüssel oder ändert er sich bei jedem Start, verliert der Dienst den zugehörigen Zustand. Das ist ungefähr so praktisch wie ein digitales Türschloss, das nach jedem Stromausfall vergisst, welche Schlüssel es kennt.
Zweitens: Läuft GateCHA hinter einem Reverse Proxy – und das wird bei einem öffentlich erreichbaren Dienst meist der Fall sein –, muss der Dienst den Proxy korrekt berücksichtigen. Andernfalls sieht GateCHA womöglich nur die IP-Adresse des Reverse Proxys. Sämtliche Besucher landen dann im selben Rate-Limit-Topf.
Das schützt zuverlässig gegen Spam. Allerdings auch gegen echte Besucher. Der Datenschutz Dude nennt das dann eine sehr konsequente Verfügbarkeitsreduktion. 🙂
Die Domain muss wirklich exakt stimmen
Im Dashboard bekommt jede Website ihren eigenen API-Key. Für diesen Key wird außerdem hinterlegt, welche Domain ihn verwenden darf. Und hier ist „exakt“ nicht als freundlicher Vorschlag gemeint. ‘eure-domain.de‘ und ‘www.eure-domain.de‘ sind zwei verschiedene Hosts. Wer per Weiterleitung konsequent auf ‘www‘ umstellt, beim GateCHA-Key aber nur die Domain ohne ‘www‘ einträgt, bekommt eine höfliche, aber eindeutige Ablehnung. Dann heißt es beispielsweise: ‘Domain not allowed‘.
Die Fehlermeldung stimmt. Die eigene erste Vermutung meistens nicht. Bevor man anfängt, JavaScript, DNS, TLS-Zertifikate oder die Mondphasen zu überprüfen, helfen drei Fragen:
- Unter welcher Domain wird das Formular tatsächlich im Browser aufgerufen?
- Gibt es eine Weiterleitung zwischen ‘www‘ und der Domain ohne ‘www‘?
- Ist genau die endgültige Ziel-Domain beim betreffenden API-Key hinterlegt?
Fragt mich, woher ich das weiß. 🙂
Das Ganze ist kein (ausschließliches) WordPress-Feature
Viele Anleitungen zu ALTCHA enden ungefähr dort, wo das WordPress-Plugin installiert wurde. Das ist verständlich. WordPress ist weit verbreitet, und fertige Integrationen sind angenehm, wenn es schnell gehen soll. Der interessante Teil beginnt aber dahinter: Der Challenge-Server spricht HTTP. Er liefert eine Challenge aus und nimmt später eine gelöste Antwort zur Prüfung entgegen. Das kann nicht nur WordPress. Das kann jedes System, das HTTP-Anfragen verarbeiten kann.
Für WordPress gibt es passende Plugins, die das Widget in Formulare, Kommentare oder Login-Seiten einhängen. Wer eine statische HTML-Seite betreibt, bindet das Frontend-Widget direkt ein. Wer ein eigenes Formular in PHP, Node.js oder einer anderen Umgebung hat, prüft die Antwort beim Abschicken auf der Serverseite. Damit wird aus einem CAPTCHA keine Plugin-Lösung für genau eine Website, sondern eine kleine eigene Infrastruktur:
- Zehn oder mehr Websites können denselben Challenge-Server nutzen.
- Jede Website bekommt ihren eigenen API-Key.
- Jede Domain bleibt getrennt konfigurierbar.
- Die Verwaltung bleibt an einer Stelle.
- Ein Wechsel des CMS zwingt nicht dazu, den Spam-Schutz gleich mit auszutauschen.
Das ist der eigentliche Charme daran. Man baut nicht noch einen weiteren Dienst in eine einzelne Website ein. Man betreibt einen überschaubaren Baustein, den verschiedene eigene Projekte nutzen können.
Datenschutzfreundlich heißt nicht: Augen zu und durch
Ein selbst gehostetes ALTCHA mit GateCHA kann datenschutzrechtlich sehr viel angenehmer sein als ein CAPTCHA, das schon beim Laden des Formulars Daten an einen großen externen Anbieter schickt. Das bedeutet insbesondere:
- Kein externer CAPTCHA-Dienst muss technisch eingebunden werden.
- Es entstehen keine zusätzlichen Datenflüsse zu diesem fremden Dienst.
- Die Infrastruktur und Konfiguration liegen in der eigenen Kontrolle.
- Logdaten, Speicherdauer und Zugriffsrechte können selbst bestimmt werden.
- Datenschutzinformationen lassen sich an die tatsächlich eingesetzte Technik anpassen, statt einen fremden Dienst möglichst tapfer unter dem Stichwort “Transparenz” zu erklären.
Aber: Selbsthosting ist kein Datenschutz-Zauberwort. Wer GateCHA auf einem gemieteten Server betreibt, sollte den Hosting-Anbieter datenschutzrechtlich einordnen und gegebenenfalls einen Auftragsverarbeitungsvertrag abschließen. Wer IP-Adressen oder Sicherheitsereignisse protokolliert, sollte festlegen, welche Daten wofür gebraucht werden und wann sie wieder gelöscht werden. Wer ein Dashboard betreibt, sollte dieses nicht mit dem Passwort ‘Sommer2026!‘ absichern, nur weil es doch „nur ein CAPTCHA“ ist.
Und natürlich gilt auch hier: Updates einspielen, Zertifikate sauber konfigurieren, Zugriffe beschränken, Schlüssel getrennt verwalten und Verantwortlichkeiten festlegen. Ein kleiner Dienst ist nicht automatisch ein unwichtiger Dienst. Gerade öffentliche Schnittstellen sind für Angreifer häufig interessanter, als man beim ersten Kaffee des Tages vermutet.
Was am Ende übrig bleibt
Kein Consent-Banner nur wegen eines CAPTCHA. Keine zusätzliche Datenschutzerklärung über die Datenverarbeitung eines externen CAPTCHA-Dienstes. Keine monatliche Rechnung, die mit den Formularaufrufen wächst. Keine Abhängigkeit davon, dass ein Anbieter seine Preise, Nutzungsbedingungen oder technische Einbindung morgen plötzlich neu erfindet. Und kein Captcha-Service gegen Bezahlung mit den Daten der eigenen Webseitenbesucher. Stattdessen gibt es einen kleinen, eigenen Dienst, der genau eine Aufgabe erfüllt: automatisierten Missbrauch von Formularen erschweren, Bots das digitale Leben schwermachen.
ALTCHA und GateCHA sind keine Universallösung. Bei hohem Schutzbedarf, komplexen Betrugsmustern oder großem Angriffsdruck braucht es möglicherweise zusätzliche Maßnahmen. Rate-Limiting auf Anwendungsebene, WAF-Regeln, E‑Mail-Validierung, Missbrauchserkennung und gut abgesicherte Formulare verschwinden nicht, nur weil irgendwo eine Proof-of-Work-Challenge läuft. Für den normalen Schutz von Kontaktformularen, Kommentaren, Login-Bereichen oder kleineren APIs ist der Ansatz aber ausgesprochen attraktiv. Weniger externe Abhängigkeiten, weniger unnötige Datenflüsse und eine Lösung, die sich für mehrere eigene Webprojekte wiederverwenden lässt.
Man sollte nur wissen, was man tut. Denn ein eigener Server ist kein Deko-Element. Er braucht Updates, Backups, klare Zuständigkeiten, Monitoring und jemanden, der im Zweifel nachvollziehen kann, warum das Kontaktformular gerade alle Besucher für Bots hält. Ob diese Person intern sitzt oder extern beauftragt ist, ist zweitrangig. Hauptsache, sie existiert – und sie weiß, dass der Dienst da ist. Dann ist ein selbst gehostetes CAPTCHA keine waghalsige Bastelidee, sondern eine saubere, kontrollierbare und datenschutzfreundliche Infrastrukturentscheidung.
Oder, um es mit dem Datenschutz Dude zu sagen: “Weniger Consent-Theater ist gut. Ein Server, den niemand betreut, ist nur das nächste Theaterstück – diesmal ohne Eintrittskarte und mit deutlich schlechteren Kritiken.”
PS: Der Anbieter hinter ALTCHA bietet auch gehostete Bezahlvarianten an. Um diese geht es explizit nicht.
Hahn IT Services, Schwaig
No responses yet