British Airways : la page de paiement que personne ne surveillait

Qui était British Airways en 2018, et pourquoi son site était-il une cible ?

En 2018, British Airways est la principale compagnie du groupe International Airlines Group (IAG), immatriculé en Espagne mais dont le siège opérationnel se trouve au Royaume-Uni, comme le rappelle l'avis de sanction de l'ICO, l'autorité britannique de protection des données. Pour l'exercice clos le 31 décembre 2017, la compagnie a déclaré à l'ICO un chiffre d'affaires mondial de 12,226 milliards de livres. Ses clients réservent et paient leurs billets sur britishairways.com et dans son application mobile, au Royaume-Uni, dans l'Union européenne et dans le reste du monde.

Un site de ce type concentre exactement ce que cherchent les fraudeurs à la carte bancaire : un flux continu de numéros de cartes, de dates d'expiration et de cryptogrammes, saisis par des clients qui font confiance à une marque connue. Dans l'affaire racontée ici, l'ICO note que l'attaquant semble avoir été motivé par l'argent, et qu'il aurait pu se servir du même accès pour viser des personnalités, perturber les réservations ou commettre d'autres fraudes.

Le calendrier compte aussi. Le Règlement général sur la protection des données (RGPD) entre en application le 25 mai 2018. Moins d'un mois plus tard, l'intrusion commence. L'avis de sanction relève que British Airways avait lancé un programme de préparation au RGPD, et qu'elle disposait depuis le 7 octobre 2017 d'une politique interne exigeant une authentification à plusieurs facteurs pour tout accès distant à son réseau, y compris celui des prestataires. Les règles existaient donc sur le papier ; c'est leur application qui a manqué.

Ce récit s'appuie d'abord sur cet avis de sanction de l'ICO, un document public de plus d'une centaine de pages dont certains passages techniques sont masqués, puis sur l'analyse publiée en septembre 2018 par la société de sécurité RiskIQ et sur la presse spécialisée. British Airways n'a pas reconnu sa responsabilité ; l'ICO l'écrit dès le paragraphe 1.6 de sa décision.

Que s'est-il réellement passé entre l'entrée de l'attaquant et la copie des cartes ?

L'attaque n'a pas commencé sur le site web. Elle a commencé par une porte de service : la passerelle Citrix qui permettait à des employés et à des prestataires d'utiliser à distance certaines applications de British Airways comme s'ils étaient au bureau. L'attaquant y est entré le 22 juin 2018 avec les identifiants d'un employé de Swissport, prestataire de services de fret. British Airways n'a jamais pu établir comment ces identifiants avaient été obtenus, mais elle a constaté, d'après l'avis de sanction, que cinq comptes liés à Swissport avaient été compromis.

Ce compte ne demandait qu'un nom d'utilisateur et un mot de passe. Une fois connecté, l'attaquant a réussi à « sortir » de l'environnement Citrix pour atteindre des parties du réseau auxquelles les employés de Swissport n'étaient pas censés accéder. La méthode exacte reste masquée ou incertaine dans l'avis de sanction. Il a ensuite importé ses propres outils et cartographié le réseau.

Pendant cette reconnaissance, il a trouvé un fichier contenant, en clair, l'identifiant et le mot de passe d'un compte d'administrateur de domaine, l'un des comptes les plus puissants d'un réseau Windows. L'ICO note qu'en théorie, n'importe quel utilisateur du domaine pouvait ouvrir ce fichier. À partir de là, l'attaquant a pu activer un compte invité désactivé, l'ajouter au groupe des administrateurs locaux et se déplacer de serveur en serveur sans déclencher d'alerte.

Le 26 juillet 2018, il a atteint des fichiers journaux qui contenaient en clair des données de cartes de paiement liées aux réservations payées en points de fidélité. Ces données n'auraient jamais dû être enregistrées : il s'agissait d'une fonction de test restée active depuis décembre 2015, par erreur humaine selon la compagnie. Leur conservation était limitée à 95 jours, ce qui a borné l'exposition : l'ICO estime qu'environ 108 000 cartes étaient ainsi à la portée de l'attaquant.

