Skip to main content
    Third-Party JavaScript / Web Supply Chain

    British Airways Magecart Third-Party Script Attack (2018)

    Breach Year

    2018

    Breach Type

    Third-Party JavaScript / Web Supply Chain

    TPRM Lesson

    Website dependencies are payment supply chain risk.

    What was the British Airways Magecart Third-Party Script Attack breach?

    The British Airways Magecart attack was a 2018 web supply chain incident in which attackers modified a third-party JavaScript library loaded by ba.com and the BA mobile app, skimming payment card data from around 380,000 transactions and triggering a £20M ICO fine under GDPR.

    On this page

    1. What Was It?
    2. What Happened?
    3. How Did It Happen Technically?
    4. Why This Was a TPRM Failure
    5. Business Impact
    6. Consequences
    7. What Most People Miss About This Breach
    8. Practical TPRM Lessons
    9. Technical Protection Checklist
    10. Final TPRM Takeaway
    11. FAQ
    12. Public Sources Reviewed

    British Airways is the case that made every board understand that the checkout page is a supply chain.

    In summer 2018 the BA website and mobile app loaded a modified JavaScript file that quietly copied every card entered at checkout to an attacker-controlled domain that mimicked baways.com.

    The ICO later found that BA had insufficient controls over the scripts running on its own payment pages and issued a £20M fine, then a record under GDPR.

    What Was It?

    A Magecart-style skimmer injected into a client-side script served from BA's own domain, exfiltrating card data to a look-alike domain.

    What Happened?

    21 August 2018. Attackers modified a JS file used by BA's payment flow.

    5 September 2018. BA disclosed the breach after 15 days of active skimming.

    2019 to 2020. ICO issued notice of intent for £183M, later reduced to £20M in October 2020.

    How Did It Happen Technically?

    • Attackers altered a third-party JavaScript file loaded by the checkout.
    • The modified script sent form data to baways.com, a look-alike domain with a valid TLS cert.
    • No Subresource Integrity or Content Security Policy prevented the modification from executing.
    • The same skimmer ran inside the BA mobile app because it loaded the same web assets.

    Why This Was a TPRM Failure

    • Client-side scripts unmanaged. Third-party JS on the payment page had no integrity controls.
    • No CSP. The browser had no policy to reject exfiltration to an unknown domain.
    • Mobile app inherited web risk. Web assets loaded inside the app carried the same skimmer.
    • Slow detection. 15 days of active skimming before discovery.
    • Vendor script inventory missing. BA could not enumerate every script running on checkout.

    Business Impact

    • Around 380,000 transactions skimmed.
    • £20M ICO fine, then a GDPR record.
    • Class action settlement in the UK covering hundreds of thousands of claimants.
    • Industry-wide adoption of CSP, SRI and script monitoring on payment pages.

    Consequences

    The case established that payment-page JavaScript is a regulated supply chain and that ICO would price weak client-side controls at GDPR scale.

    What Most People Miss About This Breach

    The malicious script was served from BA's own domain. The vendor risk was not who wrote the script; it was who could change it.

    Practical TPRM Lessons

    1. Inventory every script on any payment page.
    2. Enforce Content Security Policy with an allowlist of exfil destinations.
    3. Use Subresource Integrity on all third-party JS.
    4. Monitor client-side script changes as a security event.
    5. Do not load web assets inside mobile checkouts without the same controls.
    6. Register defensive look-alike domains for payment brands.
    7. Contract vendors for script change notification.
    8. Rehearse notification within 72 hours to meet GDPR.

    Technical Protection Checklist

    A. Identity and Access. MFA and change control on any account able to modify checkout JS.

    B. SaaS and API Integrations. Full inventory of third-party scripts on payment pages.

    C. Software Supply Chain. SRI hashes pinned for every external script.

    D. File Transfer and Data Exchange. CSP allowlist restricts card-data exfil paths.

    E. Data Protection. Tokenize card capture with hosted fields where possible.

    F. Vendor Incident Response. Contractual script-tampering alerts from CDN and tag manager.

    G. Fourth-Party Risk. Map every dependency loaded by the checkout, not just the top-level tags.

    H. Board and Executive Reporting. Client-side skimmer risk reported quarterly.

    Final TPRM Takeaway

    "Your checkout is a supply chain. Every script on it is a vendor."

    Frequently Asked Questions

    What was the British Airways Magecart attack?

    A 2018 web supply chain skimmer that exfiltrated card data from 380,000 BA transactions via modified client-side JavaScript.

    Why is it considered a third-party breach?

    The malicious change hit a script that the payment page depended on, with no integrity control.

    How did it happen?

    Attackers modified a JS file loaded by the checkout so that it copied form data to a look-alike domain.

    What was exposed?

    Payment card data, cardholder names and addresses for around 380,000 transactions.

    What was the impact?

    £20M ICO fine, class-action settlement and industry-wide adoption of CSP and SRI.

    What controls could have reduced the risk?

    CSP, SRI, script inventory, tag-manager change alerts and hosted card-capture fields.

    What should TPRM teams learn?

    Client-side JavaScript is in scope for payment TPRM and needs vendor-grade change control.

    What is the biggest lesson?

    The checkout is a supply chain. Every script on it is a vendor.

    Public Sources Reviewed

    All claims in this case study are grounded in verified public reporting.

    Back to All Case StudiesExplore the Free TPRM Platform

    TPRM Blog

    Related TPRM analysis from the blog

    Continue learning with the latest breach alerts, regulatory updates, and analyst playbooks from blog.learntprm.com.

    Visit blog.learntprm.com
    Safe Security - founding sponsor of LearnTPRM.comFounding Sponsor
    For CISOs, TPRM leads and vendor risk program owners

    Autonomous TPRM. 90% less manual effort.

    Almost every case here was findable before it happened

    Read enough third-party breaches and the pattern is brutal: an undisclosed fourth party, an expired certification, an exposure that sat on the internet for weeks. Nobody was lazy - the signals simply arrive faster than a human review cycle. The SAFE TPRM AI Co-Worker watches for them continuously.

    This is for you if you own a third-party risk program - roughly 100+ vendors, quarterly reassessments, DORA / NIS2 / OCC pressure and no new headcount coming. The link opens Safe Security's platform page, not a gated form.

    Five correlated data dimensions per vendor, refreshed continuously across the whole portfolio.

    Zero-touch due diligenceContinuous monitoring across 5 dimensionsAI-powered risk scoring workflows
    • The Fourth-Party Discovery agent finds the undisclosed downstream provider before it becomes your incident.
    • The Outside-In agent detects new vulnerabilities, misconfigurations and breaches as they surface.
    • The Threat Intel agent tracks leaked credentials, filings and legal events per vendor.
    Evaluate SAFE for my organization

    For security and risk leaders assessing a TPRM platform. Opens safe.security in a new tab.

    25+

    AI agents

    90%

    Less manual effort

    None

    Additional headcount

    200+

    Organizations globally

    End to end

    Intake to offboarding

    Just here to learn? Read how Safe Security sponsors LearnTPRM

    Ready to Prove You're a TPRM Warrior?

    Most people talk about risk management. Few can prove their expertise under pressure.

    Start Your Free Certification