PathThe anti-bot vendor landscape

Step 4 of 8

What Is Akamai Bot Manager?

Pim · Scrappey Research

May 31, 2026 4 min read

Paste into ChatGPT, Claude, or any LLM

What Is Akamai Bot Manager? — conceptual illustration

On this page

Akamai Bot Manager is an enterprise tool that websites use to tell real visitors apart from bots, and it guards roughly 30% of the Fortune 500 — airlines, banks, retailers, ticketing. It works on two fronts. At the network edge it scores your JA4+ TLS handshake (TLS is the encryption layer behind https, and the handshake leaves a fingerprint of which client you are). Then, inside the browser, it runs a fingerprinting script (sensor.js, a ~512 KB scrambled file) that gathers 500+ signals across several requests. Trust builds up over a session rather than being decided in one shot: the _abck cookie starts at ~-1~ (not trusted yet) and only flips to ~0~ once sensor.js finishes its checks. See also browser fingerprinting.

Customers	~30% of Fortune 500 — airlines, banks, retail, ticketing
Detection cookies	_abck (state ~-1~ → ~0~), bm_sz
Sensor script size	~512 KB, re-obfuscated per rotation
Distinct probe	60 chrome-extension:// fetches — zero passing = instant block
Scoring model	Multi-request, trust accumulates across the session
Commonly deployed on	Large enterprise e-commerce and media sites (e.g. StockX)

How Akamai scores a session

Akamai checks you in two layers. The first is JA4+ at the EdgeWorker — code running on Akamai's edge servers. This fires before any HTML is sent, so a suspicious TLS handshake alone can get you blocked. Clear that layer and the page loads with sensor.js built right into it (inlined or nearly so). That script runs the deeper tests: a canvas hash (a fingerprint from drawing an image), the WebGL renderer (your GPU's name), AudioContext, navigator properties, the Battery API, and a probe that tries to fetch 60 known chrome-extension:// URLs. Real Chrome users almost always have a few extensions installed (uBlock Origin, 1Password, LastPass), so some of those fetches succeed; a headless browser has none, so all 60 fail at once — something that essentially never happens for a real person.

The script then POSTs everything it collected to /_bm/data. Only after that POST succeeds does _abck flip from ~-1~ to ~0~. Protected data endpoints (the XHR calls a page makes for content) check this cookie first — if it still says ~-1~, you get a 412 "Pardon Our Interruption" no matter what else looks right.

Which signals tend to flag a client

Signals that commonly draw a flag: headless Chrome (no real GPU, so the WebGL context is null), SwiftShader (its software-GPU device ID 0x0000C0DE is widely recognised), JavaScript patches whose Function.toString() output reveals they have been rewritten, Page.addScriptToEvaluateOnNewDocument injection (the CDP automation protocol leaves visible timing artifacts), datacenter proxies of any kind, and rotating residential IPs mid-session (this wipes out the trust accumulated so far).

Signals more consistent with a real client: a TLS handshake and HTTP/2 frame order that match a mainstream browser, a session that keeps one stable IP and one set of cookies, and a browser profile that actually has the extensions and GPU a real machine would have, so the 60-probe check sees the same mix a person's browser would. These are the same coherence properties that any legitimate browser session naturally exhibits.

Session hygiene that matters

Because Akamai scores you across many requests, it penalizes inconsistency harder than most vendors do:

Use one ISP static residential IP for the whole session — never switch in the middle.
Warm up first: visit the homepage, wait 2–3 seconds, scroll, then go to the data URL.
Set Accept-Language to match the country your proxy is in.
Reuse cookies across requests — trust grows from keeping the same _abck cookie going.

Code example

python

# For medium-strength Akamai deployments, this often works
from curl_cffi import requests

s = requests.Session(impersonate="chrome131")

# Warm up on the homepage so _abck has a chance to accumulate trust
s.get("https://target.com/",
      proxies={"https": "http://user:pass@isp-residential:port"})

# Then hit the protected endpoint with the same session
r = s.get("https://target.com/api/listings",
          proxies={"https": "http://user:pass@isp-residential:port"})
print(r.status_code, len(r.text))

Next in The anti-bot vendor landscape · 5 of 8

Known for heavy client-side instrumentation.

What Is PerimeterX (HUMAN)?

Related terms

What Is TLS Fingerprinting (JA3/JA4)?

TLS fingerprinting is a way to recognize what software made a connection just by looking at how it sets up encryption — before the server re…

What Is Anti-Bot Detection?

Anti-bot detection is the set of techniques websites use to tell automated traffic apart from real human visitors — and then block, challeng…

What Is curl_cffi?

curl_cffi is a Python HTTP client whose TLS fingerprint looks exactly like real Chrome, Firefox, or Safari. TLS is the encryption layer behi…

What Is an ISP Proxy?

An ISP proxy (also called a \"static residential\" proxy) is a fixed IP address that physically sits in a datacenter but is registered to a …

Anti-Bot Vendor Detection Cheatsheet

A useful first step when working with any protected site you are authorized to access is identifying which anti-bot vendor sits in front of …

What Is a Session Cookie?

A session cookie is an HTTP cookie with no Max-Age or Expires attribute, so the browser keeps it only in memory and throws it away when the …

Concept map

How Akamai Bot Manager connects

The terms most directly tied to this one. Hover a node to see its neighbours, click to preview, drag to rearrange.

0 terms · 0 connections

You are here · Anti-Bot

Tools & solutions for this topic

Frequently asked questions

What does the _abck cookie mean?

It is Akamai's record of how much it trusts your session. The state field reads ~-1~ when you first arrive (untrusted) and flips to ~0~ after sensor.js runs and POSTs valid signals back to Akamai. Protected data (XHR) endpoints look at this state and return a 412 error if it is still ~-1~.

What is the 60-extension probe?

It is a test inside sensor.js that fires 60 fetch() requests to known chrome-extension://[id]/manifest.json URLs (uBlock Origin, LastPass, Bitwarden, and so on). Real Chrome users have at least a few extensions installed, so some of those requests succeed. A headless browser has none, so all 60 fail at the same time — a result that is statistically impossible for a real user.

Why does Akamai care more about multi-request consistency than other vendors?

Because trust builds up over the whole session instead of being judged one request at a time. Every clean interaction raises your score; every oddity lowers it. Rotating IPs partway through resets that accumulated trust. Other vendors (notably DataDome) score each request on its own, so mid-session changes hurt you less there.

Is rotating residential ever okay against Akamai?

Only between sessions, never inside one. Pick a single IP per session and keep it for the entire visit. ISP static residential is the best fit because that IP stays put and doesn't shift under you.

Last updated: 2026-05-31