As 5 Principais Vulnerabilidades de API em 2025 pela APISecurity.io

Vulnerabilidade nº 1: Ausência de Autenticação (Missing Authentication)

Nossa vulnerabilidade de API mais frequente este ano foi a Ausência de Autenticação. Tratam-se de APIs que não exigem autenticação para operações sensíveis, permitindo que usuários anônimos acessem dados ou executem ações que deveriam ser restritas a usuários autenticados.

Em 2024, essa foi a nossa quinta vulnerabilidade mais relatada. Em 2025, ela subiu para a primeira posição, representando 17% de todos os incidentes de API cobertos.

Um caso de março ilustra o impacto da ausência de autenticação, quando dados de pacientes no sistema de saúde do Reino Unido foram supostamente expostos por meio de uma API sem autenticação. E em agosto, cobrimos um problema semelhante na Intel, onde um endpoint de API getAccessToken retornava tokens válidos sem exigir nenhuma autenticação.

Manter o controle dos seus endpoints de API e verificar continuamente os controles de autenticação, tanto na pré-produção quanto em produção, pode ajudar as equipes de API a capturar e corrigir essa vulnerabilidade.

Vulnerabilidade nº 2: Quebra de Autorização em Nível de Objeto (Broken Object Level Authorization – BOLA)

A Quebra de Autorização em Nível de Objeto, ou BOLA, ficou em segundo lugar na nossa lista de incidentes frequentes em APIs. O BOLA ocorre quando uma API falha em verificar se um usuário tem permissão para acessar um objeto específico. Os atacantes exploram essa vulnerabilidade de autorização manipulando identificadores nas requisições da API, como IDs de usuário, números de conta ou outros identificadores de recursos, na tentativa de acessar dados de outros usuários. Isso se tornou uma tática padrão para hackers de API e é algo que os desenvolvedores devem estar atentos.

Vimos muitos casos de incidentes de BOLA em 2025. Um exemplo da nossa edição de setembro envolveu inversores da Growatt usados em sistemas solares industriais e comerciais. Uma falha de BOLA na API permitiu que hackers assumissem o controle de dispositivos IoT movidos a energia solar dentro das casas dos usuários.

“A API defeituosa aceita um parâmetro de ID de dispositivo sem verificar se o usuário atual está autorizado para aquele dispositivo, um caso de livro sobre Quebra de Autorização em Nível de Objeto.”

Também em setembro, analisamos as descobertas de um pesquisador sobre uma vulnerabilidade BOLA no site do Imposto sobre Bens e Serviços (GST) da Índia. Ao manipular requisições de API, os usuários conseguiam acessar informações fiscais de empresas privadas que não deveriam estar acessíveis para eles.

As verificações de autorização para recursos individuais são, geralmente, detalhadas demais para serem delegadas a plataformas centralizadas, como API Gateways ou produtos de IAM. Portanto, a responsabilidade recai sobre os desenvolvedores de API para implementar as verificações adequadas no próprio endpoint da API.

Vulnerabilidade nº 3: Exposição Excessiva de Dados (Excessive Data Exposure)

A maioria dos vazamentos de dados via API que vimos este ano envolveu a exposição de propriedades inesperadas ou não autorizadas nas respostas da API. Isso se alinha com a categoria API3:2023 da OWASP, Broken Object Property Level Authorization (embora eu ache que o nome anterior de 2019, Excessive Data Exposure, ainda descreva o problema de forma mais clara).

A exposição excessiva de dados ocorre quando uma API retorna mais propriedades do que o necessário. Isso inclui retornar objetos ou registros completos quando apenas um subconjunto de campos é exigido, ou falhar ao filtrar propriedades sensíveis antes de enviar a resposta.

Em maio, cobrimos um caso envolvendo o sistema de veículos conectados da Volkswagen. Um pesquisador descobriu que uma resposta de API retornava informações de que o aplicativo não precisava, incluindo credenciais e senhas em texto puro. E em outubro, relatamos o caso de um portal de cadastro para pilotos de Fórmula 1 que vazou dados excessivos em uma resposta de API, dando aos pesquisadores contexto suficiente para descobrir uma vulnerabilidade de elevação de privilégios.

Concordamos com a orientação da OWASP para prevenir a exposição excessiva de dados: defina e imponha os dados retornados por cada método de API por meio de um mecanismo de validação de resposta baseado em esquema ou contrato.

Vulnerabilidade nº 4: Quebra de Autorização em Nível de Função (Broken Function Level Authorization – BFLA)

A maioria dos incidentes de Quebra de Autorização em Nível de Função (BFLA) que cobrimos este ano foram erros básicos no controle de acesso baseado em funções (RBAC) no nível de operação da API. Ocorreram quando funções destinadas a usuários privilegiados estavam acessíveis a funções com menos permissões.

Um exemplo veio de um relatório de agosto sobre a plataforma de Gerenciamento de Contas Privilegiadas da Securden, onde uma função sensível de backup de senhas estava disponível para usuários que não eram administradores. Em nossa edição de março, destacamos problemas semelhantes na plataforma Zitadel, onde 12 endpoints de API de nível administrativo estavam abertos a usuários não administradores.

Outros casos comuns de BFLA envolveram usuários capazes de executar operações específicas de API, como PUT ou DELETE, que deveriam ter sido restritas a administradores.

Vulnerabilidade nº 5: Falha de Autenticação (Broken Authentication)

E, finalmente, em quinto lugar na nossa lista das vulnerabilidades de API mais comuns deste ano, está a Falha de Autenticação. Isso descreve falhas em que o próprio mecanismo de autenticação é mal projetado ou implementado, permitindo que uma API aceite requisições sem verificar adequadamente o usuário.

Em maio, cobrimos um problema em um aplicativo móvel da Volkswagen, onde uma API de validação de senha de uso único (OTP) estava vulnerável a ataques de força bruta. Em setembro, a FlowiseAI, uma plataforma para criação de agentes de IA, divulgou uma falha em seu processo de redefinição de senha. A API vulnerável retornava o token de redefinição diretamente na resposta, em vez de seguir práticas seguras para enviar o token ao e-mail cadastrado.

Separamos intencionalmente a Ausência de Autenticação da Falha de Autenticação para destacar com que frequência as equipes de API falham completamente em impor a autenticação. Embora os desafios em geral também continuem proeminentes nos controles de autenticação de API.