British Airways Magecart Attack: When Third-Party JavaScript Becomes a Weapon

Between August 21 and September 5, 2018, anyone who made a booking on the British Airways website or mobile app had their payment card details silently stolen. The attack, attributed to the threat group known as Magecart Group 6, compromised 380,000 payment card transactions through a technique called digital skimming — injecting malicious JavaScript into the airline's payment pages. The breach led to the largest GDPR fine proposed at the time and remains one of the most significant examples of third-party code risk in web application security.

How the Attack Worked

Security researchers at RiskIQ, who first publicly analyzed the attack, found that the attackers had modified a JavaScript library called Modernizr that was loaded on the British Airways website. Modernizr is a widely used open-source feature-detection library — its presence on the site was entirely normal. But the attackers injected just 22 lines of malicious code into BA's copy of the library.

This injected script was highly targeted. Rather than casting a wide net, the code was specifically designed to capture data from the BA payment form. When a customer entered their name, address, payment card number, expiry date, and CVV on the payment page, the skimmer captured every keystroke and sent the data to a server controlled by the attackers at the domain baways.com — a domain registered specifically for this attack and designed to blend in with legitimate British Airways infrastructure.

The attack was notable for its precision. Unlike many Magecart campaigns that use generic skimming scripts, this code was custom-built for the British Airways website and mobile application, suggesting the attackers had spent time studying the site's structure before deploying their payload.

The Scale of the Breach

British Airways disclosed the breach on September 6, 2018, one day after it was detected. The airline initially reported approximately 380,000 payment card details had been compromised. The stolen data included:

• Customer names
• Email addresses
• Payment card numbers, expiry dates, and CVV codes
• Billing addresses

Critically, passport and travel booking details were not compromised in this attack — the skimmer was limited to the payment page. However, the theft of CVV codes (which merchants are prohibited from storing under PCI DSS) confirmed that the data was stolen in transit, as customers entered it, rather than from a stored database.

Regulatory Consequences: A Landmark GDPR Fine

In July 2019, the UK Information Commissioner's Office (ICO) announced its intention to fine British Airways £183.39 million — equivalent to 1.5% of BA's global annual turnover — for violations of the General Data Protection Regulation (GDPR). At the time, it was by far the largest GDPR penalty ever proposed.

The ICO's investigation found that BA had failed to implement adequate security measures. Specifically, the regulator cited poor security around logging, monitoring, and the handling of third-party JavaScript on the airline's payment pages. The ICO concluded that BA "should, at that time, have been aware of the attack and could have resolved it."

However, in October 2020, the ICO issued a reduced final penalty of £20 million. The reduction reflected the economic impact of the COVID-19 pandemic on the airline industry, BA's cooperation with the investigation, and improvements the airline had made to its security posture since the breach.

Magecart: A Growing Third-Party Threat

The British Airways attack was part of a broader campaign by Magecart groups, a loose collection of cybercriminal organizations specializing in digital payment card skimming. Magecart attacks have targeted thousands of e-commerce websites by injecting malicious code into third-party scripts, tag managers, and analytics libraries. Other high-profile Magecart victims include Ticketmaster (via the Inbenta third-party chat widget), Newegg, and numerous online retailers.

What makes Magecart attacks particularly dangerous from a vendor risk perspective is that the malicious code often enters through third-party supply chains. A single compromised advertising script, analytics tag, or social media widget can be used to skim payment data across hundreds of websites simultaneously.

Implications for Third-Party Risk Management

The BA breach underscores several critical lessons for vendor risk management programs:

• Inventory all client-side third-party code. Organizations must maintain a complete inventory of every JavaScript library, analytics tag, and third-party widget loaded on their web properties, especially on pages that handle sensitive data.
• Implement Content Security Policy headers. CSP allows organizations to whitelist approved script sources and block unauthorized code execution, providing a critical defense against injection attacks.
• Use Subresource Integrity (SRI). SRI hashes ensure that externally loaded scripts have not been tampered with, alerting the organization if a third-party file changes unexpectedly.
• Monitor for unauthorized changes. Continuous monitoring of JavaScript resources on payment pages can detect Magecart-style modifications before they result in large-scale data theft.
• Isolate payment processing. Using iframes or tokenization solutions to isolate the payment form from the rest of the page limits the ability of injected scripts to access card data.

The British Airways Magecart attack remains a watershed moment for third-party risk management. It demonstrated that in the modern web, every line of JavaScript on a page represents a potential vendor dependency — and a potential attack surface. Organizations that fail to account for client-side supply chain risk in their TPRM programs are leaving their customers exposed to the same type of attack that cost BA £20 million in fines and immeasurable reputational damage.