TL;DR
- In 2018 konden kwaadwillenden via gestolen inloggegevens van een aannemer van British Airways een aan de clientzijde uitgevoerd script aanpassen om creditcardgegevens te exfiltreren naar een eindpunt dat door hen werd beheerd. Dat domein is baways[.]com, dat sinds 2024 eigendom is van cside.
- Op het domein baways[.]com kunt u een gedetailleerde, objectieve tijdlijn van de gebeurtenissen en de nasleep lezen.
- Na het incident was de ICO van plan British Airways een boete van £183 miljoen op te leggen, maar die werd later verlaagd naar £20 miljoen. Destijds had British Airways te kampen met moeilijkheden door Covid-19, wat mogelijk heeft bijgedragen aan de lagere boete.
- Na dit incident en vele vergelijkbare aanvallen heeft de PCI DSS (Payment Card Industry Data Security Standard) zijn vereisten bijgewerkt om monitoring, beveiliging en documentatie van scripts aan de clientzijde op te nemen.
- Vandaag de dag zijn er meer oplossingen op de markt om een dergelijk incident te voorkomen, maar de kwaliteit van de benaderingen verschilt aanzienlijk.
Waarom we baways[.]com hebben gekocht
Omdat we het konden. Verrassend genoeg, hoewel veel leveranciers voortdurend over de aanval spraken, verliep het domein dat bij de aanval werd gebruikt en was het beschikbaar voor aankoop op de openbare markt voor de standaard ICANN-vergoeding van $10,44 per jaar.
In de loop der jaren was wat er werd geschreven — onder meer op marketingpagina's van leveranciers — niet langer in overeenstemming met de feiten. Daarom zijn we er één keer voor gaan zitten om het bewijs, de rechtbankdocumenten, persberichten en gearchiveerde pagina's te verzamelen en alles in één geconsolideerd rapport te publiceren. Op het exacte domein dat bij de aanval werd gebruikt.
We hebben zelfs een voormalige journalist ingehuurd om het onderwerp te helpen onderzoeken.
![Banner van de baways[.]com-microsite.](/content/images/2025/12/Screenshot-2025-12-14-at-8.20.04---PM.png)
De tijdlijn van de British Airways-aanval:
22 juni 2018: Een aanvaller dringt het netwerk van British Airways binnen via gestolen inloggegevens van een Swissport-medewerker (een aannemer voor vrachtdiensten). Het account had geen meervoudige verificatie.
23-26 juni 2018: De aanvaller verkent het terrein. Ze ontdekken iets alarmerends: domeinbeheerdersgegevens opgeslagen in leesbare tekst. Gewoon in een bestand. Onversleuteld.
26 juli 2018: De aanvaller ontdekt logbestanden met betaalkaartgegevens. Ook in leesbare tekst. Deze waren afkomstig van een testfunctie die nooit in productie had mogen gaan.
21 augustus - 5 september 2018: De daadwerkelijke aanval gaat live. Gedurende 16 dagen werden de gegevens van elke klant die betaalgegevens invoerde op de BA-website gekopieerd en verzonden naar baways[.]com.
5 september 2018: British Airways wordt door een derde partij op de hoogte gesteld. Ze sluiten het binnen 90 minuten af.
Hoe de British Airways-aanval werkte
De aanvaller injecteerde kwaadaardige code in Modernizr, een veelgebruikte JavaScript-bibliotheek die websites helpt te werken in verschillende browsers. British Airways serveerde deze gecompromitteerde versie aan al hun klanten.
- Het kwaadaardige script wachtte tot klanten op de betalingsbevestigingsknop klikten
- Het verzamelde alle betaal- en persoonsgegevens uit het formulier
- Het stuurde die gegevens naar baways[.]com (wat legitiem leek omdat BA "BA" gebruikt in hun marketing)
- Dit alles gebeurde stilletjes op de achtergrond
- Het normale betalingsproces verliep zonder enige problemen
Waarom de British Airways-aanval onopgemerkt bleef door netwerkbeveiliging
De aanval vond plaats zonder zichtbare sporen achter te laten. De enige manier om iets ongewoons te herkennen was via de ontwikkelaarstools van de browser, in het netwerktabblad op het moment dat de gegevens werden verzonden.
Deze aanval trof ook de mobiele app, die een webview van de webapplicatie uitvoerde. De webview zelf had geen ontwikkelaarsdashboard, waardoor er in de mobiele app absoluut geen zichtbaar spoor werd achtergelaten.
Het zou uiterst moeilijk, zo niet onmogelijk zijn geweest voor klanten om te zien dat hun gegevens werden gestolen.
De schade
Tijdens de rechtbankprocedures maakte de ICO (Information Commissioner's Office) de volledige cijfers bekend.
| Categorie | Aantal getroffen personen |
|---|---|
| Volledige kaartgegevens blootgesteld | 244.000 |
| Kaart + CVV blootgesteld | 77.000 |
| Alleen kaartnummers | 108.000 |
| BA Executive Club-accounts | 612 |
| Totaal aantal getroffen personen | 429.612 |
De ICO stelde aanvankelijk een boete voor van £183,39 miljoen. Na onderhandelingen, een zorgvuldig proces en financieel onderzoek als gevolg van de impact van COVID-19 op British Airways werd de boete verlaagd naar £20 miljoen.
British Airways leed aanzienlijke verliezen en de toenmalige CEO was genoodzaakt publiekelijk zijn excuses aan te bieden en verzekerde dat getroffen klanten gecompenseerd zouden worden.
De boete is niet de enige financiële impact. Er volgden meerdere collectieve rechtszaken; publieke bronnen schatten de schadevergoedingen op tussen £2.000 en £6.000 per eiser. Met meer dan 16.000 slachtoffers die in slechts één rechtszaak vertegenwoordigd waren, overtrof de totale financiële impact waarschijnlijk de regulatoire boete, los van de commerciële schade door het aangetaste vertrouwen in het merk British Airways.
Waarom dit incident in 2025 nog steeds relevant is
Het probleem is alleen maar groter geworden. De beveiliging van webapplicaties is gericht op maatregelen ten aanzien van de webinfrastructuur. Er wordt nieuwe aandacht besteed aan het monitoren van statische open source-afhankelijkheden en de adoptie van AI binnen bedrijven. Maar webontwikkelaars en beveiligingsteams weten nog steeds niet — en beschikken ook niet over betrouwbare tools om te verifiëren — hoe hun webapplicaties en de bijbehorende afhankelijkheden zoals marketingtools en open source-pakketten zich gedragen in browsers.
Client-side runtime-monitoring had de British Airways-aanval kunnen voorkomen
Dit is een sterk dynamische aanvalsvector, dus de enige echte oplossing voor deze beveiligingsdreiging is actieve analyse tijdens runtime. Druk vanuit regelgeving heeft sommige bedrijven ertoe gebracht checklisttools te adopteren die gebruikmaken van scanners/crawlers of agentloze benaderingen. Die zijn eenvoudig te omzeilen doordat de kwaadwillende de schadelijke payloads simpelweg niet aan die tools serveert.
Echte runtime client-side beveiliging heeft nog steeds geen hoge prioriteit. Kwaadwillenden zijn zich hiervan bewust, en dagelijks vinden aanzienlijk complexe aanvallen aan de clientzijde plaats. Enkele grote recente gevallen zijn de Bybit-aanval, de CoinMarketCap-aanval en de Polyfill-aanval van 2024, die meer dan 490.000 websites trof met een vergelijkbaar script als Modernizr.
De client-side supply chain kent een aantal extra grote uitdagingen. Elk verzoek aan een externe server kan een dynamische en andere respons opleveren. Continue analyse is kostbaar, maar het is de enige manier om de beveiligingspositie te beheren.
Wat er veranderde na het British Airways-incident
Rond de tijd van het British Airways-incident vonden vele vergelijkbare incidenten plaats, zoals het Ticketmaster-datalek en de Newegg-aanval. Mastercard, Visa en American Express maakten bekend dat de grootste hoeveelheid creditcardgegevens tegenwoordig wordt gestolen via kwaadaardige scripts aan de clientzijde. Daarom werd als reactie het PCI DSS-complianceraamwerk aangepast om client-side beveiliging op te nemen in twee nieuwe nalevingsvereisten: 6.4.3 en 11.6.1. We schreven er een gedetailleerde blogpost over.
Na de aanpassing van PCI DSS verduidelijkten andere brancheraamwerken hun vereisten met betrekking tot supply chain-beveiliging om ook aan de clientzijde uitgevoerde afhankelijkheden op te nemen. Incidenten zoals het Kaiser Permanente-datalek leidden tot updates van HIPAA.
Het wordt steeds meer een basisvereiste om client-side runtime-beveiligingsoplossingen te adopteren voor het monitoren van websiteacties, maar elke nalevingsvereiste vraagt om zijn eigen geformatteerd bewijs. Sommige zijn meer gericht op cookiegebruik, andere meer op gegevensstromen. Met een oplossing als cside wordt dit echter heel eenvoudig.
Hoe cside helpt
cside biedt een zeer flexibele aanpak voor client-side beveiliging. Of we nu scriptgedrag aan de clientzijde monitoren en de scripts diepgaander analyseren via client-side rapportage op onze engine — cside krijgt het volledige beeld. Het analyseert de code van geserveerde afhankelijkheden in realtime en helpt u ongewenst gedrag te voorkomen voordat het grote zakelijke impact heeft.
Onze aanpak stelt ons niet alleen in staat geavanceerde, sterk gerichte aanvallen te detecteren en daarover te waarschuwen — cside maakt het ook mogelijk aanvallen te blokkeren voordat ze de browser van de gebruiker bereiken. Het voldoet ook aan meerdere complianceraamwerken, waaronder PCI DSS 4.0.1, HIPAA, GDPR, CPRA... We bieden zelfs diepgaande forensics, ook als een aanvaller probeert onze detecties te omzeilen. We slaan ook gegevens op over gemiste aanvallen, zodat we detecties kunnen verbeteren. Zo geeft u de controle die u nodig heeft in een gebruiksvriendelijk formaat. We kennen de beperkingen van browsers en weten dat dit de veiligste manier is om uw afhankelijkheden op uw gehele website te monitoren en te beschermen. We hebben jarenlange ervaring in de client-side beveiligingsruimte voordat we cside startten. We kennen de beperkingen van browsers en investeren tijd in bijdragen aan standaardenorganisaties om native ondersteunde beveiligingsmogelijkheden beter en gebruiksvriendelijker te maken.
Meld u aan of boek een demo om aan de slag te gaan.
Wat nu?
Als u meer wilt weten over dit verhaal, bekijk dan de interactieve microsite op baways[.]com. We hebben alles uit de kast gehaald om het verhaal op een aantrekkelijke manier te presenteren — we hopen dat u ervan geniet.
