Why Lessons from the British Airways Data Breach Are Timelier Than Ever

Browser supply chain attacks—where third-party scripts running in end users’ web browsers get injected with malicious exploits—remain an under-appreciated and under-secured threat, even as their prevalence continues to accelerate. The cautionary tale of the British Airways data breach was the first to show just how devastating these browser-side attacks can be. Airlines have remained a popular target, with EasyJet and Air Europa suffering similar attack types. But they aren’t alone. Even more recently, insurance giant Kaiser Permanente publicly announced a data breach, stemming from third-party browser scripts, that affected millions of current and former insurance members.

Protecting against this threat vector is more urgent than ever for engineers, and organizations ignoring the risk of browser supply chain breaches do so at their peril. Here’s why the British Airways incident is still so relevant to enterprise cybersecurity strategy, and what can be done to protect against similar threats.

Attackers exploited security lapses

In the British Airways breach, any customer who entered their credit car information to make a purchase on the official British Airways website had that sensitive data copied and sent to an attacker-controlled domain by a malicious browser-side script. By the time the airline finally noticed this difficult-to-detect threat, more than 400,000 customers had their personal data exposed, leading to a record setting £183 million+ fine by regulators at the UK’s Information Commissioner’s Office (ICO).

The incident’s origins have been traced to an initial incursion where attackers logged into British Airways’ systems using the stolen credentials of an employee of cargo services provider Swissport. That account lacked multi-factor authentication protection, allowing attackers to log into a Citrix remote access environment and escalate their access beyond restrictions meant to limit remote users to safe areas of the network.

The attackers then introduced tools to probe the entire network for additional vulnerabilities; they soon discovered an unencrypted plain text file that included a domain administrator’s login credentials. That gave attackers an open door to access computers and servers in the domain, change configuration settings, and manipulate network resources. They began logging into servers, discovered the login credentials of a database administrator the next day, and continued to patiently explore the data available at their leisure.

Attackers found log files with the details of 108,000 payment cards, all stored in plain text. The result of a testing feature accidentally left on, that data was never supposed to be stored, and certainly not left totally unsecured. Attackers then discovered filed that included the code of the British Airways’ site, giving them all the opportunities they needed to prepare their browser supply chain attack.

Understanding the anatomy of a browser supply chain attack

As a key focal point of their strategy, attackers purchased baways dot com, an available domain name easily misconstrued as an official web address belonging to the company. While the domain used a Lithuanian hosting provider and was hosted out of Romania, British Airways didn’t have the monitoring capable of alerting security personnel that something was awry.

Modern website development utilizes numerous scripts from third-party sources to enable the interactivity and advanced capabilities users expect. Examples of features powered by third-party scripts include everything from chatbots to marketing and analytics tools to security measures like captchas. But these scripts are particularly challenging for companies to monitor and secure, because most often they’re hosted and managed externally. A simple vulnerability or error on a third-party vendor’s side can lead to a security incident. In scenarios where such vendors lack the expertise to deliver secure code—or where business and personnel changes lead to unmaintained and unmonitored scripts—the risks can become extreme.

At the time of the breach, British Airways’ website loaded about 20 third-party scripts (30 including the booking page). Site visitors’ browsers received requests from the site to obtain and execute code from external sources. This is standard practice, and browsers aren’t designed to judge whether scripts or the endpoints they send data to are legitimate. Attackers injected malicious code into the Modernizr JavaScript library, a common script that helps detect browser features to optimize experiences. This compromised version of the script, served out by the British Airways web server, sent a copy of any customer-submitted data to the attacker’s site.

This is how, for about three weeks, all payment card information entered on the British Airways website was skimmed by attackers. Customers remained completely unaware at the time, even though it was their own browsers that sent out their sensitive information. The attackers were clever to keep the normal web experience and latency intact, making their data theft transparent to both users and security personnel for weeks.

When a third party did finally recognize and notify British Airways about the breach weeks later, the company did everything right. In less than two hours, the security team had the malicious code neutralized and the fake website blocked. Customers, banks processing payments, and the ICO received prompt notice. But the damage was done. The airline’s reputation took a hit, a record-setting regulatory penalty followed, and class-action lawsuits later settled out of court. While the penalty was later reduced in light of the company’s swift accountability (and in association with pandemic relief), this was an episode that anyone would eagerly avoid.

A harbinger of threats to come

To be clear, it’s hard to find fault with British Airways’ security in this incident: the tooling needed to reliably detect browser supply chain attacks with malicious payloads delivered via third-party scripts simply wasn’t available then. At the same time, subsequent events like the Magecart attack (impacting 17,000 sites) demonstrated that hackers found a vulnerability they liked. Even today, most organizations’ security postures lack visibility into these attacks. While general IT security protections now command unprecedented attention, the increasing threat of browser supply chain attacks remains largely under-secured, or addressed only to minimal compliance requirements.

However, security capabilities now exist to provide teams with robust defenses against these attacks. Essential to effective browser supply chain security is the ability to monitor and continuously vet the content of third-party scripts, leveraging strategies designed to remove malicious scripts instantly. Considering the dynamic nature of these attacks, one-time review or monitoring that vets only the source of scripts is simply not enough. That said, teams should choose the safest third-party sources they can, while continually verifying that trust. Teams should also practice good security hygiene and harden their environments by actively removing services and scripts from any page there they’re not needed—especially on sensitive pages such as payment portals.

An urgent security requirement

As websites utilize more and more third-party scripts to bring modernized experiences to users’ browsers, attackers will only discover more opportunities. Teams can learn the lessons of attacks like the one that befell British Airways and take steps to fully secure their browser supply chains now, or learn them the hard way.