Affaire Travelport : comment une erreur d’API a-t-elle entraîné une violation de données touchant 73 000 personnes ?

Mise à jour : 3 septembre 2026 · Catégorie : IA, sécurité des données et violations

Affaire Travelport : comment une erreur d’API a-t-elle entraîné une violation de données touchant 73 000 personnes ?

L’annonce de la KVKK du 27 août 2026 concernant la violation de données chez Travelport indique que 73 958 personnes auraient pu être touchées et que des informations de réservation et de voyage avaient fait l’objet d’un accès non autorisé. Elle identifie explicitement la cause technique comme une erreur de configuration d’API dans l’application ViewTrip.

Table des matières

Réponse courte
Pourquoi est-ce important ?
Qu'est-ce que les entreprises devraient faire?
Comment mesurer ces contrôles ?
Sources
Questions fréquentes

Réponse courte

L’annonce Travelport de la KVKK du 27 août 2026 identifie explicitement une erreur de configuration d’API dans ViewTrip. L’accès devait normalement nécessiter le numéro PNR et le nom de famille, mais la seule référence de réservation permettait de consulter les dossiers. Le responsable du traitement a déclaré 73 958 personnes touchées ; ce chiffre repose sur les dossiers PNR créés par les agences de voyages en Turquie et ne correspond pas directement au nombre de personnes distinctes résidant en Turquie.

Pourquoi est-ce important ?

L’affaire Travelport montre qu’une violation de données ne résulte pas toujours d’une chaîne d’attaque complexe. Selon l’annonce officielle, la configuration de l’API ViewTrip rendait la seule référence de réservation suffisante, au lieu des deux informations attendues. Un tiers non identifié a ainsi pu accéder à des informations limitées sur les réservations.

Les données potentiellement touchées comprenaient les noms des passagers, les informations PNR, les références ainsi que les détails des trajets aériens, hôteliers, automobiles et ferroviaires ; des coordonnées auraient aussi pu être concernées dans certains cas. L’incident s’est produit les 6 et 7 août 2026 et a été détecté le 20 août. Le 26 août, le Conseil a décidé de le rendre public par sa décision 2026/1797.

Comment interpréter le chiffre de 73 958 ?

Le chiffre de 73 958 ne doit pas être interprété comme 73 958 résidents distincts de Turquie. L’Autorité précise qu’il repose sur les dossiers PNR créés par les agences de voyages en Turquie. En l’absence de champ indiquant le pays de résidence et faute de pouvoir distinguer les réservations en double, le nombre de personnes résidant en Turquie serait probablement inférieur.

C'est une affaire de la BOLA ?

L’annonce de la KVKK ne qualifie pas l’incident de BOLA selon la terminologie OWASP. Toutefois, un accès insuffisamment limité à un autre dossier via une référence de réservation fournie par l’utilisateur appelle un examen de l’autorisation au niveau des objets. OWASP recommande aussi de vérifier l’autorisation réelle de l’utilisateur sur l’objet concerné dans les fonctions API acceptant un identifiant d’objet.

Que devraient faire les entreprises? 9 enseignements techniques et KVKK de l’affaire Travelport

Tenez un inventaire des points d’accès API. Incluez les points d’accès web, mobiles, partenaires et anciens dans le même inventaire.
Distinguez authentification et autorisation. Connaître une information ne doit pas signifier automatiquement que l’utilisateur est autorisé à consulter le dossier.
Testez l’autorisation au niveau des objets. Vérifiez par des tests négatifs que l’utilisateur ne peut pas obtenir un accès en remplaçant les identifiants ou références par ceux d’autres objets.
Ne vous fiez pas aux seuls identifiants imprévisibles. Une référence de réservation complexe ou aléatoire ne remplace pas les contrôles d’autorisation.
Appliquez la minimisation des réponses. Un point d’accès ne doit renvoyer que les champs nécessaires à sa fonction.
Mettez en place une surveillance des volumes et des anomalies. Détectez les comportements inhabituels, tels que l’accès à de nombreuses références de réservation différentes.
Intégrez les tests de régression d’autorisation à la CI/CD. Une modification de configuration ne doit pas désactiver un contrôle existant.
Concevez les journaux pour servir de preuves d’incident. Il doit être possible d’analyser après coup quel objet a été consulté, quand et via quel client.
Reliez la procédure d’incident KVKK à l’incident technique. Les catégories de données, le décompte des personnes touchées et la chronologie doivent reposer sur des constats techniques vérifiés.

Qu'est-ce qu'un test d'autorisation négative?

Un test fonctionnel classique vérifie qu’un dossier s’ouvre avec la bonne référence. Un test de sécurité examine aussi les scénarios qui devraient échouer : peut-on ouvrir un dossier avec la référence d’un autre utilisateur, que se passe-t-il sans nom de famille, et une même session peut-elle accéder à de nombreux dossiers ?

Pour les règles d’accès fondées sur la configuration, ces tests négatifs doivent particulièrement être automatisés dans le pipeline de livraison. Un réglage d’environnement ou de passerelle affaiblissant le contrôle d’accès peut ainsi être signalé avant la mise en production, même sans changement du code.

Modèle de mesure proposé pour B10

Contrôle API	KPI	Risque
Inventaire	Couverture des points d’accès connus	API non répertoriée ou ancienne
Autorisation	Taux de réussite des tests négatifs d’autorisation	Accès à un autre objet
Réponse	Nombre de champs sensibles exposés	Données non nécessaires
Détection	Détection des accès anormaux aux objets	Balayage non détecté
Journalisation	Traçabilité des accès aux objets	Preuves d’incident manquantes
Mise en production	Couverture des tests de régression d’autorisation	Régression de configuration

Ces indicateurs mesurent les résultats des tests d’intrusion et la traçabilité du contrôle d’accès API tout au long du cycle de vie du produit.

Évaluation spécialisée

La principale leçon de Travelport est de distinguer authentification et autorisation. Connaître une référence ne prouve pas à lui seul le droit de consulter la réservation. L’API doit appliquer la politique d’accès pertinente à chaque accès à un objet sensible.

La classification technique doit aussi distinguer l’annonce officielle de la méthodologie de sécurité. L’« erreur de configuration d’API » est le constat officiel ; le rapprochement avec l’autorisation au niveau des objets ou BOLA relève de l’analyse technique des risques.

Analyse des risques numériques et de la conformité

B10 peut relier l’inventaire API, les tests d’autorisation au niveau des objets, les champs sensibles des réponses, la couverture des journaux et les besoins de preuve d’incident KVKK dans une même Privacy & API Exposure Matrix.

Contenus associés

Sources officielles et primaires

Questions fréquentes Pourquoi est-ce important maintenant?

Qu'est-ce que les entreprises devraient d'abord vérifier?

Ne supposez pas de cause technique sans distinguer la portée de l’incident de l’annonce officielle.

Un contrôle ponctuel suffit-il ?

Oui. Dans ce cas, l’annonce de la KVKK identifie explicitement une erreur de configuration d’API dans ViewTrip comme cause technique. Les classifications OWASP telles que BOLA constituent toutefois un cadre d’analyse technique, et non la qualification officielle de l’Autorité.

Que peut apporter B10 ?

B10 peut regrouper dans un rapport l’inventaire des points d’accès API, les tests d’accès aux objets, la minimisation des données, la traçabilité des journaux et les contrôles des preuves d’incident.