Viele CAPTCHA-Implementierungen teilen die Client-IP, den Browser-Fingerabdruck, den Header-Satz und die Verhaltenstelemetrie im Moment der Verifizierung mit Drittanbieter-Diensten. Dieses Modell ist in einigen Sektoren akzeptabel, aber für Behörden-, Finanz-, Gesundheits- und Air-Gap-Umgebungen schafft es ernsthafte Datenlokalisierungs- und Compliance-Risiken.
Für compliance-sensitive Organisationen kann sogar ein einziger CAPTCHA-Aufruf auf einem Login-Screen eine Diskussion über persönliche Datenübertragungen auslösen. Explizite Einwilligungsanforderungen, grenzüberschreitende Transferregeln, vertragliche Schutzmaßnahmen und Anbieterabhängigkeit können eine einfache Bot-Schutzentscheidung in ein langes Compliance-Projekt verwandeln.
Das Verlassen auf externe CAPTCHA-Dienste schafft auch operationelle Risiken. Wenn ein Drittanbieter-Verifizierungsdienst sich verlangsamt oder nicht erreichbar ist, wird der Login-, Registrierungs- oder Zahlungsflow jeder geschützten Anwendung betroffen. Bot-Schutz wird zu einer kritischen externen Abhängigkeit für die Anwendung.
Das korrekte Modell ist, Challenge-Generierung, -Auslieferung und -Verifizierung innerhalb der eigenen ADC-Schicht der Organisation durchzuführen. Client-Daten bleiben lokal, der Verifizierungsprozess ist in sich geschlossen, Schwierigkeit skaliert mit dem Service-Risiko, und fehlgeschlagene Versuche können die Quarantäne-Eskalation speisen.
TR7 Selbst-gehostetes CAPTCHA liefert genau dieses Modell: es macht Bot-Verifizierung selbst-gehostet, reduziert das Datenlokalisierungsrisiko und integriert direkt mit der WAAP-Entscheidungs-Pipeline.
TR7 implementiert CAPTCHA durch lokale Generierung, einstellbare Schwierigkeit, sichtbare und unsichtbare Verifikationsmodi und Quarantäne-Eskalation.
Das CAPTCHA-Bild, HTML/JS-Inhalt, Token-Signatur und Lösungsverifizierung laufen alle auf TR7. Während des Verifizierungsprozesses wird kein ausgehender HTTP-Aufruf an einen externen Dienst gemacht.
Schwierigkeit wird zusammen mit Zeichenlänge, visuellem Rauschen, PoW-Arbeitsbelastung und Mindest-Lösungszeit ausgewertet. Der Operator schlägt mit einer einzigen Einstellung die richtige Balance zwischen Benutzererfahrung und Bot-Resistenz.
Visuelle Verifizierung kann Hochrisiko-Clients gezeigt werden. Für mittleres Risiko kann PoW-Validierung lautlos im Hintergrund laufen, ohne dem Benutzer einen zusätzlichen Screen zu präsentieren.
CAPTCHA wird nur ausgelöst, wenn ein Risikoschwellenwert überschritten wird. Falsche Antworten werden verfolgt; sobald der Schwellenwert überschritten ist, können Quarantäne-Aktionen wie deny, redirect, benutzerdefinierter Inhalt oder ein benutzerdefinierter Statuscode angewendet werden.
Selbst-gehostetes CAPTCHA kombiniert selbst-gehostete Challenge-Generierung mit Bot-Scoring, PoW, Cookie-Sicherheit und Quarantäne-Flows.
TR7 generiert das CAPTCHA-Bild intern, stellt die Challenge-Seite von seinem eigenen Dienst bereit und verifiziert Lösungen durch einen lokalen Hilfsprozess. Die Client-IP, der User-Agent und das Verifizierungsergebnis werden nie an einen externen Dienst gesendet. Dieses Modell bietet einen kritischen Vorteil für Organisationen mit Datenlokalisierungsanforderungen. CAPTCHA-Schutz wird ohne Abhängigkeit von externen Diensten angewendet.
In TR7 wird Schwierigkeit auf einer Skala von 1–5 gewählt. Dieser Wert mappt auf PoW-Bit-Tiefe (16–20 Bits), CAPTCHA-Zeichenlänge (4–7 Zeichen), visuelle Linien- und Punktdichte und eine server-seitig erzwungene Mindest-Lösungszeit. Der Operator verwaltet sowohl die menschliche Erfahrung als auch die Bot-Kosten mit einem einzigen Schieberegler. Höher-riskante Dienste können mit höherer Schwierigkeit konfiguriert werden.
PoW-Validierung wird als Teil der CAPTCHA-Verifizierung angewendet. Der Browser muss eine definierte Berechnung abschließen, bevor die Lösung akzeptiert wird. Eine server-seitige Mindest-Lösungszeit wird ebenfalls erzwungen — auch wenn ein Bot die korrekte Antwort sofort produziert, wird eine zu schnell ankommende Lösung als verdächtig behandelt. Dieser Ansatz erhöht die Automatisierungskosten, fügt echten Benutzern jedoch minimale Last hinzu.
Das nach erfolgreicher Verifizierung produzierte Token wird in einem verschlüsselten Cookie getragen. Das Token kann an die IP-Adresse und den User-Agent-Kontext des Clients gebunden werden, was es erheblich schwieriger macht, ein von einem Client erhaltenes Verifizierungstoken in einem anderen Kontext wiederzuverwenden. Während des verifiedTtl-Fensters muss der echte Benutzer CAPTCHA nicht bei jeder Anfrage lösen.
TR7 kann jeder CAPTCHA-Regel einen dedizierten Hilfsprozess und einen dedizierten Socket-Pfad zuweisen. Diese Isolierung reduziert die Auswirkungen eines Fehlers oder einer Last-Spitze in einer Regel auf andere Regeln. Pool-basierte Trennung bedeutet, dass CAPTCHA-Flows für verschiedene Dienste unabhängig verwaltet werden. scalingCount ermöglicht es, mehrere Prozesse für dieselbe Regel zu betreiben.
Wenn type auf text gesetzt ist, trifft der Benutzer auf ein visuelles CAPTCHA. Im unsichtbaren Modus läuft PoW-basierte Verifizierung, ohne einen vollständigen Challenge-Screen zu präsentieren. Mittleres-Risiko-Clients werden mit weniger Reibung verifiziert, während höher-riskante Clients visuelles CAPTCHA erhalten, um Bot-Kosten zu erhöhen.
Hintergrundfarbe, Textfarbe, Theme und Größe können pro Dienst definiert werden. Kleine, mittlere und große CAPTCHA-Größen passen sich verschiedenen Benutzeroberflächen an. Der Verifikationsscreen erscheint nicht losgelöst von der Markenerfahrung der Organisation. In White-Label-B2B-SaaS-Szenarien kann jeder Tenant eine Erfahrung bieten, die seiner eigenen visuellen Identität entspricht.
CAPTCHA-Titel, Beschreibungstext und Fehlermeldungen können an eine mehrsprachige Struktur gebunden werden. Sprache kann pro Dienst oder basierend auf dem Client-Kontext gewählt werden. Dies bietet einen klareren Verifikationsflow in Behörden-, Finanz- und Multi-Region-Diensten. Das Hinzufügen einer neuen Sprache erfordert keine Änderung der Verifikationslogik.
CAPTCHA muss standardmäßig nicht jedem Benutzer gezeigt werden. TR7-Bot-Scoring, IP-Reputation, Verhaltens-Signale und DDoS-Bedingungen können die Challenge-Präsentation auf riskante Clients beschränken. Dies reduziert Reibung für echte Benutzer. Vertrauenswürdiger Traffic fährt auf dem normalen Pfad fort, während verdächtiger Traffic zur Verifizierung geleitet wird.
Falsche CAPTCHA-Antworten können verfolgt werden, und sobald ein definierter Schwellenwert überschritten wird, wird der Client quarantänisiert. Die Quarantäne-Aktion kann als deny, redirect, customContent oder customStatusCode konfiguriert werden. Dies verhindert, dass Bots wiederholt Challenges verbrauchen, um das System zu erschöpfen. Mit zunehmenden Fehlern ersetzt eine härtere Aktion die Challenge.
Wenn ein Benutzer CAPTCHA erfolgreich besteht, kann er für einen konfigurierten Zeitraum als verifiziert behandelt werden. Demselben Benutzer wird CAPTCHA nicht wieder gezeigt, bis verifiedTtl abläuft. Dies bewahrt die echte Benutzererfahrung, während die anfängliche Verifikationsbarriere gegen Bots aufrechterhalten wird. IP+UA-Binding erschwert es, den Verifikationsstatus zu stehlen und in einem anderen Kontext wiederzuverwenden.
CAPTCHA ist kein eigenständiger Screen — es ist eine der Aktionen in der TR7-Entscheidungs-Pipeline. DDoS-Schutz, Bot-Schutz, IP-Reputation und Account-Takeover-Policies können alle die showCaptcha-Aktion auslösen. Jedes Sicherheitsmodul kann sein eigenes Risikosignal mit dem CAPTCHA-Verifikationsflow verbinden. Der Operator verwendet eine einzige selbst-gehostete Challenge-Infrastruktur über verschiedene Risikoszenarien hinweg.
Selbst-gehostetes CAPTCHA wird gemeinsam mit Hilfsprozessen, Secret-Management, Token-Binding, einer Quarantäne-Zustandsmaschine, mehrsprachiger Unterstützung und Audit-Records betrieben.
Jede CAPTCHA-Regel kann mit einem dedizierten Hilfsprozess laufen. Wenn der Prozess unerwartet endet, kann er automatisch neu gestartet werden. Ein Fehler in einer Regel beeinträchtigt nicht die CAPTCHA-Verifizierung in anderen Diensten.
Ein dedizierter Socket-Pfad kann für jeden Pool und jede CAPTCHA-Regel erstellt werden. Diese Struktur trennt Challenge-Verifikations-Traffic zwischen Diensten. Wenn die Konfiguration erneut abgespielt wird, bleibt die Zuordnung zwischen derselben logischen Regel und derselben physischen Socket-Struktur erhalten.
Für jede Regel kann ein eindeutiges Secret generiert werden, und Verifizierungstoken werden gegen dieses Secret signiert. Wenn ein Secret rotiert wird, können vorhandene verifizierte Token ungültig werden. Dieses Verhalten kann für geplante Sicherheitserneuerungen genutzt werden.
PoW-Lösung kann in modernen Browsern effizientere APIs nutzen. In Umgebungen ohne Unterstützung wird ein langsameres, aber kompatibles JavaScript-Fallback angewendet. Auf mobilen Clients läuft der Lösungsprozess asynchron, sodass die Benutzeroberfläche nicht einfriert.
Fehlgeschlagene Challenge-Antworten werden separat verfolgt. Wenn der Schwellenwert überschritten wird, wird der Client für einen konfigurierten Zeitraum zu einer Quarantäne-Aktion geleitet. Während dieser Zeit werden deny, redirect oder benutzerdefinierter Inhalt direkt angewendet, statt ein weiteres CAPTCHA zu präsentieren.
Für jede Challenge können Zeitstempel, Quell-IP, User-Agent, Regel-ID, Schwierigkeitsstufe, Challenge-Typ und Ergebnis geloggt werden. PoW-Lösungszeit produziert ebenfalls ein wertvolles Signal für Incident-Untersuchungen. Diese Records unterstützen Bot-Analyse- und Betrugs-Forensik-Workflows.
Banken können verpflichtet sein, die Übermittlung von Benutzer-IP- oder Browser-Informationen an externe Dienste während der CAPTCHA-Verifizierung zu vermeiden. Mit TR7 selbst-gehostetem CAPTCHA bleibt der Challenge-Prozess innerhalb des ADC und Login-Schutz wird gemäß Datenlokalisierungsanforderungen betrieben.
Behörden, die in Umgebungen ohne Zugang zu externen Verifizierungsdiensten betreiben, können dennoch Bot-Schutz anwenden. TR7 CAPTCHA-Generierung und -Verifizierung funktionieren ohne externe DNS-Auflösung oder ausgehende HTTP-Aufrufe.
Bei Coupon-Betrug, gefälschter Kontoerstellung oder automatisierten Registrierungsangriffen kann der Registrierungs-Endpoint basierend auf Bot-Score hinter CAPTCHA gestellt werden. Fehlgeschlagene Versuche werden mit Quarantäne verknüpft, was Bots daran hindert, kontinuierlich Challenges zu verbrauchen.
Healthcare-Portale können Benutzer bei Terminbuchungs- oder Patientenzugangs-Flows, die sensible Daten beinhalten, verifizieren, ohne auf einen externen CAPTCHA-Dienst angewiesen zu sein. Der Benutzer-Verifikationsprozess bleibt unter organisatorischer Kontrolle.
Während eines DDoS- oder Bot-Angriffs kann TR7 CAPTCHA oder unsichtbares PoW nur auf Clients mit hohem Risiko-Score anwenden. Die Mehrheit der echten Benutzer fährt ohne zusätzliche Reibung fort, während Bot-Kosten erhöht werden.
B2B-SaaS-Anbieter können Farb-, Theme- und Größeneinstellungen separat für jeden Tenant konfigurieren. Der CAPTCHA-Screen trägt kein Drittanbieter-Logo und erscheint näher an der eigenen Benutzererfahrung des Kunden.
Selbst-gehostetes CAPTCHA, das Daten lokal hält — integriert mit WAAP, DDoS und ATO-Flows. Wir zeigen Ihnen ein Live-Setup in Ihrer eigenen Umgebung.