Enfin, en explorant les serveurs, l'attaquant a trouvé les fichiers de code du site britishairways.com. Entre le 14 et le 25 août 2018, selon l'ICO, il y a ajouté un détournement : chaque fois qu'un client saisissait sa carte, une copie partait vers BAways.com, sans interrompre la réservation. Selon l'analyse de RiskIQ rapportée par CSO Online, le code tenait en 22 lignes ajoutées à la bibliothèque Modernizr, servait aussi l'application mobile, et le domaine pirate disposait d'un certificat de sécurité émis le 15 août 2018, ce qui permettait d'envoyer les données en connexion chiffrée, comme le reste du site.

Pourquoi l'ICO tient-elle la compagnie pour responsable, alors que l'attaquant est un criminel ?

British Airways a soutenu devant l'ICO que l'attaque était l'œuvre de criminels persistants, que les fuites de cartes étaient devenues courantes et que l'autorité jugeait avec le bénéfice du recul. L'ICO a écarté ces arguments. Elle reconnaît que l'attaque est un acte criminel et que l'entrée s'est faite par le compte d'un prestataire, mais elle sanctionne autre chose : l'absence de mesures de sécurité appropriées, au sens de l'article 5 et de l'article 32 du RGPD.

Pour éviter de juger après coup, l'ICO s'est limitée aux risques connus ou prévisibles à l'époque, et aux mesures qui existaient déjà. Elle cite des recommandations publiques antérieures à l'attaque, venues du Centre national de cybersécurité britannique, de l'OWASP, du NIST américain et de Citrix lui-même. Les mesures qu'elle énumère sont présentées comme disponibles de longue date et réalisables sans coût excessif, souvent avec les outils Microsoft que la compagnie possédait déjà.

Elle conclut que la compagnie a agi par négligence, et non intentionnellement, et qu'elle est entièrement responsable des manquements au RGPD, sans être pour autant seule responsable de l'attaque. Elle relève aussi qu'il est difficile de savoir si, ni quand, British Airways aurait découvert seule le vol : c'est un tiers qui l'a prévenue. La période retenue court du 25 mai au 5 septembre 2018, soit 103 jours pendant lesquels les accès et les copies de données sont passés inaperçus.

Que révèle l'écart entre l'amende annoncée et l'amende payée ?

L'écart de plus de 163 millions de livres a beaucoup été commenté. L'avis de sanction montre qu'il ne vient pas d'un abandon des griefs : les manquements sont maintenus, la négligence aussi. Il vient surtout de la méthode de calcul. Dans son avis d'intention, l'ICO s'appuyait sur une procédure interne fondée sur des tranches de chiffre d'affaires ; après les observations de la compagnie, elle a renoncé à cette procédure et appliqué sa politique d'action réglementaire en cinq étapes, en gardant le chiffre d'affaires comme l'un des critères parmi d'autres.

Deux réductions se sont ensuite ajoutées, toujours selon l'avis du 16 octobre 2020. La première, de 20 %, récompense ce que la compagnie a bien fait après l'alerte : neutraliser le code en 90 minutes, prévenir l'ICO dès le lendemain, informer les banques et les clients, proposer le remboursement des pertes financières et une surveillance de crédit, coopérer pleinement. La seconde, de 4 millions, applique la politique adoptée par l'ICO pendant la pandémie, qui pesait lourdement sur les recettes de la compagnie, même si l'ICO estimait que la compagnie et son groupe pouvaient payer sans difficulté financière.

Pour une petite entreprise, la leçon n'est pas le montant. Elle tient en deux constats tirés du même document. D'une part, la qualité de la réaction après l'incident a pesé directement sur la sanction. D'autre part, aucun effort de communication n'a effacé ce qui manquait avant l'incident : une règle de sécurité écrite mais non appliquée, et l'absence de tout moyen de savoir que le site avait été modifié.

Qu'ont coûté l'incident et ses suites au-delà de l'amende ?

L'amende n'est qu'une partie de la facture, et la plupart des autres postes ne sont pas publics. L'avis de sanction énumère pourtant ce que la compagnie a dû mobiliser : des experts techniques pour l'enquête, des conseils juridiques pendant deux ans de procédure, la notification de plus de 530 000 clients en deux jours, un communiqué adressé à 5 000 journalistes et commentateurs, l'information de la police, de l'aviation civile, de l'autorité financière, de l'agence nationale de lutte contre la criminalité et de 21 procureurs généraux d'États américains.

