British Airways issued a customer notification on the 6th of September describing an incident in which payment-card details for approximately 380,000 customers were stolen between the 21st of August and the 5th of September (British Airways customer communication, ba.com archived, BBC News coverage). The data taken includes name, billing address, email address, and full payment-card details (card number, CVV, expiry). Customer accounts and travel-document data were not, on BA's account, in scope. The disclosure was within the GDPR 72-hour window from BA's discovery on the 5th, which makes this the first major UK GDPR-era disclosure of a payment-card breach.
The technical mechanism, on the analysis published yesterday by Yonathan Klijnsma at RiskIQ (RiskIQ blog post on the BA breach), is a Magecart-style supply-chain script injection. The BA booking flow loaded a JavaScript file from a baways.com subdomain (rather than from BA's primary infrastructure), and that file was modified to include code that captured payment-card details from the form fields and exfiltrated them to a Magecart-operator-controlled domain (baways.com without the British Airways indicia, registered to a third party). The injection was tailored — only the BA booking flow was targeted, the script change was subtle and would not have been caught by a generic integrity check, and the exfiltration domain was chosen to look like a legitimate BA infrastructure host on casual inspection.
The Magecart cluster — which is the umbrella name RiskIQ and other research groups use for a sustained campaign of payment-skimming script injections that has been running against e-commerce sites since at least 2015 — has been growing in operational sophistication through 2017 and 2018. The Ticketmaster compromise disclosed in June (Ticketmaster customer notification, June 27) was Magecart through the Inbenta third-party-chat-widget supply-chain. The Newegg compromise that was disclosed last week is Magecart with a similar pattern. Several smaller e-commerce sites have been Magecart-compromised through various third-party-script paths. The pattern is consistent: identify a third-party script loaded by the target's checkout pages, compromise that third party's infrastructure, modify the served script to skim payment data. The structural exposure of e-commerce sites to this attack is essentially universal because almost every e-commerce site loads multiple third-party scripts (analytics, customer-engagement, A/B testing, advertising) on its checkout pages.
For the customer-organisation work, the Magecart pattern requires a particular kind of defensive posture that most customer organisations have not historically prioritised. Subresource Integrity (SRI) — the W3C specification (W3C SRI specification) — provides browser-enforced integrity verification for third-party scripts by hash. Where a script changes (which is the Magecart attack mechanism), the browser refuses to execute it. Adopting SRI requires the customer organisation to actively manage the hashes — the third-party script vendors who legitimately update their scripts have to coordinate with the customer organisation to rotate hashes — and the operational cost is real but tractable. Content Security Policy (CSP) restrictions can limit which domains scripts can be loaded from and where data can be exfiltrated to; restrictive CSP would, in many Magecart cases, prevent the exfiltration even if the skimming script ran. Server-side checkout flows that do not trust browser-side data — taking the payment-card information through a server-rendered form path with anti-tampering controls — are the more substantial architectural change but are the most defensive against this category of attack.
For the retailer in our customer portfolio (added in October 2017), the Magecart conversation is now top of the priority list. The retailer's checkout flow loads several third-party scripts and we have spent the past six days reviewing each. Two of the third-party-script vendors have been responsive about implementing SRI; one has been less so and is on a follow-up call this week. The CSP posture is being tightened. The architectural conversation about server-side checkout is on the table for Q4. Across the wider e-commerce-adjacent customers in the portfolio (the manufacturer's e-commerce subsidiary, the new financial-services client's customer-portal infrastructure), similar work is in progress.
For the GDPR-disclosure question, the BA case is a useful early data point. The 72-hour notification was met. The customer-notification language was clear about the scope, the affected data categories, and the remediation actions customers should take. The Information Commissioner's Office is investigating, and the eventual fine — if a fine is issued — will set the precedent for what GDPR-era enforcement against a UK-domiciled major data controller looks like. Several of the trade press pieces are speculating about figures in the £50 million to £500 million range based on the maximum-fine framework; my expectation is something materially below the upper end but materially above any pre-GDPR fine ever issued. The case will be a reference point for the next several years of UK data-protection enforcement.
The wider strategic point — and this is the one I am writing into the customer briefings for autumn — is that the supply-chain-script category is operationally important and is going to produce more incidents through Q4 and 2019. The defensive controls are not difficult to specify but require sustained attention to maintain in operational deployment. The customer-organisation programmes that have GDPR readiness as their primary attention focus will need, in Q4 and 2019, to broaden to include supply-chain-script integrity as a programme component. The pen-testing engagement queue is already showing the shift in customer demand; the share of engagements that include third-party-script review as an explicit scope item has roughly doubled in the past three months.