Akamai Bot Manager Cookies erklärt: _abck, ak_bmsc, bm_sz, bm_sv

Mit den Cookies des Akamai Bot Manager hält Akamai fest, was es über Ihren Client bereits entschieden hat. bm_sz kommt zuerst, meist mit der ersten HTML-Antwort, und lebt etwa vier Stunden. ak_bmsc und bm_sv sind kurze Session-Cookies mit rund zwei Stunden Laufzeit. _abck ist das persistente Cookie, typischerweise für ein Jahr gesetzt: Es hält fest, ob die clientseitigen Prüfungen Ihres Browsers akzeptiert wurden. Die Werte sind verschlüsselt und nicht dokumentiert. Ablesen lässt sich, welche Cookies Sie besitzen, wann sie sich ändern und ob sie bei einem Client auf einer IP bleiben.

Die Cookies des Akamai Bot Manager im Überblick

Akamai veröffentlicht keine feldgenaue Spezifikation dieser Cookies. Die verlässlichsten öffentlichen Informationen stammen aus Cookie-Offenlegungen: Akamais eigener Produktdokumentation und Cookie-Seiten sowie den Cookie-Richtlinien von Websites, die Bot Manager einsetzen. Die folgende Tabelle führt sie zusammen. Wo sich Quellen widersprechen, steht das in der Tabelle.

Quellen: Die Cookie-Liste des RIPE NCC führt alle fünf als unbedingt erforderlich, mit 1 Jahr für _abck, 4 Stunden für bm_sz und 2 Stunden für ak_bmsc, bm_sv und bm_mi. cookie.is nennt dieselben Laufzeiten für _abck, bm_sz, ak_bmsc und bm_sv. Akamais Cookie-Tabelle für Identity Cloud liefert die Beschreibung von bm_sv und die Flags HttpOnly/Secure/SameSite für ak_bmsc und bm_sv. Akamais eigene Seite zu Cookie-Einstellungen ordnet _abck, ak_bmsc und bm_sv als unbedingt erforderlich und bm_sz als Performance-Cookie ein.

Zwei praktische Hinweise. Erstens wird jedes dieser Attribute pro Deployment gesetzt; die Laufzeiten oben sind also typisch, nicht garantiert. Lesen Sie die tatsächlichen Set-Cookie-Header der Website, mit der Sie arbeiten. Zweitens setzen neuere Deployments zusätzliche Cookies, deren Namen Sie in den DevTools sehen können. Eine verlässliche öffentliche Beschreibung haben wir dafür nicht gefunden, deshalb fehlen sie hier.

_abck: das Cookie, das das Urteil trägt

_abck ist das persistente Cookie, das widerspiegelt, ob Ihr Browser Akamais clientseitige Prüfungen bestanden hat. Es wird zunächst in einem unvalidierten Zustand ausgegeben und dann vom Server jedes Mal neu geschrieben, wenn das Bot-Manager-Skript Daten meldet. Es läuft typischerweise nach einem Jahr ab, doch der „validierte“ Zustand darin hält deutlich kürzer als das Cookie selbst.

Sein Wert ist eine lange verschlüsselte Zeichenkette mit durch Tilden getrennten Abschnitten. Diskutiert werden nur kurze Marker wie ~-1~ und ~0~. Betrachten Sie das Folgende als Beobachtung aus der Community. Akamai hat diese Marker nie dokumentiert, und eine ausführliche Analyse, die von Scrapfly, rät ausdrücklich davon ab, überhaupt feste Felder aus dem Wert abzuleiten. Die Lesart, auf die sich unabhängige Quellen einigen, ist ungefähr diese:

• ~-1~ an der frühen Position: Der Client hat die clientseitige Prüfung noch nicht erfüllt. In diesem Zustand kommt ein frisches _abck an, und darin bleibt es, wenn nie akzeptable Telemetrie eintrifft.
• ~0~ an dieser Position: Die Prüfung ist vorerst erfüllt. Gängig ist die Beschreibung als clientseitiges „Stoppsignal“, das dem Seitenskript mitteilt, dass es keine Telemetrie mehr senden muss.
• Ein validiertes Cookie kann zurückgesetzt werden. Geschützte Endpunkte können ein neues _abck ausgeben, das Sie in einen unvalidierten Zustand zurückversetzt, etwa vor einem Login oder Checkout.

