O caso Travelport: como um erro de API causou uma violação de dados que afetou 73 mil pessoas

Atualizado: 3 de setembro de 2026 · Categoria: IA, segurança de dados e violações

O caso Travelport: como um erro de API causou uma violação de dados que afetou 73 mil pessoas

O comunicado da KVKK de 27 de agosto de 2026 sobre a violação de dados na Travelport indicou que 73.958 pessoas poderiam ter sido afetadas e que informações de reserva e viagem tinham sido acedidas sem autorização. O comunicado oficial identifica expressamente a causa técnica como um erro de configuração de API na aplicação ViewTrip.

Índice

Resposta curta
Porque importa?
O que devem fazer as empresas?
Como medir estes controlos?
Fontes
Perguntas frequentes

Resposta curta

O comunicado da KVKK de 27 de agosto de 2026 sobre a Travelport identifica expressamente um erro de configuração de API na ViewTrip. O acesso deveria exigir o número PNR e o apelido em conjunto, mas era possível consultar registos apenas com a referência de reserva. O responsável pelo tratamento comunicou 73.958 pessoas afetadas; o número baseia-se em registos PNR criados por agências de viagens na Turquia e não corresponde diretamente ao número de pessoas distintas residentes na Turquia.

Porque é importante?

O caso Travelport mostra que as violações de dados nem sempre resultam de uma cadeia de ataque complexa. Segundo o comunicado oficial, a configuração da API ViewTrip permitia o acesso apenas com a referência de reserva, em vez dos dois dados esperados. Um terceiro não identificado pôde assim aceder a informações limitadas sobre reservas.

Os dados potencialmente afetados incluíam nomes de passageiros, dados PNR, referências e informações de itinerários aéreos, hoteleiros, automóveis e ferroviários; em alguns casos, também poderiam incluir contactos. O incidente ocorreu em 6–7 de agosto de 2026 e foi detetado em 20 de agosto. Em 26 de agosto, o Conselho decidiu divulgá-lo publicamente pela decisão 2026/1797.

Como interpretar o número 73.958?

O número 73.958 não deve ser interpretado como 73.958 residentes distintos na Turquia. A Autoridade esclarece que se baseia nos registos PNR criados por agências de viagens na Turquia. Como não existia um campo de país de residência e não era possível distinguir reservas duplicadas, o número de pessoas residentes na Turquia será provavelmente inferior.

Isto é um caso da Bola?

O comunicado da KVKK não classifica o incidente como BOLA na terminologia OWASP. Contudo, a restrição insuficiente do acesso a outro registo através de uma referência de reserva fornecida pelo utilizador exige avaliar os controlos de autorização ao nível do objeto. A OWASP também recomenda verificar a autorização real do utilizador sobre o objeto nas funções API que recebem um identificador de objeto.

O que as empresas devem fazer? 9 lições técnicas e de KVKK do caso Travelport

Mantenha um inventário de endpoints de API. Inclua endpoints web, móveis, de parceiros e legados no mesmo inventário.
Distinga autenticação de autorização. Conhecer uma informação não deve significar automaticamente que o utilizador está autorizado a aceder ao registo.
Teste a autorização ao nível do objeto. Verifique com testes negativos que os utilizadores não obtêm acesso ao substituir IDs ou referências por outros objetos.
Não dependa apenas de identificadores imprevisíveis. Uma referência de reserva complexa ou aleatória não substitui os controlos de autorização.
Aplique a minimização das respostas. Um endpoint deve devolver apenas os campos necessários à sua função.
Configure a monitorização de taxas de acesso e anomalias. Detete comportamentos invulgares, como o acesso a muitas referências de reserva diferentes.
Integre testes de regressão de autorização no CI/CD. Uma alteração de configuração não deve desativar um controlo existente.
Conceba os registos de eventos como provas de incidentes. Deve ser possível analisar posteriormente que objeto foi acedido, quando e através de que cliente.
Ligue o processo de incidentes KVKK ao incidente técnico. As categorias de dados, o número de pessoas afetadas e a cronologia devem basear-se em conclusões técnicas verificadas.

O que é um teste de autorização negativa?

Um teste funcional normal verifica se um registo abre com a referência correta. Um teste de segurança verifica também cenários que devem falhar: é possível abrir um registo com a referência de outro utilizador, o que acontece sem apelido e pode uma sessão aceder a muitos registos?

Sobretudo nas regras de acesso baseadas em configuração, estes testes negativos devem executar-se automaticamente no pipeline de lançamento. Assim, uma definição de ambiente ou gateway que enfraqueça o controlo de acesso pode gerar um alerta antes do lançamento, mesmo sem alteração do código.

Modelo de Medição proposto para B10

Controlo de API	KPI	Risco
Inventário	Cobertura de endpoints conhecidos	API oculta ou legada
Autorização	Taxa de sucesso dos testes negativos de autorização	Acesso a outro objeto
Resposta	Número de campos sensíveis expostos	Dados não necessários
Deteção	Deteção de acessos anómalos a objetos	Varrimento não detetado
Registo de eventos	Rastreabilidade do acesso a objetos	Provas de incidente em falta
Lançamento	Cobertura de regressão de autorização	Regressão de configuração

Estes indicadores medem os resultados dos testes de intrusão e a rastreabilidade do controlo de acesso à API ao longo do ciclo de vida do produto.

Avaliação especializada

A principal lição da Travelport é distinguir autenticação de autorização. Conhecer uma referência de reserva não prova, por si só, o direito de consultar essa reserva. A API deve aplicar a política de acesso relevante sempre que se acede a um objeto sensível.

A classificação técnica deve também distinguir o comunicado oficial da metodologia de segurança. O «erro de configuração de API» é o facto oficial; a associação à autorização ao nível do objeto ou BOLA é uma análise técnica de risco.

Análise de Risco e Conformidade Digital

A B10 pode relacionar o inventário de API, os testes de autorização ao nível do objeto, os campos sensíveis das respostas, a cobertura de registos e as necessidades de prova de incidentes KVKK numa Privacy & API Exposure Matrix comum.

Conteúdos relacionados

Fontes oficiais e primárias

Perguntas frequentes Porque é que isso é importante agora?

O que as empresas devem primeiro verificar?

Não presuma uma causa técnica sem distinguir o âmbito do incidente do comunicado oficial.

Basta um controlo único?

Sim. Neste caso, o comunicado da KVKK identifica expressamente um erro de configuração de API na ViewTrip como causa técnica. Contudo, classificações OWASP como BOLA são um quadro de análise técnica, não a qualificação oficial utilizada pela Autoridade.

O que pode a B10 oferecer?

A B10 pode apresentar em conjunto o inventário de endpoints de API, os testes de acesso ao nível do objeto, a minimização de dados, a rastreabilidade de registos e os controlos de provas de incidentes.