Browser-Automatisierung erkennen, jenseits von User Agents

Was ist Browser-Automatisierung?

Browser-Automatisierung bezeichnet das Steuern eines echten (oder fast echten) Browsers durch ein Skript statt durch einen Menschen. Das Skript öffnet Seiten, klickt Elemente, füllt Formulare und liest das DOM über einen Steuerkanal aus, meist das Chrome DevTools Protocol oder ein herstellerspezifisches Äquivalent. Der Browser rendert. Das Skript entscheidet. Die Site auf der anderen Seite soll das auseinanderhalten und kann es meist nicht.

Die meisten Bot-Detection-Systeme prüfen zuerst den User-Agent-String, ein selbstdeklariertes Etikett, das jeder HTTP-Client mit jedem Request sendet. Einen User Agent zu ändern kostet eine Zeile Code. Die W3C-WebDriver-Spezifikation verlangt, dass `navigator.webdriver` auf `true` steht, wenn ein Browser per Automatisierung gesteuert wird. Das sollte ein verlässliches Signal sein. Es war keines. WebDriver-Bots haben den Wert schlicht wieder auf false gesetzt, sobald sie merkten, dass er zur Erkennung diente.

Warum Browser-Automatisierung jetzt wichtig ist

Die Menge ist schwer zu unterschätzen. Imperva misst 51 % des gesamten Web-Traffics 2024 als automatisiert, zum ersten Mal seit einem Jahrzehnt mehrheitlich (Imperva, 2025). 41 % des Bad-Bot-Traffics gelten inzwischen als fortgeschritten, gebaut, um menschliches Verhalten zu imitieren (Imperva, 2025). Diese Bots fälschen alles, was die Browser-Oberfläche preisgibt, nicht nur den User Agent.

Wenn die Signale, die ein Client über sich selbst preisgibt, unzuverlässig sind, muss die Erkennung auf Signale ausweichen, die der Client nicht kontrollieren kann. Diese Verschiebung ist bei diesem Volumen nicht optional. Nur 2,8 % der Websites sind vollständig geschützt, gegenüber 8,4 % im Vorjahr (DataDome, 2025). 85 % der Unternehmen, die von Account-Takeover-Angriffen getroffen wurden, hatten bereits Bot-Detection im Einsatz (Kasada, 2025).

Arten der Automatisierung (Puppeteer, Playwright, Selenium, CDP-basiert)

Vier Familien von Automatisierungs-Tooling decken den Großteil des Scraping- und Agent-Traffics im heutigen Web ab.

**Selenium.** Das älteste und am breitesten gelehrte Framework. Steuert Browser über ChromeDriver oder GeckoDriver, die wiederum über herstellerspezifische Automatisierungsprotokolle mit dem Browser reden. Hinterlässt die auffälligsten Spuren: Die Variable `$cdc_asdjflasutopfhvcZLmcfl_`, die ChromeDriver in jede Seite injiziert, ist mit einer Zeile Regex zu fangen.

**Puppeteer.** Googles Node.js-Bibliothek zur Chromium-Steuerung via Chrome DevTools Protocol. Wird mit Stealth-Plugins wie puppeteer-extra-stealth ausgeliefert, die beim Seitenaufbau die offensichtlichen Automatisierungs-Artefakte überschreiben. Seit Anfang 2025 kommt puppeteer-extra-stealth nicht mehr zuverlässig an Cloudflare vorbei, und die Maintainer haben die aktive Pflege pausiert.

**Playwright.** Microsofts Multi-Browser-Automatisierung, für Chromium ebenfalls CDP-basiert und für Firefox und WebKit über herstellerspezifische Protokolle. Forks wie Patchright patchen Playwrights CDP-Nutzung auf C++-Ebene, damit die Seite die Side-Effect-Events, auf die Detection achtet, nicht sieht.

**CDP-basierte und Post-CDP-Frameworks.** nodriver, zendriver (ein async-Fork) und rebrowser-patches bilden die jüngste Generation. Sie minimieren entweder CDP-Nutzung (meiden Hochrisiko-Domains wie `Runtime` und `Console`) oder verzichten ganz auf CDP und steuern den Browser über OS-Level-Input, sodass keine CDP-Session existiert, die ein Detektor bemerken könnte.

Wie Browser-Automatisierung funktioniert

Puppeteer, Playwright und Selenium kommunizieren alle über denselben Kanal mit Chromium: das Chrome DevTools Protocol (CDP), eine WebSocket-Schnittstelle für Debugging. Rund 95 % aller automatisierten Aktionen laufen über `Page.evaluate`, CDPs Weg, JavaScript in der Seite auszuführen (Rebrowser, 2024).

`Page.evaluate` setzt voraus, dass die CDP-`Runtime`-Domain aktiviert ist. Das Aktivieren sendet Events, die die Seite beobachten kann. Jahrelang hat Bot-Detection-Code genau diese Events indirekt ausgelesen: ein Error-Objekt mit einem `.stack`-Getter, der ausgelöst wurde, sobald die Runtime das Objekt über den WebSocket serialisierte.

Im Mai 2025 haben zwei V8-Commits diesen Trick stillgelegt, Avoid error side effects in DevTools am 7. Mai und Apply getter guard throughout error preview am 9. Mai. Benutzerdefinierte Getter werden während der Error-Preview nicht mehr ausgeführt (Castle, 2025). Der `console.debug`-Check wurde nutzlos, und die meisten Anbieter haben das monatelang nicht bemerkt.

Wie Sie Automatisierung auf Ihrer Website identifizieren

Die Erkennung muss unter die Schicht, die das Skript kontrolliert. Vier Signalklassen überleben moderne Automatisierung.