Die Analyse von Crawlex kommt zur selben Lesart und betont, dass sie „entirely from people watching the cookie change“ stammt. Die wichtige Konsequenz ist, was ~0~ nicht bedeutet: Es ist kein Zugangsticket. Akamai bewertet weiterhin jede Anfrage nach IP-Reputation, Protokoll-Fingerprints und Anfragemustern, und ein ~0~-Cookie, das von einem anderen Client oder Netzwerk vorgelegt wird, kann scheitern. Akamais eigener Bot-Manager-Quickstart nennt eine Erkennung namens Cookie Integrity Failed, die „ensures that no bot operator has tampered with or is trying to replicate a Bot Manager cookie“. Ein kopiertes _abck ist also genau das, was das System abfangen soll.

Weil das Seitenskript diesen Marker liest, ist _abck in der Regel nicht HttpOnly; meist sehen Sie es in document.cookie. Eine Aussage von Akamai dazu haben wir nicht gefunden, prüfen Sie es also auf der Website, die Sie testen.

bm_sz: der Session-Seed

bm_sz wird meist schon mit der allerersten HTML-Antwort eines geschützten Hosts gesetzt, bevor irgendein Bot-Manager-JavaScript gelaufen ist, und hält etwa vier Stunden. Technische Analysen wie die bm_sz-Analyse von Crawlex beschreiben es als den sitzungsspezifischen Input, mit dem das clientseitige Skript arbeitet. Deshalb macht ein bm_sz aus einer anderen Sitzung oder von einem anderen Origin alles Folgende kaputt. Erhält ein Client nie ein bm_sz, lief die geschützte Seite wahrscheinlich gar nicht durch Bot Manager – beim Debuggen eine nützliche Information.

ak_bmsc: das kurzlebige Session-Cookie

ak_bmsc ist ein Session-Cookie mit etwa zwei Stunden Laufzeit. Offenlegungen beschreiben es als Unterscheidungsmerkmal zwischen Menschen und Bots, und Akamais Identity-Cloud-Doku beschreibt es zusätzlich als „used to optimize performance“. Beim HttpOnly-Flag sind sich die Quellen uneinig. Akamais eigene Identity-Cloud-Tabelle sagt HttpOnly: false, mehrere Scraping-Blogs sagen, es sei HttpOnly – vermutlich unterscheidet sich die Einstellung je nach Deployment. Verschwindet es mitten in der Sitzung, sind meist zwei Stunden vergangen oder Ihr Client hat Cookies verworfen.

bm_sv und bm_mi

bm_sv ist das einzige Cookie, das Akamai direkt beschreibt („used by Akamai Bot Manager to help differentiate between web requests generated by humans and web requests generated by bots or other automated processes“). Es hält etwa zwei Stunden. Akamais Quickstart nennt außerdem eine Erkennung namens Session Validation, die „counts the number of HTML page and AJAX requests that come from a client“. Die Benennung legt eine Verbindung zu bm_sv nahe, öffentlich bestätigt ist sie aber nicht, verlassen Sie sich also nicht darauf. bm_mi taucht in den Offenlegungen mancher Deployments mit zwei Stunden Laufzeit und ohne weitere Details auf.

Wie der Sensor-Ablauf konzeptionell funktioniert

Bot Manager arbeitet in Schichten. Die Edge bewertet jede Anfrage für sich, und eine JavaScript-Schicht im Browser liefert clientseitige Indizien, die in _abck festgehalten werden. Akamais Quickstart nennt die wichtigsten Erkennungen:

• Imitatoren bekannter Bots: gefälschter Googlebot und Ähnliches.
• User-Agent-basierte Erkennung und Erkennung von Anfrageanomalien: Inkonsistenzen innerhalb einer Anfrage.
• Web-Scraper-Reputation: „a bad reputation score to IP addresses that have recently engaged in scraping activity“.
• Cookie-Integrität, Session-Validierung und Browser-Validierung: „confirms that requests come from a real web browser“.
• Erkennung von Verhaltensanomalien: nur Premier, auf transaktionalen Endpunkten wie Login und Checkout.

Akamais aktuelle Seite zu Erkennungsmethoden beschreibt dieselbe Aufteilung: Die transparente Erkennung fängt „out-of-order headers and browser version mismatches“ ab, während die aktive Erkennung „employ[s] an interaction to confirm the request is coming from a web browser“.

Der Lebenszyklus der Cookies ergibt sich aus diesem Design:

