The admin key was in the page source

· · Security

Your website almost certainly talks to something else. A marketing platform that sends your newsletters. A booking system. A live chat widget. A tool that tracks who filled in a form. Each of those connections needs a credential, and the person who set it up made a decision about where to put it. If that person put it in the code your browser downloads, then every visitor to your site has a copy.

That is not a hypothetical. It is what appears to have happened to the UK's largest airport group.

What happened

In late August, Manchester Airports Group disclosed a breach affecting Manchester, Stansted, and East Midlands airports. On 2 September, the group calling itself FulcrumSec published the stolen data after MAG declined to pay, roughly 550GB covering 8.7 million people.

The interesting part is not the size. It is the way in. In its own notes, the group described finding admin keys for Iterable, the customer engagement platform MAG used, in the frontend JavaScript of all three airport websites. Frontend JavaScript is the code your browser downloads and runs when you open a page. It is not hidden. It is not protected. It is sent to everyone who visits.

The attackers were blunt about how little work this took:

"No subdomain enumeration or URL crawling necessary; any of the millions of visitors to the site could have right-clicked 'inspect' and seen the keys just sitting there, plain as day. On all three websites."

An admin key for a customer engagement platform is not a small thing. It is the credential that lets a system read and write the customer database behind the marketing. According to the leak notes, what came out included 8.7 million customer profiles with names, emails, mobile numbers, home towns, postcodes, and home IP addresses, around 2.5 million purchase records covering every parking, lounge, and Fast Track booking, more than 461,000 text messages containing booking dates, car park details, and vehicle registrations in plain text, and 108,000 unique number plates. Have I Been Pwned has since added the breach with 8,728,451 accounts.

The group also claimed to hold data on roughly 191,000 future bookings, including travel dates and vehicle details, and said it withheld that part from the public leak. MAG's claims and the attackers' claims have not been fully reconciled, and MAG has said passenger safety and aviation security were not affected.

Why this is your problem too

It is tempting to read this as a story about a large organisation with a large budget getting it wrong. The more useful reading is that the mistake is completely ordinary, and smaller businesses make it more often, not less.

Think about how these credentials get into a website. Somebody needs to wire the site up to a mailing platform, a booking tool, or an analytics service. The documentation shows a snippet of code with a key in it. The snippet goes into the page. It works. Nobody looks at it again for three years.

Most platforms of this type issue two kinds of key: a public one, meant to sit in a web page and permitted to do almost nothing, and a private or admin one, meant to stay on a server and permitted to do a great deal. They often look identical. Putting the wrong one in a web page is a single-character difference in a config file and produces no error at all, because the wrong key works perfectly. It just also works for everyone else.

This is the same failure as the leaked key that emptied a charity CRM last month, arriving through a different door. There, a key ended up in published build files. Here, it went straight into the page. The lesson holds either way: a secret that reaches the browser is not a secret.

What to do this week

You do not need a security team or a budget to check this. You need a browser.

  • Look at your own site. Open your website, press F12 or right-click and choose Inspect, and open the Network tab. Reload the page. You are looking at every file your site sends to visitors. Search those files for the words key, token, secret, and api. Most sites will have something. The question is what it is.
  • Ask your web developer one question. "Which third-party services does our site connect to, and for each one, is the key in the page or on the server?" A competent answer names the services and confirms that anything sensitive is server-side. A vague answer is itself the finding.
  • Check what each key can actually do. Log into the marketing or booking platform and look at the API keys section. Most now distinguish between public and private keys, and many show when a key was last used. If a key in your website has write access to your customer list, it is the wrong key, whatever else is true.
  • Rotate anything that looks wrong, then investigate. Changing a key stops it working immediately. That is the one action that ends the risk now rather than after the investigation. Rotate first, work out the history afterwards.
  • Write down which suppliers hold your customer data. MAG's customers did not choose Iterable. They gave their details to an airport. Under UK data protection law, the business collecting the data answers for what happens to it, whichever platform is holding it. If you cannot list the third parties holding your customer records, that list is the first thing to build.

The reassuring part of this incident is how little skill it required to exploit, because the same is true in reverse: it takes very little skill to check. Ten minutes with your browser's developer tools tells you whether you have the same problem.

How Steelwise can help

Working out which services your website talks to, what credentials each one uses, and which of those are visible to the public is a short, well-defined piece of work. Get in touch if you would like someone to look at yours.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.