**TLS- und Protokoll-Fingerprinting.** Bevor ein Browser den ersten HTTP-Request sendet, läuft ein TLS-Handshake. Das ClientHello enthält Cipher-Suites, Extensions, Protokollversionen und ALPN-Präferenzen. Diese Werte werden vom Netzwerk-Stack gesetzt, nicht von JavaScript. JA4, von FoxIO entwickelt und von Cloudflare übernommen, widersteht der Extension-Randomisierung, die JA3 gebrochen hat. Cloudflare verfolgt über 15 Millionen einzigartige JA4-Fingerprints aus mehr als 500 Millionen User Agents (Cloudflare, 2025).

**HTTP/2 SETTINGS-Frame.** Beim Verbindungsaufbau sendet der Client einen SETTINGS-Frame mit implementierungsabhängigen Parametern. Chrome sendet ein WINDOW_UPDATE von ~15 MB, Firefox ~12,5 MB. Die meisten HTTP-Bibliotheken senden null oder lassen es ganz weg. Ein 100-facher Unterschied, sichtbar bevor ein einziges Byte Seiteninhalt übertragen wird. Die Pseudo-Header-Reihenfolge (`:method`, `:authority`, `:scheme`, `:path`) ist pro Browser fest codiert.

JavaScript- und CDP-Artefakte

**JavaScript-Umgebungssignale.** Moderne Erkennung prüft, wie Properties definiert sind, nicht ihre Werte. Wenn ein Stealth-Plugin `navigator.webdriver` auf `false` überschreibt, ändert sich der Property-Deskriptor. Der Getter ist nicht mehr nativer Code, sondern ein Proxy. `toString()` liefert ein anderes Ergebnis als bei einem echten Browser. Canvas- und WebGL-Ausgaben hängen von der GPU ab. Tools, die in Cloud-Umgebungen laufen, erzeugen Ausgaben, die zur Hardware des Cloud-Anbieters passen, nicht zu der, die der User Agent behauptet.

**CDP-Artefakte.** Wenn ein CDP-Client sich verbindet und die `Runtime`-Domain aktiviert, löst das Serialisierung über die WebSocket-Verbindung aus. JavaScript in der Seite kann diese Serialisierungs-Effekte beobachten, die es in einem Browser ohne CDP-Client nicht gibt. Allein im Oktober 2025 hat Castle rund 205.000 Puppeteer-Stealth-Events erkannt, aber zehnmal mehr Traffic von gewöhnlichen Selenium-Bots (Castle, 2025).

Wie Sie auf automatisierten Traffic reagieren

Zu jeder Detection-Technik existiert eine Gegenmaßnahme. TLS-Fingerprinting hat curl-impersonate und tls-client hervorgebracht. CDP-Erkennung hat nodriver und Rebrowser hervorgebracht. JavaScript-Fingerprinting hat Anti-Detect-Browser wie Multilogin und GoLogin entstehen lassen, die separate Browser-Profile mit eigenen Fingerprints pflegen. Eine Antwort, die auf einem einzigen Signal ruht, altert schnell, weil das Umgehungs-Ökosystem genau dieses Signal gezielt angreift.

Was das Wettrennen überlebt, ist Cross-Layer-Konsistenzprüfung kombiniert mit Verhaltensbestätigung. Ein Request, bei dem TLS-Fingerprint, HTTP/2-Settings und JavaScript-Umgebung alle zu Chrome passen und dessen Verhaltensmuster menschlich wirken, ist vermutlich ein echter Browser. Ein Request, bei dem eine Schicht die anderen widerlegt, vermutlich nicht. Je mehr Schichten gleichzeitig geprüft werden, desto teurer wird das Umgehen.

Verhaltensanalyse erfasst, was Fingerprinting nicht sehen kann. Bots bewegen die Maus in geraden Linien mit konstanter Geschwindigkeit, mit Richtungen, die auf feste Winkel gelockt sind. Menschliche Cursor wandern, folgen gekrümmten Pfaden mit variabler Geschwindigkeit, pausieren unregelmäßig. In kontrollierten Tests hat die Analyse des Tastenanschlag-Timings Bots mit 99,98 % Genauigkeit erkannt (IFIP, 2024). Diese Signale wirken am stärksten auf interaktiven Seiten wie Login-Formularen, Suchfeldern und Checkout-Flows.

Steht das Urteil, sind drei Antworten pro Request möglich. Automatisierten Traffic am Edge blockieren, damit Origin nicht zahlt. Grenzfall-Sessions mit einer nicht-interaktiven Challenge konfrontieren, die den Client zur Code-Ausführung zwingt. Partner-Agents und Suchmaschinen-Indexer, die Sie durchlassen wollen, verifizieren und signiert durchreichen, mit Volumen-Tracking pro Betreiber.

Zentrale Erkenntnisse

- Browser-Automatisierung deckt den Großteil des Bot-Traffics moderner Sites ab. Bad Bots stellten 2024 37 % des Internet-Traffics, nach 32 % im Vorjahr (Imperva, 2025). - User-Agent-Filter, IP-Reputationslisten und Rate-Limiting allein fangen die trägsten Bots und verpassen den Rest. Das W3C-`navigator.webdriver`-Flag ist trivial auf `false` zurückzusetzen. - Wirksame Erkennung prüft über Schichten hinweg: TLS-Handshake, HTTP/2 SETTINGS, JavaScript-Umgebung, CDP-Artefakte und Verhalten, in Echtzeit gegeneinander abgeglichen. Ein Widerspruch zwischen zwei Schichten ist das Signal. - Die Antwort ist eine Entscheidung pro Request: blockieren, challengen oder verifizieren. robots.txt regelt gut erzogene Crawler. Centinel prüft jede Anfrage über all diese Schichten und entscheidet in unter 2 ms, bevor der Bot Origin erreicht.