Ralf Gundelach, Michael Mühlhauser, Dominik Herrmann · Full Paper, ARES 2026, 24.–27. August 2026, Linköping (Schweden)

Kurzfassung

Viele Websites setzen Bot-Erkennung ein, die automatisierte Browser blockiert – genau die Werkzeuge, mit denen die Forschung Datenschutz- und Sicherheitspraktiken im Web misst. Unser Literatursurvey zeigt, dass 83 % von 81 Measurement-Papern an Top-Venues (2020–2025) dieses Problem nicht berichten. In einer Messstudie über die Tranco Top 10.000 (vier Browser-Konfigurationen, 40.000 Seitenaufrufe) quantifizieren wir den Effekt: Chromium headless wird auf 15,2 % der Sites geblockt, die übrigen Konfigurationen auf 6,8–7,2 %; 82 % der Blocks sind auf Bot-Erkennung zurückführbar. Der resultierende Stichprobenverlust ist nicht zufällig, sondern korreliert mit dem Infrastruktur-Anbieter – und lässt sich daher nicht durch stratifiziertes Sampling korrigieren.

Kernzahlen

Soft-Block-Raten nach Browser-Konfiguration: Chromium headless 15,2 Prozent, Chromium headed 7,2 Prozent, Firefox headless 6,8 Prozent, Firefox headed 6,8 ProzentChromium headless: 15,2 % Soft-Blocks (HTTP 403/429/503) von 10.000 SitesChromium headless15,2 %Chromium headed: 7,2 % Soft-Blocks (HTTP 403/429/503) von 10.000 SitesChromium headed7,2 %Firefox headless: 6,8 % Soft-Blocks (HTTP 403/429/503) von 10.000 SitesFirefox headless6,8 %Firefox headed: 6,8 % Soft-Blocks (HTTP 403/429/503) von 10.000 SitesFirefox headed6,8 %
Soft-Block-Rate (HTTP 403/429/503) je Browser-Konfiguration; n = 10.000 Sites je Konfiguration, Tranco Top 10K, Februar/März 2026.
Block-Raten nach Infrastruktur-Anbieter: Cloudflare 37,0 Prozent, Akamai 26,4 Prozent, Amazon 16,3 Prozent, Fastly 15,6 Prozent, Microsoft 14,8 Prozent, Google 5,1 ProzentCloudflare: 37,0 % der Sites in mindestens einer Konfiguration geblocktCloudflare37,0 %Akamai: 26,4 % der Sites in mindestens einer Konfiguration geblocktAkamai26,4 %Amazon: 16,3 % der Sites in mindestens einer Konfiguration geblocktAmazon16,3 %Fastly: 15,6 % der Sites in mindestens einer Konfiguration geblocktFastly15,6 %Microsoft: 14,8 % der Sites in mindestens einer Konfiguration geblocktMicrosoft14,8 %Google: 5,1 % der Sites in mindestens einer Konfiguration geblocktGoogle5,1 %
Anteil geblockter Sites nach Infrastruktur-Anbieter (Block in mindestens einer Konfiguration; nur Anbieter mit ≥ 100 Sites im Sample). Blocking korreliert mit dem Anbieter, nicht mit der Popularität der Site.
  • 83 % der 81 untersuchten Measurement-Paper (USENIX Security, IEEE S&P, CCS, NDSS, WWW, IMC, PETS; 2020–2025) berichten Block-Raten nicht; nur 5 % quantifizieren sie.
  • 772 vs. 14: Von 6.936 paarweise vergleichbaren Sites blocken 772 ausschließlich Chromium headless, nur 14 ausschließlich Chromium headed. Bei Firefox ist der Unterschied vernachlässigbar (15 vs. 12).
  • 82 % der 1.554 beobachteten Blocks sind auf Bot-Erkennung zurückführbar: 59 % über Vendor-Signaturen bestätigt (Cloudflare-Challenges, DataDome, PerimeterX/HUMAN, CAPTCHA, Imperva), 23 % aus konfigurationsabhängigem Blocking abgeleitet. Nur 18 % sind uniforme Infrastruktur-Blocks.
  • 75 % der ausschließlich in Chromium headless geblockten Sites lassen sich allein durch angepasste HTTP-Header entblocken (User-Agent und sec-ch-ua-Client-Hints verraten „HeadlessChrome“); 25 % blocken auch danach – dort greifen tiefere Detection-Ebenen.
  • Detection-Infrastruktur ist breiter als aktives Blocking: 34 % der erfolgreich gescannten Sites prüfen navigator.webdriver, 46 % proben mindestens ein eindeutiges Automations-Signal.

Taxonomie der Detection-Techniken

Das Paper klassifiziert client-seitige Bot-Detection auf zwei Achsen: nach der Aussagekraft der abgefragten Signale und nach der Messmethode, mit der sich diese Zugriffe beobachten lassen.

