Der Fall Travelport: Wie führte ein API-Fehler zu einer Datenschutzverletzung mit 73.000 Betroffenen?

Aktualisiert: 3. September 2026 · Kategorie: KI, Datensicherheit und Datenschutzverletzungen

Der Fall Travelport: Wie führte ein API-Fehler zu einer Datenschutzverletzung mit 73.000 Betroffenen?

Die KVKK-Mitteilung zur Datenschutzverletzung bei Travelport vom 27. August 2026 besagt, dass möglicherweise 73.958 Personen betroffen waren und unbefugt auf Buchungs- und Reisedaten zugegriffen wurde. Als technische Ursache nennt die offizielle Mitteilung ausdrücklich einen API-Konfigurationsfehler in der ViewTrip-Anwendung.

Inhaltsverzeichnis

Kurzantwort
Warum spielt das eine Rolle?
Was sollten Unternehmen tun?
Wie sollte dies gemessen werden?
Quellen
Häufig gestellte Fragen

Kurzantwort

Die Travelport-Mitteilung der KVKK vom 27. August 2026 nennt ausdrücklich einen API-Konfigurationsfehler in ViewTrip als technische Ursache. Normalerweise waren PNR-Nummer und Nachname gemeinsam für den Zugriff erforderlich; tatsächlich ließen sich Datensätze allein mit der Buchungsreferenz anzeigen. Der Verantwortliche meldete 73.958 Betroffene. Diese Zahl beruht auf PNR-Datensätzen türkischer Reisebüros und entspricht nicht unmittelbar der Zahl einzelner Personen mit Wohnsitz in der Türkei.

Warum ist das wichtig?

Der Fall Travelport zeigt, dass Datenschutzverletzungen nicht immer eine komplexe Angriffskette voraussetzen. Laut offizieller Mitteilung genügte wegen der API-Konfiguration in ViewTrip die Buchungsreferenz anstelle der beiden erwarteten Angaben. So konnte ein unbekannter Dritter auf begrenzte Buchungsinformationen zugreifen.

Möglicherweise betroffen waren Passagiernamen, PNR-Angaben, Referenznummern sowie Informationen zu Flug-, Hotel-, Mietwagen- und Bahnreisen; teilweise könnten auch Kontaktdaten betroffen gewesen sein. Der Vorfall ereignete sich am 6.–7. August 2026 und wurde am 20. August entdeckt. Am 26. August beschloss der Datenschutzrat mit Entscheidung 2026/1797 die öffentliche Bekanntmachung.

Wie ist die Zahl 73.958 zu verstehen?

Die Zahl 73.958 ist nicht als 73.958 einzelne Einwohner der Türkei zu verstehen. Die Behörde stellt klar, dass sie auf PNR-Datensätzen türkischer Reisebüros beruht. Da ein Feld zum Wohnsitzland fehlte und Mehrfachbuchungen nicht getrennt werden konnten, dürfte die Zahl der in der Türkei wohnenden Betroffenen niedriger sein.

Ist das ein BOLA-Fall?

Die KVKK-Mitteilung stuft den Vorfall nicht in der OWASP-Terminologie als BOLA ein. Unzureichend beschränkter Zugriff auf einen anderen Datensatz über eine vom Nutzer übermittelte Buchungsreferenz erfordert jedoch die Prüfung der Autorisierung auf Objektebene. OWASP empfiehlt ebenfalls, bei API-Funktionen mit Objekt-ID die tatsächliche Zugriffsberechtigung des Nutzers auf das betreffende Objekt zu prüfen.

Was sollten Unternehmen tun? 9 technische und KVKK-Lehren aus dem Fall Travelport