1. Die erste Antwort eines geschützten Hosts setzt bm_sz und ein unvalidiertes _abck, und die Seite lädt Akamais Skript.
2. Das Skript sammelt im Browser Client-Signale (Umgebung, Timing und auf manchen Seiten Interaktion) und sendet sie an einen First-Party-Endpunkt derselben Website.
3. Akamai bewertet die Übermittlung zusammen mit den Signalen auf Anfrageebene und antwortet mit einem Set-Cookie, das _abck aktualisiert.
4. Spätere Anfragen tragen die Cookies. Die Edge prüft, ob sie intakt sind, zu dieser Sitzung gehören und zum Rest dessen passen, was sie sieht.

Nicht Gegenstand dieses Artikels: Wir beschreiben weder den Sensor-Payload noch, wie man ihn erzeugt oder Cookie-Werte konstruiert. Gefälschte Akamai-Telemetrie ist genau das, wofür Cookie Integrity und verwandte Erkennungen existieren, und dabei helfen wir nicht. Für das größere Bild der Signale, einschließlich TLS- und HTTP/2-Fingerprints, siehe unseren Deep-Dive zum Akamai Bot Manager.

Warum reine HTTP-Clients auf einem ungültigen _abck sitzen bleiben

Eine HTTP-Bibliothek wie requests, httpx oder Gos net/http führt kein JavaScript aus. Das Bot-Manager-Skript läuft also nie, und nichts aktualisiert jemals _abck. Der Client sendet weiter das unvalidierte Cookie aus der ersten Antwort. Auf Seiten, auf denen Akamai eine Browser-Validierung verlangt, ist genau das das erwartbare Ergebnis.

Ein korrigiertes TLS ändert daran nichts. Eine Impersonation-Bibliothek kann Handshake und HTTP/2-Frames wie Chrome aussehen lassen, aber sie kann nicht die clientseitigen Indizien erzeugen, die das Skript geliefert hätte. In der Praxis passiert meist Folgendes: Seiten, die nur die transparente Schicht nutzen, funktionieren weiter, während Seiten mit aktiver Validierung (Logins, Warenkörbe, auf manchen Websites Such-APIs) 403-Fehler oder Challenge-Seiten liefern.

Klären Sie vor der Wahl Ihrer Werkzeuge, welche Seiten Sie tatsächlich brauchen. Viele öffentliche Daten sind ohne die aktive Schicht erreichbar, und die offizielle API oder ein Datenfeed der Website ist oft die bessere Antwort als Browser-Automatisierung.

Was ein echter Browser auf einer sauberen, konsistenten Verbindung anders macht

Ein echter Browser führt das Skript aus, behält seine Cookies, sendet einen einheitlichen TLS- und HTTP/2-Fingerprint und bleibt die ganze Sitzung über im selben Netzwerk. Genau diese Kombination bringt _abck in den validierten Zustand und hält es dort. Jeder Teil zählt:

• Behalten Sie den Cookie-Jar für die gesamte Sitzung. Wenn Sie zwischen Anfragen Cookies verwerfen, sieht jede Anfrage wie ein Erstbesuch aus: neues bm_sz, unvalidiertes _abck, und das Skript muss erneut laufen. In Playwright entspricht ein Browser-Kontext einem Cookie-Jar. Öffnen Sie nicht pro Seite einen neuen Kontext.
• Behalten Sie pro Sitzung eine Exit-IP. Cookies, die einer Sitzung auf einer IP ausgestellt und von einer anderen wieder eingespielt werden, sehen nach genau der Replikation aus, die Cookie Integrity abfangen soll. Rotieren Sie IPs mitten in der Sitzung, passen die Cookies nicht mehr zu dem Netzwerk, auf dem sie ausgestellt wurden. Nutzen Sie für alles mit Zustand (Durchblättern einer Kategorie, Warenkorb, eingeloggter Ablauf) eine Sticky Session und rotieren Sie nur zwischen Sitzungen. Wie man sie dimensioniert, erklärt unser Leitfaden zu Sticky vs. rotierenden Sessions.
• Starten Sie mit einer sauberen IP. Die Web-Scraper-Reputation wird pro IP bewertet. Ein Datacenter-Bereich mit Scraping-Vorgeschichte steht unter Verdacht, bevor überhaupt ein Cookie gesetzt ist. Residential- und Mobile-IPs haben andere Ausgangsreputationen; wie diese Scores entstehen, erklärt unsere Analyse zur IP-Reputation.
• Fragen Sie in einem für Menschen plausiblen Tempo an. Session Validation zählt buchstäblich HTML- und AJAX-Anfragen pro Client. Ein gültiges _abck rettet keine Sitzung, die Hunderte Seitenaufrufe pro Minute erzeugt.