Signal-TierBedeutungBeispiele
Tier 1Kein legitimer Zweck außer Automations-Erkennungnavigator.webdriver, window._selenium
Tier 2Starke Automations-Indikatoren, auch für Fingerprinting nutzbarchrome.runtime, navigator.plugins
Tier 3Allgemeines Browser-Fingerprinting, nur im Kontext interpretierbarnavigator.userAgent, localStorage
MessmethodeFunktionsweise
Property InterceptionRekursiver JavaScript-Proxy auf window protokolliert jeden Property-Zugriff samt Zugriffspfad
Prototype PatchingNicht-konfigurierbare Getter auf Built-in-Prototypen werden durch instrumentierte Versionen ersetzt
Honeypot PropertiesGepflanzte Schein-Properties (z. B. window._selenium), deren Abfrage Detection-Absicht belegt

Die 28 identifizierten Tier-1-Signale verteilen sich auf acht Framework-Familien (WebDriver API, PhantomJS, NightmareJS, WebDriver Protocol, Selenium, Chrome DevTools, Awesomium, ChromeDriver). Kommerzielle Anbieter kombinieren sie mit Fingerprinting in bis zu acht Kategorien (Canvas, Audio, WebGL, Speech, Fonts, Dimensions, Permissions, Plugins).

Selbsttest: Sieht Ihr Browser wie ein Bot aus?

Der Test prüft direkt in Ihrem Browser einen Ausschnitt der client-seitig sichtbaren Signale aus der Taxonomie oben. Er läuft vollständig lokal – es werden keine Daten übertragen oder gespeichert.

Empfehlungen für Measurement-Studien

Browser-Setup berichten

Engine, Version und Display-Modus (headless/headed) dokumentieren – der Unterschied macht bis zu Faktor 2 in der Block-Rate aus.

Block-Raten quantifizieren

Die beobachtete Block- und Fehlerrate während des Crawls messen und berichten, statt sie als Rauschen zu behandeln.

CDN-Zusammensetzung dokumentieren

Der Infrastruktur-Anbieter ist ein Confounder: Cloudflare-gehostete Sites fallen systematisch häufiger aus der Stichprobe als andere.

Stealth-Maßnahmen offenlegen

Eingesetzte Gegenmaßnahmen – oder deren bewusste Weglassung – gehören in die Methodenbeschreibung.

Methodik und Limitationen

Methodik. Literatursurvey: 132 Paper gescreent, 81 eingeschlossen, 12 Kriterien, doppelt kodierte Teilstichprobe (Cohen’s κ = 0,90). Messstudie: Tranco Top 10.000 (Liste vom 25.02.2026), vier Konfigurationen im 2×2-Design (Chromium/Firefox × headless/headed, Playwright ohne Stealth-Maßnahmen), 40.000 Seitenaufrufe von Datacenter-IPs mit IP-Rotation, 27.02.–02.03.2026. Block = HTTP 403/429/503; Zuordnung zu Bot-Erkennung über manuell verifizierte Vendor-Signaturen und Cross-Condition-Analyse.

Limitationen. Einzelner europäischer Vantage-Point und einmaliger Messzeitpunkt; nur Homepages der Top 10K; erfasst werden explizite HTTP-Blocks, nicht degradierte Inhalte in 200er-Antworten; die headed-Konfigurationen approximieren menschliches Browsen nur. Die client-seitig gemessene Detection-Prevalence ist eine Untergrenze, da serverseitige Verfahren (TLS-Fingerprinting, IP-Reputation, Verhaltensanalyse) unsichtbar bleiben.

Zitieren

Camera-Ready-Version und DOI erscheinen zur Konferenz; bis dahin bitte den Preprint zitieren:

@misc{gundelach2026botdetection,
  title         = {Detecting Bot Detection: Prevalence, Techniques, and
                   Implications for Web Measurement Research},
  author        = {Gundelach, Ralf and M{\"u}hlhauser, Michael and Herrmann, Dominik},
  year          = {2026},
  eprint        = {2606.14525},
  archivePrefix = {arXiv},
  primaryClass  = {cs.CR},
  note          = {Angenommen bei ARES 2026}
}

Crawler, Datensatz, Analyse-Notebooks und die Kodierungen des Literatursurveys sind offen verfügbar: doi.org/10.5281/zenodo.20334022 (Screenshots aus Urheberrechtsgründen ausgenommen).

Kontakt

Prof. Dr. Dominik Herrmann
Lst Privatsphäre und Sicherheit in Informationssystemen
Universität Bamberg, 96045 Bamberg
Lst Privatsphäre und Sicherheit in Informationssystemen
Universität Bamberg
96045 Bamberg

dh.psi@uni-bamberg.de | +49 951 863-2661
uni-mal-anders.de | LinkedIn

Prof. Dr. Dominik Herrmann
Lst Privatsphäre und Sicherheit in Informationssystemen,
Universität Bamberg, 96045 Bamberg

dh.psi@uni-bamberg.de
+49 951 863-2661
uni-mal-anders.de | LinkedIn

Ansicht