Führen Sie ein API-Endpunktinventar. Erfassen Sie Web-, Mobil-, Partner- und Legacy-Endpunkte im selben Inventar.
Trennen Sie Authentifizierung und Autorisierung. Die Kenntnis einer Information bedeutet nicht automatisch, dass ein Nutzer auf den Datensatz zugreifen darf.
Testen Sie die Autorisierung auf Objektebene. Prüfen Sie mit Negativtests, dass Nutzer nicht durch Einsetzen anderer Objekt-IDs oder Referenzen Zugriff erhalten.
Verlassen Sie sich nicht allein auf unvorhersehbare Kennungen. Eine komplexe oder zufällige Buchungsreferenz ersetzt keine Autorisierungsprüfung.
Minimieren Sie API-Antworten. Ein Endpunkt sollte nur die für seine Funktion benötigten Felder zurückgeben.
Richten Sie Raten- und Anomalieüberwachung ein. Erkennen Sie ungewöhnliches Verhalten, etwa Zugriffe auf viele unterschiedliche Buchungsreferenzen.
Binden Sie Autorisierungs-Regressionstests in CI/CD ein. Eine Konfigurationsänderung darf bestehende Kontrollen nicht deaktivieren.
Gestalten Sie Protokolle als Nachweise für Sicherheitsvorfälle. Es muss nachträglich analysierbar sein, auf welches Objekt wann und über welchen Client zugegriffen wurde.
Verknüpfen Sie den KVKK-Vorfallprozess mit dem technischen Vorfall. Datenkategorien, Betroffenenzahl und Vorfallzeitachse sollten auf bestätigten technischen Erkenntnissen beruhen.

Was ist ein negativer Autorisierungstest?

Ein normaler Funktionstest prüft, ob sich ein Datensatz mit der richtigen Buchungsreferenz öffnen lässt. Ein Sicherheitstest prüft auch Szenarien, die scheitern sollten: Ist Zugriff mit der Referenz eines anderen Nutzers möglich? Was passiert ohne Nachnamen? Kann eine Sitzung auf viele Datensätze zugreifen?

Gerade bei konfigurationsbasierten Zugriffsregeln sollten diese Negativtests automatisch in der Release-Pipeline laufen. So können Änderungen an Umgebungs- oder Gateway-Einstellungen, die den Zugriffsschutz schwächen, vor der Veröffentlichung erkannt werden, auch ohne Codeänderung.

Vorgeschlagenes Messmodell für B10

API-Kontrolle	KPI	Risiko
Bestandsaufnahme	Abdeckung bekannter Endpunkte	Schatten- oder Legacy-API
Autorisierung	Erfolgsquote negativer Autorisierungstests	Zugriff auf ein anderes Objekt
Antwort	Anzahl offengelegter sensibler Felder	Unnötige Daten
Erkennung	Erkennung ungewöhnlicher Objektzugriffe	Unentdecktes Scannen
Protokollierung	Nachvollziehbarkeit von Objektzugriffen	Fehlende Vorfallnachweise
Veröffentlichung	Abdeckung von Autorisierungs-Regressionstests	Regression der Konfiguration

Diese Kennzahlen messen sowohl Pentest-Ergebnisse als auch die Nachvollziehbarkeit der API-Zugriffskontrolle über den gesamten Produktlebenszyklus.

Sachverständigenbewertung

Die wichtigste Lehre aus Travelport ist die Trennung von Authentifizierung und Autorisierung. Die Kenntnis einer Buchungsreferenz beweist allein keine Berechtigung zum Anzeigen der Buchung. Die API muss die geltende Zugriffsrichtlinie bei jedem Zugriff auf ein sensibles Objekt durchsetzen.

Bei der technischen Einordnung sind außerdem die offizielle Mitteilung und die Sicherheitsmethodik zu unterscheiden. „API-Konfigurationsfehler“ ist die offiziell mitgeteilte Ursache; die Zuordnung zu Autorisierung auf Objektebene oder BOLA ist technische Risikoanalyse.

Digitale Risiko- und Compliance-Analyse

B10 kann API-Inventar, Autorisierungstests auf Objektebene, sensible Antwortfelder, Protokollierungsabdeckung und KVKK-Vorfallnachweise in einer gemeinsamen Privacy & API Exposure Matrix verknüpfen.

Verwandte Inhalte

Offizielle und primäre Quellen

Häufig gestellte Fragen Warum ist das jetzt wichtig?

Was sollten Unternehmen zuerst überprüfen?

Nehmen Sie keine technische Ursache an, ohne den Vorfallumfang von der offiziellen Mitteilung zu unterscheiden.

Reicht eine einmalige Kontrolle?

Ja. In diesem Fall nennt die KVKK-Mitteilung ausdrücklich einen API-Konfigurationsfehler in ViewTrip als technische Ursache. OWASP-Einstufungen wie BOLA sind jedoch ein Rahmen technischer Analyse und keine offizielle Bezeichnung der Behörde.

Was kann B10 beitragen?

B10 kann API-Endpunktinventar, Zugriffstests auf Objektebene, Datenminimierung, Protokollnachvollziehbarkeit und Vorfallnachweise gemeinsam auswerten.