_abck is the cookie Akamai Bot Manager writes on a site's own domain to carry bot-detection state. Akamai's edge sets it on the first response, before any script runs, and rewrites it after every post from the sensor script the page loads. The value is a 32-character id, a number, and a long signed block that grows with each post. That number was -1 in every session we watched, including sessions that were never blocked, so it is not a pass or fail flag you can read. A proxy changes one input, the reputation of your address. It does not change the browser check, the cookie check or the sensor. In our test a plain HTTP client was refused from the same connection that served a real browser.
Everything below was measured on 2 September 2026 in a fresh Chrome 151 on Windows 11, on the public pages of easyJet, which publishes its Akamai use, and on Akamai's own website. The full logs sit in our research folder, with every cookie value reduced to its shape.
What does the _abck cookie look like in DevTools?
Open the site, press F12, and go to Application, then Storage, then Cookies, then the site's origin. That is the path Google's DevTools documentation gives, last updated 5 December 2023. In Firefox the same table sits in the Storage Inspector under Cookies. Do not read the Value column first. Read Domain, Expires, Size, HttpOnly and Secure, because those five tell you what kind of cookie you are looking at.
The panel above shows six Akamai cookies next to the airline's own. Together they weighed 4,128 bytes, which every request to the domain now carries. RFC 6265 asks browsers to store at least 4,096 bytes per cookie, so the size is legal, and it is the largest thing in the jar.
| Cookie | Written by | Lifetime as sent | Expiry | Secure | HttpOnly | Size |
|---|---|---|---|---|---|---|
_abck | edge header, then every sensor answer | Max-Age 31536000 (365 days) | slides on each response | yes | no | 738 to 978 bytes |
bm_sz | edge header | Max-Age 14400 (4 hours) | fixed from the first set | no | no | 426 to 490 bytes |
bm_s | edge header, on nearly every response | Max-Age 2678400 (31 days) | slides | yes | yes | 952 to 1,084 bytes |
bm_so | edge header | Max-Age 86400 (1 day) | slides | yes | no | 542 bytes |
bm_sc | edge header | Max-Age 660 (11 minutes) | fixed | yes | no | 493 to 553 bytes |
bm_lso | page script, no Set-Cookie header | 30 days | slides | no | no | 557 bytes |
Our own session on www.easyjet.com, 2 September 2026, from the Set-Cookie headers and the cookie panel. Rabobank's cookie page (June 2026) publishes the same four lifetimes for bm_s, bm_sc, bm_so and bm_lso.
Two attributes carry the meaning. _abck has no HttpOnly flag, so the page's own scripts can read it, which the sensor needs. bm_s is HttpOnly, so no script can read it, and it was rewritten on almost every response. The Domain attribute is the registrable domain with a leading dot, .easyjet.com. RFC 6265 says a cookie with that domain goes to every host under it, which is why the same _abck shows under both easyJet origins in the panel.
What is inside the value, and what do the numbers mean?
The shape is stable across the two sites. First come 32 hexadecimal characters. Then a tilde, a number, and a tilde. Then a long block of base64-like text with URL-encoded slashes. Then further numbers separated by tildes. After the first sensor post a 10-digit Unix timestamp appears in that tail, and the block grows.
Akamai documents the cookie's existence and purpose, not its format. So the honest way to read the numbers is to say what we saw at each step.
| Moment | Size | Number after the id | Timestamp field | Refused |
|---|---|---|---|---|
| First HTML response, before any script | id plus a 460-character block | -1 | no | no |
| After the sensor script loaded | 738 bytes | -1 | no | no |
| After three sensor posts, four seconds in | 836 bytes | -1 | yes | no |
| After a reload | 828 bytes | -1 | yes | no |
| Second public page | 832 bytes | -1 | yes | no |
| After 60 seconds idle | 832 bytes | -1 | yes | no |
| After 45 seconds of mouse and scroll | 970 bytes | -1 | yes | no |
| Through a datacenter proxy, first load | 742 bytes | -1 | no | no |
Our own Chrome 151 sessions on www.easyjet.com, 2 September 2026, between 14:17 and 14:28 UTC. On www.akamai.com the number was -1 at every step as well, and no timestamp field appeared there at all.
The number after the id stayed -1 through everything we could do on a public page. Nothing was blocked. A public bug report against the Coraza web application firewall, opened on 18 May 2026, quotes a value from another site with a 0 in that position. Both numbers occur. What each one means to Akamai is not published, and a cookie with -1 was served for twelve minutes without a single refusal. Treat the number as a state Akamai reads, not as a verdict you can read.
How does Akamai set it and rewrite it?
The first HTML response set five cookies at once, at 14:17:04 UTC: _abck, bm_s, bm_sc, bm_so and bm_sz. No script had run yet. The page then loaded its sensor script from a randomised path on the airline's own hostname. That GET was answered with a new _abck in the headers. Within the next five seconds the page posted to the same path three times, with bodies between 1.9 and 5.4 kilobytes. Each post was answered with 201 Created and another fresh _abck. A second script path handled bm_s and bm_sc in the same way.
The 2018 version of this exchange is on record. A Security Stack Exchange question from 4 April 2018 describes a script at /_bm/async.js that posts to /_bm/_data and sets a cookie named _abck, seen on Marriott, Adidas, Fidelity and IHG. The paths moved. The pattern did not.
What the posts carry is stated by Akamai itself. Its security research blog wrote on 19 August 2026 that Bot Manager Premier collects "sequences of mouse events (movements, clicks, and scrolls) that are transmitted from every instrumented web page", and that its behavioural models "analyze these sequences to distinguish humans from bots". The Security Center documentation, updated 24 August 2026, calls the web path "standard telemetry": requests "that Bot Manager processes using first-party cookies to associate and transmit user behavior data". The cookie is the carrier of that state, on the site's own domain, which is why it cannot be a third-party cookie and why it grows with interaction.
Akamai's Bot Manager quick start, published in August 2020 and archived in July 2021, names the checks the edge runs. Cookie Integrity Failed "ensures that no bot operator has tampered with or is trying to replicate a Bot Manager cookie". Browser Validation "confirms that requests come from a real web browser". Session Validation "counts the number of HTML page and AJAX requests that come from a client". Web Scraper Reputation applies "a bad reputation score to IP addresses that have recently engaged in scraping activity". Behavior Anomaly Detection, Premier only, is set up "on transactional pages" through JavaScript injection. The product page adds the score: from 0 for human to 100 for bot, "starting with the very first request".
Every replacement of the cookie is ordinary HTTP. RFC 6265 says a browser stores a new cookie over an old one when the name, domain and path match. Every 201 answer carried the same name, domain and path, so the browser kept exactly one _abck and it changed under the page's feet.
Why do the cookie notices list different cookies?
Because the notices lag the deployment, and because lifetimes are the customer's setting. easyJet's cookie list names ak_bmsc, bm_sz, bm_mi and bm_sv as "set by Akamai" and gives _abck one year. Akamai's own cookie list names _abck, ak_bmsc, bm_sv and bm_sz. In our sessions on both sites, ak_bmsc, bm_sv and bm_mi never appeared. bm_s, bm_so, bm_sc and bm_lso did, and neither notice lists them. Rabobank's page, updated June 2026, is the only notice we found that lists the newer set, and it gives _abck and bm_sz one hour where easyJet gives one year and four hours. If you are auditing a site, read the Set-Cookie headers, not the notice.
What does a block look like?
A refusal is a 403 with a short page and a reference number. This is what our plain HTTP client received from www.easyjet.com at 14:20:55 UTC, from the same home connection that served a real Chrome a minute later:
HTTP/1.1 403 Forbidden
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Date: Wed, 02 Sep 2026 14:20:55 GMT
Set-Cookie: bm_s=...; Domain=.easyjet.com; Path=/; Max-Age=2678400; Secure; HttpOnly
Set-Cookie: bm_so=...; Domain=.easyjet.com; Path=/; Max-Age=86400; Secure
<HTML><HEAD><TITLE>Access Denied</TITLE></HEAD><BODY>
<H1>Access Denied</H1>
You don't have permission to access "http://www.easyjet.com/en" on this server.
Reference #18.ccb20f17.1788358855.1f03f3d7
https://errors.edgesuite.net/18.ccb20f17.1788358855.1f03f3d7
</BODY></HTML>
Three things in that capture matter. The refusal set no _abck at all, only bm_s and bm_so, so a client that never gets past this page never sees the cookie it is looking for. The middle number of the reference, 1788358855, is the Unix time of the response and matches the Date header to the second. We saw the same on www.akamai.com fifteen minutes earlier. And the reference is Akamai's key into its own logs. Akamai's community article on this exact page, dated 23 May 2024, describes it as a 403 with a reference starting 18.x.x.x, and a second article says a list of reference errors and their causes exists. That list is behind the customer login, so only the site's operator can look your number up. Our page on Access Denied, Reference #18 covers what to send them.
The status codes are not interchangeable. RFC 9110 defines 403 as the server understood the request "but refuses to fulfill it". RFC 6585 defines 429 as "too many requests in a given amount of time", with an optional Retry-After header. Akamai's product page says Bot Manager can also slow bots down and serve cached content instead of the live page. A 403 is a decision. A 429 or a slow page is a throttle.
Which symptom points to which cause?
| What you see | Most likely cause | What to check first |
|---|---|---|
| 403 with Reference #18 on the very first request | The edge refused before any script ran: address reputation, a region rule, or a client that fails Browser Validation | Load the same URL in a real browser on the same connection; if that works, the client is the problem, not the address |
| A browser works, your HTTP client does not, same connection | Browser Validation: TLS handshake, header set and order, no script execution | Compare the two requests; the address is identical, so the address is not the cause |
_abck is set but stays at -1 | Normal. Every session we watched stayed at -1 and was served | Nothing, unless a protected endpoint refuses you |
_abck changes on every response | Normal. The edge replaced it on every sensor answer and page load | Nothing; do not cache it |
| 429, or pages that crawl | A throttle, not a verdict: Session Validation counts requests per client | Slow down, honour Retry-After, spread sessions |
| Works on the homepage, refused on search, login or checkout | Behaviour detection is applied per endpoint on Premier, and those are the endpoints customers protect | Read the page's own rules; a public page tells you nothing about a protected one |
The cookie notice lists ak_bmsc and bm_sv but you see bm_s and bm_so | The notice is older than the deployment | Trust the headers |
_abck expires in an hour on one site and a year on another | Lifetimes are per customer | Read Max-Age; both are documented on customer notices |
Own measurements of 2 September 2026, RFC 9110 and 6585 for the status codes, and Akamai's quick start and product page for the detection names.
What does a proxy change, and what does it not?
We tested the address on its own. The same fresh Chrome loaded the same easyJet pages three ways: from our home connection, through a Hetzner datacenter address in Germany, and through a Bredband2 address in Sweden. Both proxies were public entries from our free proxy list, used for plain browsing. All three sessions were served every page. All three received the same cookie names, the same lifetimes, and a _abck that stayed at -1. The only difference was speed. The second page took 19 seconds through the datacenter address and under a second directly.
Then we sent a plain HTTP client with a Chrome User-Agent string from our own home address. Both www.akamai.com and www.easyjet.com refused it with the 403 above. Same address as the browser that was served. Different client.
So the address is one input, and Akamai names it: Web Scraper Reputation scores addresses "that have recently engaged in scraping activity". A residential address answers that input, and only that input. It does nothing for Browser Validation, which looks at the client, and nothing for Cookie Integrity, which looks at the cookie you carry. It cannot run the sensor, because the sensor runs in a browser. That is the whole division of labour.
The address answers
Web Scraper Reputation
a score on the address, per Akamai's quick start
Region rules
the country the session appears from
Session Validation, in part
requests are counted per client
The address cannot answer
Browser Validation
a real browser, its TLS and headers
Cookie Integrity
a cookie replicated or tampered with
Behavior Anomaly Detection
the sensor's mouse and scroll telemetry
One practice follows from the cookie itself. _abck lives one year on the domain, bm_sz four hours, bm_s 31 days, and all of them were rewritten as we browsed. Akamai's Cookie Integrity check exists to catch a cookie that is copied or replayed. The safe pattern is one browser profile, one address, one session, held together for as long as the flow lasts, and rotated between flows rather than inside them. We cover the mechanics in sticky versus rotating sessions. The same shape applies on DataDome and Imperva, and your TLS fingerprint has to match the browser your User-Agent claims, because that is the Browser Validation half. For the four signals together, read how to scrape past Akamai.
If the address is the input you are missing, our residential proxies hold one address for a session and start at $0.44/GB, pay as you go. If the client is the input you are missing, no address fixes it, and we would rather say so here than after you paid.
Is the _abck cookie safe, and can you block it?
The value carries no login and nothing readable. It is a signed state that only Akamai's edge can interpret, set by the site you are visiting, on that site's domain. The sites that set it class it as strictly necessary, and easyJet's notice describes its purpose as protection "against malicious website attacks". That is the category a consent tool does not ask about, which is why it appears before any banner is answered.
Deleting it is harmless and pointless. A fresh profile received a new _abck on its first response, so a deleted cookie is back on the next page load. Blocking the sensor script is a different decision. On a site with Bot Manager Premier the behaviour signals then never arrive, and Akamai's own research says a session with zero mouse events looks like automation to its models. On a public page you will not notice. On a protected page you might.
What this page could not measure
Two sites, one day, one browser build, one connection in Germany, and a DevTools client attached during every observation. We never touched a transactional endpoint, so we never saw the cookie on a session that had to be cleared. The interaction test used synthetic mouse and wheel events, not a hand on a mouse. The two proxies are a sample of two, both from the free list's reliable end. The Bot Manager documentation behind Akamai's customer login was not used. The value format is undocumented, and this page says so rather than guessing. We will re-run the same sessions by 1 March 2027 and rewrite the states table if the cookie set or the number changes.
Sources
- Akamai Technologies, Manage Cookie Preferences, the cookie list on akamai.com, read 2 September 2026: akamai.com/legal/manage-cookie-preferences.
- Akamai Technologies, Bot Manager Quick Start, learn.akamai.com, published August 2020, Wayback Machine capture of 9 July 2021.
- Akamai Technologies, Security Center documentation, Dimensions, updated 24 August 2026: techdocs.akamai.com/security-ctr/docs/dimensions-new.
- Akamai Technologies, Terraform documentation for Bot Manager: JavaScript injection, Challenge injection rules, Detection, Define bot responses, updated 1 March 2026: techdocs.akamai.com/terraform/docs/bmgr-rc-javascript-injection.
- Michael Sparkman and Daniel McAndrew, Identifying Agentic Automation with Behavioral Telemetry, Akamai Security Research, 19 August 2026: akamai.com/blog/security-research.
- Akamai Technologies, Bot Manager product page, read 2 September 2026: akamai.com/products/bot-manager.
- Akamai Customer Community, Reference Error 18.x.x.x (Access Denied) - 403 Forbidden, 23 May 2024; About Reference Errors: What do they mean?, 17 October 2023; Security in Cookies, 6 May 2024.
- A. Barth, RFC 6265, HTTP State Management Mechanism, IETF, April 2011: rfc-editor.org/rfc/rfc6265.
- R. Fielding, M. Nottingham, J. Reschke, RFC 9110, HTTP Semantics, section 15.5.4, IETF, June 2022: rfc-editor.org/rfc/rfc9110.
- M. Nottingham, R. Fielding, RFC 6585, Additional HTTP Status Codes, section 4, IETF, April 2012: rfc-editor.org/rfc/rfc6585.
- Google, Chrome DevTools, View, add, edit, and delete cookies, last updated 5 December 2023: developer.chrome.com/docs/devtools/application/cookies.
- Mozilla, Firefox Storage Inspector, Cookies: firefox-source-docs.mozilla.org.
- easyJet, Our Group Cookie Notice, cookie list, read 2 September 2026. Rabobank, Cookies, last updated June 2026. IKEA UK, Cookie policy, May 2021.
- Stack Overflow question 57121107, What is the purpose of _abck and bm_sz?, 20 July 2019. Security Stack Exchange question 182895, Anti-bot JavaScript library identification, 4 April 2018. GitHub, corazawaf/coraza issue 1620, 18 May 2026.
- Our own measurements of 2 September 2026: four browser sessions, one interaction test and two plain-client captures, logged in the research folder for this page.