Le même document mentionne le remboursement promis le 7 septembre 2018 aux clients qui subiraient une perte financière directe, la surveillance de crédit gratuite acceptée par plus de 40 000 personnes, et le déploiement d'un outil de détection et de réponse sur les terminaux, achevé le 16 novembre 2018. L'ICO note aussi que l'attaque et la procédure ont nui à la marque et à la réputation de la compagnie.

Sur le terrain judiciaire, une action collective a été engagée devant la justice anglaise. Selon le cabinet Simmons & Simmons, elle réunissait environ 16 000 demandeurs. Le 5 juillet 2021, le cabinet qui les représentait a annoncé un accord confidentiel comprenant une indemnisation des demandeurs éligibles, sans reconnaissance de responsabilité de la compagnie. Le montant n'a pas été publié, et aucun chiffre fiable ne permet de l'estimer.

Le même mode opératoire a-t-il touché d'autres sites marchands la même année ?

Oui. Le 13 novembre 2020, l'ICO a infligé une amende de 1,25 million de livres à Ticketmaster UK pour une attaque de 2018 qui ressemble beaucoup à celle de British Airways, avec une différence instructive. Selon l'avis de sanction visant Ticketmaster, l'attaquant n'a pas touché le site du vendeur de billets : il a modifié le JavaScript d'un assistant conversationnel fourni par la société Inbenta, hébergé sur les serveurs de ce prestataire.

Ticketmaster avait choisi d'afficher cet assistant sur plusieurs pages, y compris la page de paiement. Le script compromis a donc pu lire ce que les clients y tapaient : noms, numéros de cartes, dates d'expiration et cryptogrammes. L'avis indique que 9,4 millions de personnes dans l'Espace économique européen ont été prévenues d'une exposition possible, dont 1,5 million au Royaume-Uni, que la banque Barclays a signalé environ 60 000 cartes compromises et que la banque Monzo en a remplacé environ 6 000.

L'ICO souligne que la vulnérabilité est née d'une décision commerciale : placer un outil tiers sur la page la plus sensible du site. C'est la leçon complémentaire du cas British Airways. Là, l'attaquant a modifié un fichier du site lui-même ; ici, il a modifié un fichier chargé depuis le serveur d'un fournisseur. Dans les deux cas, le navigateur du client a exécuté sans broncher un code que le marchand ne contrôlait plus.

La norme de sécurité des cartes traite désormais ce risque de front. Le PCI Security Standards Council, qui la publie, constate dans un guide du 10 mars 2025 une forte hausse de ces vols lors des paiements en ligne, qu'il appelle « e-skimming ». Sa version 4 contient deux exigences consacrées aux scripts des pages de paiement : les exigences 6.4.3 et 11.6.1, applicables depuis le 31 mars 2025. Elles demandent que chaque script soit autorisé, que son intégrité soit vérifiée, et que toute modification non autorisée de la page ou de ses en-têtes de sécurité soit détectée.

Une PME de Cotonou, d'Abidjan ou de Lyon est-elle vraiment concernée par une attaque de ce genre ?

On pourrait croire que ce risque est réservé aux grandes marques. Le mécanisme dit l'inverse : l'attaquant de British Airways n'a utilisé ni faille inconnue ni moyen hors de portée. Il a profité d'un mot de passe de prestataire sans second facteur, d'un mot de passe d'administration écrit dans un fichier, et d'un site dont personne ne vérifiait le code. Ces trois faiblesses se retrouvent couramment dans les petites structures, où le même prestataire garde pendant des années les accès à l'hébergement et à l'administration du site.

Une boutique en ligne de PME charge souvent sur sa page de commande bien plus de code qu'elle ne le pense : thème, extensions de la boutique, outil de mesure d'audience, pixel publicitaire, bouton WhatsApp, fenêtre de discussion, police de caractères hébergée ailleurs. Chacun de ces fichiers peut lire ce que le client tape sur la page. Le cas Ticketmaster montre qu'il suffit qu'un seul fournisseur soit compromis pour que la page de paiement le soit aussi.

