Notable client-side card theft incidents and what they teach

About this article

This is a summary of public sources, written for education. Facts, dates and amounts are stated as the cited sources give them, and where only secondary reporting is available we say so. We do not assert anything beyond what those decisions and reports state. Companies named here have in some cases disputed aspects of the findings; read the original documents listed in the references for the full picture.

British Airways (2018): a JavaScript file on the airline's own site

In a penalty notice dated 16 October 2020, the ICO fined British Airways £20 million under data protection law for a 2018 incident in which payment card details entered on the airline's website were copied to an attacker. According to the notice, this happened without interrupting the normal booking and payment process, and the notice describes the attacker altering a JavaScript file on the airline's site so that card data was sent to a domain the attacker controlled. The ICO estimated that the personal data of approximately 429,612 individuals was potentially accessed.

British Airways notified the ICO on 6 September 2018. The ICO had first announced an intention to fine British Airways £183.39 million on 8 July 2019; the final amount was lower after the ICO considered the company's representations, mitigating factors and the economic impact of Covid-19 on the airline sector. The 2019 statement said the attack was thought to have begun in June 2018.

What it teaches: the altered file was part of the airline's own site, so attackers do not only target third-party code. It also shows that the regulatory consequences of a skimming incident can be very large, and that the ICO examined the security measures that were in place around the page.

Ticketmaster UK (2018): a third-party chatbot script

On 13 November 2020 the ICO fined Ticketmaster UK Limited £1.25 million. The ICO's findings concerned a chatbot, supplied and hosted by a third party, that Ticketmaster had included on its online payment page. Malicious code in the chatbot's JavaScript captured data entered on the page, including names, payment card numbers, expiry dates and security codes. Up to 9.4 million customers across Europe, including about 1.5 million in the UK, were potentially affected.

The penalty relates to the period from 25 May 2018, when the GDPR took effect, to 23 June 2018, when the chatbot was removed from the site. Law-firm summaries of the notice report that the ICO regarded the risk of third-party scripts on payment pages as well known, and pointed to measures that could have been used, such as Subresource Integrity or keeping the chatbot off the payment page. Ticketmaster has said it would appeal, and its position is that the supplier was responsible for the compromise; we have not verified the outcome of any appeal.

What it teaches: a script that has no obvious connection to payments, here a customer-service widget, was loaded on the page where cards are entered. That is exactly the situation that PCI DSS 6.4.3 addresses by asking for an inventory with a written reason for every script. See third-party JavaScript risk.

Newegg (2018): a short skimmer on the checkout page

In September 2018, researchers at Volexity and RiskIQ reported a skimmer on the billing page of the electronics retailer Newegg. According to their analysis, as relayed in secondary coverage, card details entered on the checkout were exposed between 14 August and 18 September 2018, about five weeks. The attackers had registered a look-alike domain, neweggstats.com, on 13 August, the day before the skimmer was added, and the skimmer sent form data to it. The code was reported to be very short, and it was placed so that it ran only on the payment processing page. The number of affected customers was not publicly confirmed.

Researchers linked the campaign to the group of activity known as Magecart.

What it teaches: a skimmer can be a handful of lines, can run only on the page that matters, can send data to a domain that looks like an ordinary statistics service, and can run for weeks. It was found by outside researchers rather than by the retailer's own monitoring.

Lessons that apply to every payment page

1. Look at the page the customer's browser gets. In all three cases the harmful code ran in browsers. Checks of servers and repositories would not have shown it.
2. Every script on a payment page needs a reason. A chatbot or a statistics helper does not need to see card numbers. Remove, isolate or justify each one.
3. Restrict where data can go. A Content Security Policy that limits script sources, and the addresses a page may send data to, makes both loading a skimmer and sending data out harder.
4. Detect change quickly. Weeks passed in the incidents above. Detection that compares the page with an approved baseline shortens the exposure; see how to detect client-side tampering.
5. Regulators and card brands notice. The ICO decisions examined whether appropriate security measures had been in place, not only whether the attack happened. These and similar cases are part of the background to the attention that client-side security now receives in PCI DSS; see why requirements 6.4.3 and 11.6.1 exist.