En résumé
- En 2018, en obtenant les identifiants d'un sous-traitant de British Airways, des acteurs malveillants ont pu modifier un script exécuté côté client pour exfiltrer des données de carte de crédit vers un endpoint qu'ils contrôlaient — ce domaine est baways[.]com, propriété de cside depuis 2024.
- Sur le domaine baways[.]com, vous pouvez lire une chronologie objective et détaillée des événements et de leurs suites.
- À la suite de l'incident, l'ICO avait initialement prévu d'infliger à British Airways une amende de 183 millions de livres sterling, qui a ensuite été réduite à 20 millions de livres sterling. À l'époque, British Airways traversait des difficultés liées à la Covid-19, ce qui a peut-être contribué à la réduction de l'amende.
- À la suite de cet incident et de nombreuses attaques similaires, le PCI DSS (Payment Card Industry Data Security Standard) a mis à jour ses exigences pour inclure la surveillance, la sécurisation et la documentation des scripts côté client.
- Aujourd'hui, davantage de solutions existent sur le marché pour prévenir ce type d'incident, mais la qualité des approches varie considérablement.
Pourquoi nous avons acheté baways[.]com
Parce que nous le pouvions. Étonnamment, alors que de nombreux éditeurs évoquaient constamment cette attaque, le domaine utilisé lors de celle-ci a expiré et était disponible à la vente sur le marché public au tarif standard de l'ICANN, soit 10,44 $ par an.
Au fil des années, et à travers les pages marketing des éditeurs, ce qui était écrit ne correspondait plus aux faits. Nous avons donc décidé de rassembler une dernière fois les preuves, les documents judiciaires, les communiqués de presse et les pages archivées, pour les publier dans un rapport consolidé. Sur le domaine même qui avait été utilisé lors de l'attaque.
Nous avons même fait appel à un ancien journaliste pour nous aider dans les recherches.
![Bannière du micro-site baways[.]com.](/content/images/2025/12/Screenshot-2025-12-14-at-8.20.04---PM.png)
Chronologie de l'attaque contre British Airways :
22 juin 2018 : Un attaquant pénètre dans le réseau de British Airways en utilisant des identifiants volés appartenant à un employé de Swissport (un prestataire de services cargo). Le compte ne disposait d'aucune authentification multifacteur.
23-26 juin 2018 : L'attaquant explore le réseau. Il fait une découverte alarmante : des identifiants d'administrateur de domaine stockés en clair. Simplement dans un fichier. Non chiffré.
26 juillet 2018 : L'attaquant découvre des fichiers journaux contenant des données de carte de paiement. Également en clair. Ceux-ci provenaient d'une fonctionnalité de test qui n'aurait jamais dû être mise en production.
21 août - 5 septembre 2018 : L'attaque est lancée. Pendant 16 jours, chaque client ayant saisi ses données de paiement sur le site de BA a vu ses données copiées et envoyées vers baways[.]com.
5 septembre 2018 : British Airways est alerté par un tiers. L'attaque est stoppée en 90 minutes.
Comment l'attaque contre British Airways a fonctionné
L'attaquant a injecté du code malveillant dans Modernizr, une bibliothèque JavaScript courante qui aide les sites web à fonctionner sur différents navigateurs. British Airways servait cette version compromise à l'ensemble de ses clients.
- Le script malveillant attendait que les clients cliquent sur le bouton de confirmation du paiement
- Il récupérait toutes les données de paiement et personnelles du formulaire
- Il envoyait ces données vers baways[.]com (qui semblait légitime, BA utilisant « BA » dans ses communications marketing)
- L'ensemble se déroulait silencieusement en arrière-plan
- Le processus de paiement normal se poursuivait sans aucun problème
Pourquoi l'attaque contre British Airways n'a pas été détectée par la sécurité réseau
L'attaque s'est déroulée sans laisser de traces visibles. La seule façon de détecter une anomalie était d'observer les outils de développement du navigateur, dans l'onglet réseau, au moment où les données étaient exfiltrées.
Cette attaque a également touché l'application mobile, qui utilisait une webview de l'application web. La webview elle-même ne disposait d'aucun tableau de bord d'outils de développement, si bien que dans l'application mobile, absolument aucune trace visible n'était laissée.
Il aurait été extrêmement difficile, voire impossible, pour les clients de détecter le vol de leurs données.
Les dommages
Dans le cadre des procédures judiciaires, l'ICO (Information Commissioner's Office) a publié les chiffres complets.
| Catégorie | Nombre de personnes touchées |
|---|---|
| Données de carte complètes exposées | 244 000 |
| Carte + CVV exposés | 77 000 |
| Numéros de carte uniquement | 108 000 |
| Comptes BA Executive Club | 612 |
| Total des personnes touchées | 429 612 |
L'ICO a initialement proposé une amende de 183,39 millions de livres sterling. Après négociations, la procédure contradictoire et les difficultés financières imposées à British Airways par la COVID-19, l'amende a été réduite à 20 millions de livres sterling.
British Airways a subi des pertes considérables et le PDG de l'époque a été contraint de présenter des excuses publiques, en assurant que les clients touchés seraient indemnisés.
L'amende n'est pas le seul impact financier. Plusieurs recours collectifs ont suivi ; selon des sources publiques, les dommages sont estimés entre 2 000 et 6 000 livres sterling par plaignant. Avec plus de 16 000 victimes représentées dans un seul recours, l'impact financier total a vraisemblablement dépassé l'amende réglementaire, sans même tenir compte des répercussions commerciales liées à l'atteinte à la réputation de la marque British Airways.
Pourquoi cet incident reste pertinent en 2025
Le problème n'a fait que s'aggraver. La posture de sécurité des applications web est centrée sur les actions visant l'infrastructure web. De nouveaux efforts sont consacrés à la surveillance des dépendances open source statiques et à l'adoption de l'IA dans les entreprises. Mais les développeurs web et les équipes sécurité ne savent toujours pas, et ne disposent pas d'outils fiables pour vérifier, comment leurs applications web et leurs dépendances — outils marketing et packages open source inclus — se comportent dans les navigateurs.
La surveillance à l'exécution côté client aurait empêché l'attaque contre British Airways
Il s'agit d'un vecteur d'attaque hautement dynamique, et la seule vraie solution à cette menace est une analyse active à l'exécution. La pression réglementaire en matière de conformité a poussé certaines entreprises à adopter des outils de conformité superficiels reposant sur des scanners/crawlers ou des approches sans agent. Ces approches sont facilement contournées par l'attaquant, qui n'a qu'à ne pas servir les charges utiles malveillantes à ces outils.
La sécurité côté client à l'exécution en temps réel n'est toujours pas une priorité élevée. Les acteurs malveillants en sont conscients, et des attaques côté client d'une complexité significative se produisent quotidiennement. Parmi les cas récents notables, on peut citer l'attaque Bybit, l'attaque CoinMarketCap, et l'attaque Polyfill de 2024 qui a ciblé plus de 490 000 sites web en utilisant une approche similaire à celle de Modernizr.
La chaîne d'approvisionnement côté client présente des défis supplémentaires significatifs. Chaque requête vers un serveur tiers peut générer une réponse dynamique et différente. L'analyse en continu est coûteuse, mais c'est la seule façon de gérer la posture de sécurité.
Ce qui a changé après l'incident British Airways
À l'époque de l'incident British Airways, de nombreux incidents similaires se sont produits, comme la violation Ticketmaster et l'attaque Newegg. Mastercard, Visa et American Express ont révélé que la majorité des données de carte de crédit sont aujourd'hui volées via des scripts côté client malveillants. En réponse, le cadre de conformité PCI DSS a été mis à jour pour intégrer la sécurité côté client à travers 2 nouvelles exigences : 6.4.3 et 11.6.1. Nous avons rédigé un article de blog détaillé à ce sujet.
À la suite de la mise à jour du PCI DSS, d'autres référentiels sectoriels ont clarifié leurs exigences en matière de sécurité de la chaîne d'approvisionnement pour y inclure les dépendances exécutées côté client. Des incidents comme la fuite de données Kaiser Permanente ont déclenché des mises à jour de l'HIPAA.
L'adoption de solutions de sécurité à l'exécution côté client pour surveiller les actions des sites web devient de plus en plus incontournable. Cependant, chaque exigence de conformité nécessite ses propres preuves formatées : certaines davantage axées sur l'utilisation des cookies, d'autres sur les flux de données. Avec une solution comme cside, cela devient extrêmement simple.
Comment cside aide
cside propose une approche hautement flexible de la sécurité côté client. Que nous surveillions les comportements des scripts côté client et les analysions plus en profondeur via le reporting côté client sur notre moteur, cside dispose d'une vision complète. Il analyse le code des dépendances servies en temps réel, vous aidant à prévenir les comportements indésirables avant qu'ils n'aient un impact majeur sur votre activité.
Notre approche nous permet non seulement de détecter les attaques avancées et hautement ciblées et d'émettre des alertes, mais aussi de bloquer les attaques avant qu'elles n'atteignent le navigateur de l'utilisateur. Elle coche également les cases de plusieurs référentiels de conformité, notamment PCI DSS 4.0.1, HIPAA, RGPD, CPRA… Nous fournissons même une forensique approfondie, y compris lorsqu'un attaquant tente de contourner nos détections. Nous stockons également des données sur les attaques manquées afin d'améliorer continuellement nos capacités de détection. Vous disposez ainsi du contrôle dont vous avez besoin, dans un format facile à utiliser. Conscients des contraintes des navigateurs, nous sommes convaincus qu'il s'agit de la méthode la plus sécurisée pour surveiller et protéger vos dépendances sur l'ensemble de votre site web. Nous évoluons dans le domaine de la sécurité côté client depuis des années, bien avant la création de cside. Nous connaissons les limites des navigateurs et investissons du temps à contribuer aux organismes de normalisation pour améliorer nativement les capacités de sécurité et les rendre plus faciles à utiliser.
Inscrivez-vous ou réservez une démo pour commencer.
Par où commencer
Si cette histoire vous intéresse, consultez le micro-site interactif sur baways[.]com. Nous avons fait tout notre possible pour vous présenter cette histoire dans un format attrayant — nous espérons qu'elle vous plaira.
