User-Agent

Der User-Agent-Header soll den Client identifizieren, der eine HTTP-Anfrage stellt — Browsername, Version, Betriebssystem usw. Er ist zugleich der am stärksten gewucherte Header der HTTP-Geschichte und lügt aus Abwärtskompatibilitätsgründen, die sich Jahr für Jahr verstärken, über seinen eigenen Inhalt.

Ein typischer moderner Chrome-User-Agent-String:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Chrome gibt sich gleichzeitig als Mozilla, Apple WebKit und Safari aus. Keines dieser Tokens ist zutreffend — sie existieren, weil irgendein serverseitiger Code von 1998 auf „Mozilla“ prüfte, bevor er modernes HTML auslieferte, sodass jeder nachfolgende Browser „Mozilla/5.0“ hinzufügte, um nicht herabgestuft zu werden. Der String ist seither ein Museum der Kompatibilitäts-Hacks.

Moderne Alternativen:

• User-Agent Client Hints (Sec-CH-UA-Header-Familie) — Chrome begann 2020, strukturierte Client Hints zu senden. Server können sich per Accept-CH dafür anmelden. Sauberere Daten, kleinerer Standard-Fußabdruck.
• Funktionserkennung statt UA-Sniffing — prüfen Sie, ob die benötigte API existiert, statt aus der Browserversion zu raten.

User-Agent-Strings lassen sich trivial fälschen; behandeln Sie sie als Hinweis, nicht als Sicherheitsgrenze. Für Analysen liefert der UA eine grobe Aufschlüsselung der Client-Anteile; für tatsächliche Entscheidungen nutzen Sie Funktionserkennung.

Das Chrome-User-Agent-Reduktionsprojekt: Google begann 2022, die Entropie des UA-Strings herunterzufahren, indem es die Minor-Version einfror, die genaue Betriebssystemversion strich und Mobile-/Desktop-Strings vereinheitlichte. Ziel war es, passives Fingerprinting zu reduzieren — ein UA-String kann allein anhand seiner Build-Versions-Tokens einen einzelnen Browser unter Hunderttausenden anderer identifizieren. Bis 2025 ist der Chrome-UA-String merklich kürzer und weniger identifizierend. Firefox und Safari sind langsamer gefolgt. Seiten, die noch auf das Parsen des UA zur Browser-Erkennung angewiesen sind, gehen langsam kaputt — die moderne Client-Hints-API (Sec-CH-UA, Sec-CH-UA-Platform usw.) ist der unterstützte Ersatz.

Bot-User-Agents — Konvention, keine Durchsetzung: Googlebot, Bingbot, GPTBot, ClaudeBot und die meisten kommerziellen Crawler identifizieren sich im UA-String ehrlich, weil sie an der robots.txt vorbeigelassen und fair ratenbegrenzt werden müssen. Scraper, die sich nicht identifizieren, fälschen oft einen Browser-UA — was der Grund ist, warum Ratenbegrenzung und Bot-Erkennung sich nicht allein auf UA-Strings verlassen können. Modernes Bot-Management kombiniert den UA mit TLS-Fingerprinting (JA3/JA4), HTTP/2-Einstellungen, Maus-/Tastatursignalen und Headless-Browser-Markern. Eine Seite, die nur gelistete Bots zulassen will, sollte auf mehreren Signalen abgleichen, nicht nur auf dem UA. Quelle: RFC 9110 §10.1.5 — User-Agent.

Durchgerechnetes Beispiel

Sie möchten „der Nutzer ist auf iOS Safari“ für eine Web-Push-Kompatibilitätsprüfung erkennen. Naives UA-Sniffing: /iPhone|iPad|iPod/.test(ua) && /Safari/.test(ua) && !/CriOS|FxiOS/.test(ua). Nur: iPadOS 13+ liefert standardmäßig den „Desktop“-UA aus, sodass iPad nicht im String steht. Nur: Chrome auf iOS enthält „CriOS“, ist aber tatsächlich WebKit darunter (Apple-Plattformrichtlinie), sodass die Negation falsch ist. Nur: Ein Nutzer mit Datenschutz-Erweiterung könnte seinen UA als Firefox-auf-Linux fälschen. Nutzen Sie stattdessen Funktionserkennung: 'serviceWorker' in navigator && 'PushManager' in window && Notification.permission !== 'denied' — drei Zeilenprüfungen, funktioniert in jedem Browser, geht nicht kaputt, wenn Apple nächstes Jahr iOS 18 ausliefert. Die UA-Sniffing-Variante war bereits beim Ausliefern für ~6 % der Nutzer kaputt.

Wann und warum es zählt

UA-basierte Logik ist die mit Abstand größte Quelle von „funktioniert in Chrome, kaputt in Safari“-Fehlern, die gar keine Browser-Engine-Fehler sind. Behandeln Sie den UA serverseitig nur als grobes Analysesignal — gaten Sie Funktionen, Inhalte oder Sicherheitsprüfungen niemals darüber. Bevorzugen Sie clientseitig Funktionserkennung (Modernizr oder selbstgeschriebene Prüfungen für die konkrete benötigte API). Für die Bot-Abwehr kombinieren Sie den UA mit TLS-Fingerprinting (Akamai Bot Manager, Cloudflare Bot Fight Mode), Verhaltenssignalen (Entropie der Mausbewegung) und Proof-of-Work-Challenges (hCaptcha, Turnstile). Die Client-Hints-Geschichte verbessert sich — Sec-CH-UA-Platform ist zuverlässig, Sec-CH-UA-Mobile ist für die Mobil-/Desktop-Unterscheidung zuverlässig, doch alles Spezifischere erfordert weiterhin ein Opt-in des Nutzers per Accept-CH. Quelle: W3C WICG — User-Agent Client Hints.