Ein minimales Playwright-Setup, das diese Regeln einhält, sieht so aus: ein persistenter Kontext, ein Sticky-Residential-Exit und gespeicherter Zustand, damit der nächste Lauf dieselbe Sitzung fortsetzt, statt neu zu beginnen:

from pathlib import Path
from playwright.sync_api import sync_playwright

STATE = Path("state.json")
PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "USERNAME-sid-abc123-ttl-10m",   # sticky: dieselbe Exit-IP für diese Sitzung
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY)
    context = browser.new_context(
        storage_state=str(STATE) if STATE.exists() else None
    )
    page = context.new_page()
    page.goto("https://www.example.com/", wait_until="load")
    # ... wenige Navigationen, in menschlichem Tempo ...
    names = sorted(c["name"] for c in context.cookies())
    print(names)                                # zeigt, welche Akamai-Cookies Sie haben
    context.storage_state(path=str(STATE))      # Jar für den nächsten Lauf behalten
    browser.close()

Koppeln Sie den gespeicherten Zustand an seine Session-ID. Setzen Sie state.json über eine andere Exit-IP fort, erzeugen Sie genau das IP-Wechsel-Problem, das Sie vermeiden wollten.

Fehlersuche: Symptom, wahrscheinliche Ursache, was zu prüfen ist

Prüfen Sie jeweils nur eine Variable. Die meisten Meldungen à la „Akamai blockiert mich“ entpuppen sich als einer der ersten drei Fälle. Eine wenig hilfreiche, aber ehrliche Antwort gehört ebenfalls in diese Tabelle: Manchmal hat die Website entschieden, auf diesem Pfad keinen automatisierten Traffic zu bedienen, und die richtige Reaktion ist, aufzuhören oder um Zugang zu bitten.

Für Website-Betreiber: diese Cookies in den eigenen Logs lesen

Wenn Sie Bot Manager betreiben, loggen Sie die Cookie-Namen und den Statusmarker von _abck, nicht die Werte, und treffen Sie Entscheidungen auf Basis von Akamais eigenen Bot-Ergebnissen. Die Werte sind verschlüsselt, und das Format kann sich ohne Ankündigung ändern. Muster, die ein normales Access-Log hergibt:

• Anfragen an tiefe URLs ganz ohne bm_sz oder _abck. Das sind cookielose Clients: entweder Erstaufrufe oder Werkzeuge, die Cookies verwerfen. Ein hoher Anteil auf Produkt- oder Such-URLs ohne passende Aufrufe der Einstiegsseite deutet auf skriptgesteuerten Zugriff hin.
• Derselbe _abck-Wert von vielen IPs oder ASNs. Das ist Cookie-Sharing oder Replay. Akamais Cookie-Integrity-Erkennung ist dafür gebaut. Ihre Logs zeigen, wie groß das Problem ist und welche Pfade betroffen sind.
• Sitzungen, die über viele Anfragen unvalidiert bleiben. Das sind meist Clients, die das JavaScript Ihrer Seiten nie ausführen. Prüfen Sie das, bevor Sie Regeln verschärfen, denn Datenschutz-Erweiterungen und fehlerhafte Skriptauslieferung verursachen es ebenfalls.
• Bot-Ergebnisse am Origin. Akamai kann sein Urteil als Request-Header an Ihren Origin weiterleiten. Der Integrationsleitfaden von Auth0 dokumentiert die Header akamai-bot und akamai-user-risk und verweist auf Akamais Konfiguration „Forward Bot Results to Origin“. Ein unterstütztes Feld wie dieses ist besser, als Cookie-Interna zu parsen.

Zum Datenschutz: Diese Cookies sind an ein Gerät gebundene Kennungen. Offenlegungen wie die des RIPE NCC stufen sie als unbedingt erforderlich ein, was in der EU in der Regel bedeutet, dass keine Einwilligung nötig ist. Logs, die Rohwerte zusammen mit IPs speichern, sind trotzdem personenbezogene Daten; hashen oder verwerfen Sie die Werte also, sobald Sie Marker und Namensliste haben.

Was diese Cookies Ihnen nicht verraten

Ein Cookie kann zeigen, dass die clientseitige Validierung noch nicht stattgefunden hat. Es kann nicht zeigen, dass eine Anfrage durchgelassen wird. Erkennungen auf Anfrageebene (IP-Reputation, Protokoll-Fingerprints, Header-Anomalien, Tempo) laufen unabhängig von _abck, und Website-Betreiber legen Richtlinien pro Pfad fest, die Sie von außen nicht sehen. Nutzen Sie die Cookies beim Debuggen als ein Signal und Statuscodes, Challenge-Seiten und Timing als die anderen.