The Manchester Airports breach didn't need a hacker. It needed an API key nobody was watching

The group that took roughly 8.8 million customer records from Manchester Airports Group did not break into anything. They opened the browser developer tools on the airport website, read an API key out of the JavaScript, and used it to export the customer database directly from the marketing platform it belonged to. Security researcher Scott Helme verified the method against archived copies of the site's code. His title for the writeup says it plainly: no hacking required.

For anyone responsible for an API estate, this is the more uncomfortable kind of breach. There was no vulnerability to patch, no zero-day, no phishing email. There was a valid credential doing exactly what it was allowed to do, in a place it should never have been, for four years, while nobody watched what it could reach or where the data went.

What actually happened

MAG runs three airport websites: Manchester, Stansted, and East Midlands. Each one loaded marketing automation from Iterable, and each one shipped an Iterable API key inside the JavaScript that every visitor's browser downloaded. According to Helme's analysis, the key had been sitting in that deployed code since around June 2022 and stayed active, unchanged, for more than four years.

Two things turned an ordinary integration into a full customer export.

The first is where the key lived. Browser JavaScript is public. Anything shipped to the client can be read by anyone who opens developer tools, and a content-hashed webpack bundle is no exception. An API key is a credential, and a credential shipped to the browser is a published credential. This one was not hidden. It was served to every visitor, on every page load, for four years.

The second is what the key could do. Iterable offers restricted, browser-scoped key types for exactly this situation, and its own documentation warns against putting a server-side key in client-side code. The key MAG shipped was a server-side key with database access. Helme found it could reach 98 of the platform's 131 API endpoints, including the one that exports the entire customer list, the one that looks up any individual by email, and the ones that delete and bulk-update records. A credential that existed to attribute marketing email opens could export the whole database.

The exported data was not thin. Names, email addresses, phone numbers, postal codes, vehicle registration numbers, IP addresses, and booking references with future travel dates and times. The last item is the one a security lead should read twice: named individuals with confirmed itineraries. That data tells an attacker who is flying where and when.

Why nobody saw it leave

The detail that matters most for anyone building an API security program is not how the key got exposed. It is why the theft was invisible.

The stolen data never passed through MAG's infrastructure. The attacker held a valid Iterable credential, so the requests went straight from the attacker's own systems to Iterable's API. MAG's gateways, its logs, its perimeter monitoring: none of them were in the path. There was nothing anomalous to detect on MAG's side because nothing happened on MAG's side. The customer database left through a door that MAG's own tooling could not see.

The exposure was equally invisible upstream. The key was injected at build time, so the source repositories and the CI/CD pipeline looked clean. Secret scanners that watch commits found nothing, because the secret was not in a commit. It appeared only in the compiled output, spread across roughly 90 content-hashed JavaScript chunks that no engineer reads by hand. The credential was hiding in plain sight in the one artifact almost nobody monitors: the code that actually ships to production.

This is the shape of a modern API breach. The individual pieces were each somebody's blind spot. The repository looked clean, the gateway saw normal traffic, the marketing team saw a working integration, and the security team had no signal that a database-scoped credential was being served to the public internet. No single tool was wrong. The problem was that no tool saw the whole path from the credential to the data. It is the same blind spot behind many of the worst recent API breaches: the exploit is boring, and the visibility gap is the whole story.

Runtime visibility is the layer that was missing

Runtime visibility is knowing what your APIs are actually doing in production right now: which credentials appear in live requests, which endpoints those credentials reach, and what data moves in the responses. Every control that could have caught this breach operates there, on live traffic, not on a static scan or a periodic review.

Knowing which credentials are in use, and what they are scoped to reach, is a runtime question. A design document that says "the browser uses a restricted key" is worth nothing if the deployed bundle ships a server key instead. The only reliable source of truth is what the running system actually does: which keys appear in real requests, which endpoints those keys touch, and whether any of that matches what was intended. This is the difference between API observability and API monitoring: monitoring tells you a system is up, observability tells you what the traffic is actually doing.

Knowing where sensitive data goes is also a runtime question. An export of 8.8 million records is not a subtle event. It is a large volume of personal data leaving through an endpoint that, in normal operation, should never return the full customer list to the kind of caller that just asked for it. Continuous inspection of API traffic and its payloads is what turns that from an invisible event into an alert. Sampled logs pulled once a quarter do not catch a four-year exposure. Full, continuous visibility into every request and response does, which is what Treblle captures on every API call in real time, complete request and response payloads with no sampling.

The gap MAG had was not a missing product feature. It was the absence of a single place that could see the entire API landscape at once: every integration, every credential, every endpoint, and the data moving across them. When visibility is split across a gateway here, a marketing platform there, and a repository scanner somewhere else, the space between the tools is exactly where a credential like this one lives undetected for four years.

Governance is what keeps a marketing key from exporting a database

Runtime visibility tells you what is happening. API governance is what decides what is allowed to happen in the first place, and it is the layer that would have shrunk this breach from a full export to a non-event.

The core governance failure was blast radius: how much one leaked credential can reach. There is no business reason for a credential embedded in a public web page to hold database export, deletion, and bulk-update rights. The principle of least privilege exists precisely to make sure that a key which does leak can do as little as possible. The vendor even offered the narrower key type. Governance is the practice of enforcing that choice, and of catching the moment a database-scoped credential is used somewhere it should never appear.

Credential rotation is the same story. A key that lives unchanged for four years is a key that has outlived every person, review, and assumption that originally approved it. Governance means rotation is scheduled and verified, not left to whoever last touched the integration.

None of this is knowable from an architecture diagram. It is knowable only from the traffic. Governance that lives in a policy document describes what should be true. Governance that lives in the runtime checks whether it actually is: whether the key in production is the restricted one, whether its scope matches its job, whether it still exists after it should have been retired, and whether it is reaching endpoints that a key of its kind has no business reaching. That is why governance and security belong to the same foundation rather than living in separate reviews.

What to take from this

Treat every credential shipped to a browser as already public, because it is. Assume any key in client-side code will be read, and scope it so that reading it accomplishes nothing worth an attacker's time.

Then close the visibility gap that let this run for four years. The controls that matter are the ones watching live API traffic: which credentials are in use, what each one is allowed to reach, and what data is moving through every endpoint. A breach that never touches your own infrastructure is still your breach, and the only way to see it is to have visibility into the full path your APIs and their data actually travel, not just the parts that pass through your own front door.

MAG's attacker did not need a single exploit. The organization's own code handed over the key, and its own blind spots kept the theft invisible until 8.8 million records were already gone. The lesson is not that airports need better firewalls. It is that an API estate without runtime visibility and enforced governance is one exposed key away from the same headline.