Schlechte UX gefährdet IT-Sicherheit und Inklusion
Ein dokumentierter CAPTCHA-Fall zeigt, warum Abuse-Schutz, serverseitige Prüfung und Barrierefreiheit gemeinsam getestet werden müssen.
Ende Dezember 2025 spülte mir der Algorithmus etwas in die Timeline, das ich erst für Satire hielt: ein Fundstück von Pascal Wegner auf X. Er zeigte einen Screenshot der Bundesnetzagentur, der zu absurd wirkte, um wahr zu sein. Der Beitrag ist heute nicht mehr zuverlässig abrufbar; der lokal archivierte Screenshot zeigt aber die damalige BNetzA-URL, die Aufgabenstellung und den zugehörigen DOM-Ausschnitt.
Ich musste das selbst sehen. Also ab auf die Webseite, Entwicklertools geöffnet, und da war er: dieser Moment ungläubigen Staunens. Im DOM stand der Challenge-Text mit unsichtbaren ‌-Zeichen zwischen den Buchstaben, im Klartext auslesbar für jeden Code, der die Seite parst. Ob ein Bot das Formular tatsächlich erfolgreich abgeschickt hat, belegt der Screenshot nicht. Die konkrete URL lieferte bei der Prüfung am 15. August 2026 nur noch HTTP 404.
„Bitte geben Sie den Text in Großbuchstaben und ohne Leerzeichen ein.“
Der enge Befund reicht für eine wichtige Designfrage: Wenn ein Challenge-Wert im Client steht, ist er kein Geheimnis. Gleichzeitig kann eine visuelle oder kognitive Aufgabe Menschen behindern. Security und Barrierefreiheit müssen deshalb im selben Testzyklus betrachtet werden.
Wir investieren viele Ressourcen in Compliance-Dokumente und Datenschutzerklärungen. Bei der praktischen Umsetzung bauen wir uns dagegen manchmal digitale Potemkinsche Dörfer: Fassaden, die bei genauerem Hinsehen nicht tragen.
Was der Screenshot zeigt und was nicht
Der Screenshot dokumentiert einen clientseitig lesbaren Challenge-Text. Er misst weder die Erfolgsquote von Bots noch die Ausgabe verschiedener Screenreader. Auch eine konkrete Rechtsverletzung lässt sich daraus nicht ableiten.
Für einen belastbaren Review braucht es zwei getrennte Hypothesen:
- Security-Risiko: Ein automatisierter Client könnte den Text aus dem DOM extrahieren und die vorgesehene Hürde umgehen.
- Barrierefreiheitsrisiko: Zeichenbild, Großschreibung, unsichtbare Trennzeichen und fehlende Alternativen könnten Bedienung oder Verständnis mit assistiven Technologien erschweren.
Beide Hypothesen sind testbar. Keine wird durch einen Screenshot allein bewiesen.
Der Server entscheidet
In der physischen Welt würde niemand seinen Haustürschlüssel unter die Fußmatte legen und hoffen, dass niemand drunter schaut. Digital passiert genau das, wenn Validierungslogik im Client, also im Browser, liegt und von dort aus auslesbar ist.
„Serverseitig validieren” ist richtig, aber noch kein vollständiges Schutzkonzept. Der Browser bleibt eine nicht vertrauenswürdige Umgebung. Ein brauchbarer Abuse-Schutz prüft mindestens:
- Der Server erzeugt und bewertet einen kurzlebigen, nicht wiederverwendbaren Challenge- oder Sitzungstoken.
- Ablaufzeit und Replay-Schutz verhindern die erneute Nutzung einer gelösten Aufgabe.
- Rate-Limits und Missbrauchserkennung begrenzen automatisierte Versuche, ohne legitime Nutzung pauschal zu blockieren.
- Monitoring macht Fehlerraten und auffällige Muster sichtbar.
- Die eigentliche Geschäftslogik bleibt auch dann sicher, wenn die sichtbare Hürde umgangen wird.
Die goldene Regel dahinter: Don't roll your own crypto. Baue keine eigenen Sicherheitsmechanismen, wenn du kein Kryptograph bist. Wenn du das Rad neu erfindest, wird es meistens viereckig und stolpert über den nächsten Screenreader.
Die BSI TR-03172-3 verlangt für Onlinedienste im Portalverbund Eingabevalidierung und fordert bei ungeschütztem Dateiupload Schutz vor Bots und Spammern.1 CAPTCHAs regelt sie nicht eigens. Wo eine solche Hürde eingesetzt wird, ist sie höchstens eine Schicht, nicht die Sicherheitsarchitektur.
Barrierefreiheit ist Teil des Tests
Für Websites und Apps öffentlicher Bundesstellen sind vor allem § 12a BGG und § 3 BITV 2.0 relevant.2 Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 für die erfassten Produkte und Dienstleistungen, darunter bestimmte Bankdienstleistungen für Verbraucher und Dienste im elektronischen Geschäftsverkehr.3 Es ist kein pauschales Gesetz für jede Website.
WCAG 2.2 verlangt bei CAPTCHA unter Erfolgskriterium 1.1.1 eine Beschreibung des Zwecks und Alternativen für unterschiedliche Sinneswahrnehmungen.4 Ein Audio-CAPTCHA löst das Problem nicht automatisch; auch Hören, Sprache und Kognition können Barrieren sein.
Die Bundesfachstelle Barrierefreiheit empfiehlt passive Verfahren und praktische Tests.5 Zugleich warnt sie, dass verhaltensbasierte Systeme Menschen mit assistiven Technologien fälschlich als Bots einordnen können. „Unsichtbar“ bedeutet also nicht „barrierefrei“.
Eine kleine Testmatrix macht die Risiken sichtbar:
| Test | Prüffrage |
|---|---|
| Tastatur | Ist die Aufgabe ohne Maus erreichbar, lösbar und zurücksetzbar? |
| Screenreader | Sind Zweck, Eingabe, Fehler und Alternative verständlich angekündigt? |
| Zoom und Vergrößerung | Bleiben Challenge, Eingabe und Fehlermeldung bei 200 und 400 Prozent nutzbar? |
| Spracheingabe | Lassen sich Feld, Zeichen und Bedienelemente eindeutig ansprechen? |
| Fehlversuch | Bleiben Fokus, Erklärung und eine zugängliche Alternative erhalten? |
| Browser und Geräte | Funktionieren Schutz und Fallback in mindestens zwei Browsern und auf mobilen Geräten? |
Ein manueller Test mit betroffenen Nutzenden oder erfahrenen Fachleuten für Barrierefreiheit ist durch diese Matrix nicht ersetzt. Sie verhindert nur, dass das Team bei „Widget geladen“ aufhört.
Passive Verfahren brauchen dieselbe Prüfung
Produkte wie Cloudflare Turnstile, reCAPTCHA oder Proof-of-Work-basierte Verfahren können sichtbare Aufgaben reduzieren. Sie bringen eigene Fragen mit: Welche Daten fließen an Dritte? Wie hoch sind Fehlklassifikationen? Was passiert auf alten oder schwachen Geräten? Welcher Fallback erscheint, wenn JavaScript, Cookies oder der Anbieter ausfallen?
Kein Anbietername ist ein Gütesiegel. Entscheidend sind das Bedrohungsmodell, die Datenschutzprüfung, reale Fehlerraten und Tests mit assistiven Technologien.
Ein gemeinsamer Prüfzyklus
Der BNetzA-Fall ist als dokumentierter Altstand nützlich, gerade weil sein Befund eng bleibt. Ein autorisierter Security-Test prüft, was der Client sehen und der Server akzeptieren kann. Ein Accessibility-Test prüft dieselben Erfolgs-, Fehler- und Fallback-Pfade mit unterschiedlichen Eingaben und Hilfsmitteln.
Diese Verbindung fehlt oft. Wer Abuse-Schutz nur nach abgewehrten Requests bewertet, übersieht ausgeschlossene Menschen. Wer nur auf eine ruhige Oberfläche schaut, übersieht vielleicht einen auslesbaren oder wiederverwendbaren Challenge-Wert. Der bessere Mindeststandard ist ein Schutz, der automatisierte Angriffe erschwert und berechtigte Nutzung nicht unnötig behindert.
Vier Schritte weg vom Fax-Mindset
Wer heute noch Zeichen abtippen lässt, setzt auf eine schwache Barriere. Moderne OCR- und Vision-Systeme lösen solche Aufgaben zuverlässig. Für den Anfang braucht es kein Beraterbudget, nur diese vier Punkte:
- Serverseitig validieren. Die richtige Antwort darf den Server nicht verlassen, bevor der Nutzer sie eingegeben hat. Traue dem Browser nie.
- Barrierefreiheit mitprüfen. Zu jeder Sicherheitsmaßnahme gehört die Frage: Kann ein blinder Nutzer sie bedienen? Wenn nein, ist sie nicht fertig.
- Nichts selbst erfinden. Für Challenge, Token und Krypto gibt es geprüfte Bausteine. Eigenbau ist der häufigste Weg zu genau dem Fehler, um den es hier geht.
- Von außen testen lassen. Ein Durchgang mit einem Screenreader und einer mit Blick auf die Client-Logik. Betriebsblindheit ist das eigentliche Risiko.
Die Haustür muss wirklich abgeschlossen sein. Nicht dekorativ. Und nicht so, dass Bots leichter reinkommen als Menschen.
Verwandt: Dark Patterns und Einwilligungs-UX bei Banken sowie Content Testing mit prüfbaren Erfolgskriterien.
Quellen & Referenzen