El caso Travelport: cómo un error de API causó una brecha de datos que afectó a 73.000 personas
El comunicado de la KVKK del 27 de agosto de 2026 sobre la brecha de datos de Travelport indicó que podrían haberse visto afectadas 73.958 personas y que se había accedido sin autorización a…
Actualizado: 3 de septiembre de 2026 · Categoría: IA, seguridad de datos e infracciones
El caso Travelport: cómo un error de API causó una brecha de datos que afectó a 73.000 personas
El comunicado de la KVKK del 27 de agosto de 2026 sobre la brecha de datos de Travelport indicó que podrían haberse visto afectadas 73.958 personas y que se había accedido sin autorización a información de reservas y viajes. Identifica expresamente la causa técnica como un error de configuración de API en la aplicación ViewTrip.
Contenido- Respuesta breve
- ¿Por qué importa?
- ¿Qué deben hacer las empresas?
- ¿Cómo medir estos controles?
- Fuentes
- Preguntas frecuentes
El comunicado de la KVKK del 27 de agosto de 2026 sobre Travelport identifica expresamente un error de configuración de API en ViewTrip. El acceso debía exigir tanto el número PNR como el apellido, pero bastaba la referencia de reserva para consultar los registros. El responsable del tratamiento comunicó 73.958 afectados; la cifra se basa en registros PNR creados por agencias de viajes en Turquía y no corresponde directamente al número de personas distintas residentes en Turquía.
¿Por qué es importante?El caso Travelport muestra que las brechas de datos no siempre resultan de una cadena de ataque compleja. Según el comunicado oficial, la configuración de API de ViewTrip permitía el acceso solo con la referencia de reserva, en vez de los dos datos esperados. Así, un tercero no identificado pudo acceder a información limitada sobre reservas.
Los datos potencialmente afectados incluían nombres de pasajeros, datos PNR, referencias e itinerarios de vuelos, hoteles, automóviles y trenes; en algunos casos también podrían haberse afectado datos de contacto. El incidente ocurrió los días 6 y 7 de agosto de 2026 y se detectó el 20 de agosto. El 26 de agosto, el Consejo acordó hacerlo público mediante la decisión 2026/1797.
¿Cómo interpretar la cifra de 73.958?La cifra de 73.958 no debe interpretarse como 73.958 residentes distintos de Turquía. La Autoridad aclara que se basa en registros PNR creados por agencias de viajes en Turquía. Al no existir un campo de país de residencia ni poder distinguirse las reservas duplicadas, el número de residentes en Turquía probablemente sea menor.
¿Es un caso de BOLA?El comunicado de la KVKK no clasifica el incidente como BOLA en la terminología OWASP. Sin embargo, restringir insuficientemente el acceso a otro registro mediante una referencia de reserva aportada por el usuario exige evaluar los controles de autorización a nivel de objeto. OWASP también recomienda verificar la autorización real del usuario sobre el objeto en las funciones API que reciben un identificador de objeto.
¿ Qué deben hacer las empresas? 9 lecciones técnicas y de KVKK del caso Travelport- Mantenga un inventario de endpoints de API. Incluya los endpoints web, móviles, de socios y heredados en el mismo inventario.
- Distinga autenticación y autorización. Conocer un dato no debe significar automáticamente que el usuario está autorizado a acceder al registro.
- Pruebe la autorización a nivel de objeto. Verifique con pruebas negativas que los usuarios no obtienen acceso sustituyendo identificadores o referencias por los de otros objetos.
- No dependa solo de identificadores impredecibles. Una referencia de reserva compleja o aleatoria no sustituye los controles de autorización.
- Aplique la minimización de respuestas. Un endpoint debe devolver solo los campos necesarios para su función.
- Configure la supervisión de tasas de acceso y anomalías. Detecte conductas inusuales, como el acceso a muchas referencias de reserva distintas.
- Integre pruebas de regresión de autorización en CI/CD. Un cambio de configuración no debe desactivar un control existente.
- Diseñe los registros de eventos como pruebas de incidentes. Debe poder analizarse después a qué objeto se accedió, cuándo y mediante qué cliente.
- Vincule el proceso de incidentes KVKK con el incidente técnico. Las categorías de datos, el cómputo de afectados y la cronología deben basarse en hallazgos técnicos verificados.
Una prueba funcional normal comprueba si el registro se abre con la referencia correcta. Una prueba de seguridad también examina escenarios que deberían fallar: ¿puede abrirse con la referencia de otro usuario?, ¿qué ocurre sin apellido?, ¿puede una sesión acceder a muchos registros?
Especialmente en reglas de acceso basadas en configuración, estas pruebas negativas deben ejecutarse automáticamente en el proceso de publicación. Así se puede detectar antes del lanzamiento una configuración de entorno o gateway que debilite el control de acceso, aunque no cambie el código.
Modelo de medición propuesto para el B10| Control de API | KPI | Riesgo |
|---|---|---|
| Inventario | Cobertura de endpoints conocidos | API oculta o heredada |
| Autorización | Tasa de éxito de pruebas negativas de autorización | Acceso a otro objeto |
| Respuesta | Número de campos sensibles expuestos | Datos no necesarios |
| Detección | Detección de accesos anómalos a objetos | Exploración no detectada |
| Registro de eventos | Trazabilidad del acceso a objetos | Pruebas de incidentes ausentes |
| Publicación | Cobertura de regresión de autorización | Regresión de configuración |
Estos indicadores miden los resultados de las pruebas de intrusión y la trazabilidad del control de acceso de API durante todo el ciclo de vida del producto.
Evaluación especializadaLa principal lección de Travelport es distinguir autenticación y autorización. Conocer una referencia de reserva no demuestra por sí solo el derecho a consultarla. La API debe aplicar la política de acceso pertinente cada vez que se accede a un objeto sensible.
La clasificación técnica también debe distinguir el comunicado oficial de la metodología de seguridad. El «error de configuración de API» es el hecho oficial; su asociación con autorización a nivel de objeto o BOLA es un análisis técnico de riesgo.
Análisis de Riesgo Digital y CumplimientoB10 puede relacionar el inventario de API, las pruebas de autorización a nivel de objeto, los campos sensibles de respuesta, la cobertura de registros y las necesidades de prueba de incidentes KVKK en una Privacy & API Exposure Matrix común.
Contenidos relacionados- Los deepfakes ya no son solo un riesgo reputacional: qué deben demostrar las empresas tras el AI Act
- Vendedores no autorizados y riesgos de marca en el comercio electrónico transfronterizo: ¿quién vende su marca en marketplaces globales?
- ¿Cómo se convierten las vulnerabilidades de seguridad de API en infracciones de la KVKK? Guía de privacidad y exposición de API para empresas
- KVKK – notificación de brecha de datos de Travelport International Operations Limited
- KVKK – obligaciones de seguridad de datos
- OWASP – API1:2023 Fallos de autorización a nivel de objeto
El comunicado de la KVKK del 27 de agosto de 2026 sobre la brecha de datos de Travelport indicó que podrían haberse visto afectadas 73.958 personas y que se había accedido sin autorización a información de reservas y viajes. Identifica expresamente la causa técnica como un error de configuración de API en la aplicación ViewTrip.
¿Qué deben comprobar las empresas primero?No suponga una causa técnica sin distinguir el alcance del incidente del comunicado oficial.
¿Basta con un control puntual?Sí. En este caso, el comunicado de la KVKK identifica expresamente un error de configuración de API en ViewTrip como causa técnica. Sin embargo, las clasificaciones OWASP como BOLA son un marco de análisis técnico, no la calificación oficial empleada por la Autoridad.
¿Qué puede aportar B10?B10 puede informar conjuntamente sobre el inventario de endpoints de API, las pruebas de acceso a nivel de objeto, la minimización de datos, la trazabilidad de registros y los controles de pruebas de incidentes.