Le paiement par mobile money change la nature du risque sans le supprimer. Quand la validation se fait chez la passerelle ou sur le téléphone du client, le site du marchand ne voit pas le code secret du portefeuille. Mais un script malveillant sur la page de commande peut toujours copier les noms, téléphones et adresses, remplacer le bouton de paiement par un faux formulaire de carte, ou envoyer le client vers une page imitant la passerelle. Le danger se déplace vers ce que le client voit avant de payer.

Côté encaissement, une autre faiblesse est propre aux intégrations de passerelles : se fier au statut affiché dans l'adresse de retour plutôt qu'à la vérification par l'API. Les documentations de FedaPay, KkiaPay et CinetPay demandent toutes une confirmation côté serveur, comme le détaille le comparatif FedaPay, KkiaPay et CinetPay. Une commande validée sur la seule foi du navigateur peut être falsifiée par le client lui-même ou par un script.

Quelles décisions prendre dès maintenant, sans attendre un incident ?

Première décision : ne plus jamais recevoir de numéro de carte sur votre propre serveur. Le paiement passe par la page ou la fenêtre de la passerelle, et votre site ne voit qu'une référence de transaction. Le PCI Security Standards Council réserve son questionnaire d'auto-évaluation SAQ A aux marchands qui confient entièrement ces fonctions à des prestataires conformes ; depuis sa mise à jour de janvier 2025, ces marchands doivent aussi confirmer que leur site n'est pas exposé aux attaques par scripts.

Deuxième décision : dresser l'inventaire des scripts et des accès. Pour chaque script de la page de commande, notez qui l'a ajouté, pourquoi, et s'il est vraiment utile à cet endroit. Retirez la fenêtre de discussion, les pixels et les outils de test de la page de paiement s'ils n'y servent à rien. Pour chaque accès, notez qui le détient et fermez ceux qui ne servent plus.

Troisième décision : rendre visible toute modification. Une empreinte des fichiers du site comparée régulièrement, une alerte quand un fichier change hors d'une mise en production prévue, une politique de sécurité du contenu qui limite les domaines autorisés à recevoir des données, des journaux de connexion à l'administration consultés : ces mesures ne coûtent pas une infrastructure de grande entreprise, mais elles demandent que quelqu'un en soit responsable.

Quatrième décision : préparer la réaction. Qui coupe le site ? Qui prévient la passerelle, la banque, les clients ? Dans l'Union européenne, l'article 33 du RGPD impose de notifier l'autorité de contrôle d'une violation de données dans les meilleurs délais et, si possible, dans les 72 heures ; l'article 34 impose d'informer les personnes en cas de risque élevé. Au Bénin, la protection des données relève du livre cinquième du Code du numérique et de l'APDP ; vérifiez avec un juriste les obligations de votre pays avant d'en avoir besoin.

Comment Richard SALANON peut-il aider sur ce point précis ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Il n'a jamais travaillé pour British Airways : cette histoire est publique et sert ici de cas d'école. Ce qu'il propose aux PME porte sur les trois maillons qui ont cédé chez la compagnie. Pour une boutique, la page création de site e-commerce décrit une intégration où le paiement reste chez la passerelle, mobile money comme carte, et où chaque commande est confirmée côté serveur avant livraison.

Pour un site déjà en ligne, le service de maintenance et support est le cadre où se traitent les points de la liste ci-dessus : mises à jour, sauvegardes, revue des accès, second facteur, inventaire des scripts de la page de commande et surveillance des fichiers. Quand le site est relié à un ERP, à une passerelle ou à un outil métier, le service API REST et intégrations permet de revoir chaque connexion : ses clés, ses droits et ce qu'elle journalise.

Sa méthode commence par un état des lieux : quels scripts se chargent au paiement, qui détient quels accès, où passent les données de vos clients. Vous recevez une liste écrite des points à corriger, classés par urgence, puis les corrections sont faites avec vous, sans que les accès quittent votre nom. Il ne promet pas l'invulnérabilité, que personne ne peut garantir ; il vous aide à savoir ce qui tourne sur votre site et à être prévenu le premier s'il change. Son parcours figure sur la page Richard SALANON, et d'autres cas publics sont réunis dans les histoires.