Quantos Shadow APIs estão escondidos em seus produtos e como trazê-los à luz

Shadow APIs raramente surgem de má intenção. Mais frequentemente, são um subproduto do desenvolvimento rápido: uma rota temporária para um piloto, um ponto de acesso separado para um aplicativo móvel, uma versão antiga esquecida de ser desativada ou um serviço interno que foi acidentalmente exposto. Neste artigo, vamos analisar por que os registros oficiais de API divergem da realidade, de onde vêm os Shadow APIs e como começar a procurá-los sem um projeto de vários meses.

O material será útil para gerentes e especialistas em segurança da informação, equipes de AppSec, arquitetos, engenheiros DevOps e proprietários de produtos digitais — todos que trabalham com microsserviços, aplicativos móveis, portais de clientes, integrações com parceiros e plataformas internas.

Vamos começar com um caso

Imagine uma auditoria típica antes de um teste de penetração ou implementação de um API Gateway. No comitê de arquitetura, a equipe afirma com confiança: "Em produção, temos 214 endpoints de API. Tudo está descrito no Swagger, as rotas principais estão configuradas no API Gateway." Uma semana depois, a equipe de segurança da informação examina os logs de acesso no proxy reverso e encontra 327 rotas exclusivas. Dezenas de outras estão nas configurações do Ingress para Kubernetes, mas não passam pelo API Gateway. Parte delas é chamada pelo aplicativo móvel, parte por serviços internos, parte por um antigo circuito de integração com parceiros que ninguém mais se lembra.

Neste momento, a pergunta "quantas APIs temos?" deixa de ser uma questão de referência. Ela se transforma em uma investigação.

Figura 1. O registro oficial de API e a imagem real frequentemente divergem

O problema não é que os engenheiros não saibam contar. O problema é que as APIs em uma empresa moderna surgem mais rápido do que podem ser registradas e gradualmente formam uma camada separada de APIs que vive fora do processo normal de gerenciamento.

Assim surgem os Shadow APIs — APIs ocultas. Eles não são necessariamente mal projetados ou escritos de forma insegura. O risco é outro: eles não estão na lista oficial, não têm um proprietário claro, não foram incluídos na área de testes, não são cobertos por verificações de segurança, notificações não estão configuradas para eles e, às vezes, eles até contornam o WAF e o API Gateway.

Uma API não pode ser protegida se você não sabe que ela existe.

O que considerar um Shadow API

O termo Shadow API é frequentemente confundido com conceitos relacionados, então começaremos com uma classificação básica.

Shadow API — é uma API em funcionamento que não está no registro oficial, documentação ou especificação. Tal API pode aceitar requisições reais, acessar um banco de dados de produção, retornar dados pessoais ou executar operações de negócios, mas permanecer invisível para as equipes de segurança, operações e controle arquitetônico.

Zombie API — é uma antiga API legítima que deveria ter sido desativada, mas que na verdade continua funcionando. Um exemplo típico é /api/v1/payment/confirm, que foi substituído por /api/v2/payment/confirm, mas a versão antiga não foi desativada porque "talvez alguém ainda a use".

Shadow parameters — é uma situação em que o próprio endpoint é descrito, mas na realidade aceita parâmetros que não estão na especificação. Por exemplo, o OpenAPI especifica apenas customer_id, mas em produção o mesmo método também responde a debug=true, role=admin ou include_internal=true.

Veja como isso pode parecer na prática:

GET /api/v1/users/{id} GET /internal/users/export?id=123 GET /debug/customer/profile?user_id=123&include_internal=true

O primeiro endpoint está descrito no OpenAPI. O segundo foi adicionado para integração com o sistema de análise de negócios. O terceiro surgiu durante a depuração do aplicativo móvel e deveria existir apenas por alguns dias. Todos os três podem acessar os mesmos dados, mas no registro oficial, muitas vezes, apenas o primeiro permanece.

OWASP classifica esse problema como API9:2023 Improper Inventory Management — gerenciamento incorreto de inventário de API. A essência do risco é simples: se uma empresa não tem um registro atualizado e uma estratégia clara para desativar versões antigas, sistemas não atualizados continuam a existir na infraestrutura, canais de acesso a dados desnecessários e rotas de API acidentalmente acessíveis externamente aparecem. OWASP observa separadamente que a arquitetura de microsserviços, ambientes em nuvem e Kubernetes facilitam a implantação de APIs, mas complicam o controle de sua disponibilidade real.

Existem mais APIs reais do que no registro

Se de todos os números de mercado, deixássemos apenas um, seria este: a Cloudflare, em seu 2024 API Security & Management Report , comparou endpoints de API auto-relatados com o que os algoritmos de aprendizado de máquina descobriram no tráfego real. A diferença foi de 30,7% . Ou seja, as empresas em média tinham quase um terço mais endpoints de API do que pensavam.

Isso é mais importante do que parece. O problema não é que alguém esqueceu de atualizar uma planilha no Confluence. O problema é a discrepância sistêmica entre o que a organização considera seu cenário de API e o que realmente responde às requisições.

Para contexto: segundo a mesma Cloudflare , as APIs representavam cerca de 57% do tráfego dinâmico da internet . As APIs há muito deixaram de ser uma "camada técnica". Para o mundo exterior, a API é frequentemente a própria aplicação: através dela são criados pedidos, obtidos dados pessoais, realizados pagamentos, gerenciadas contas e realizadas integrações com parceiros.

Dados mais recentes da Salt Labs para 2025 mostram que o problema não se tornou menos agudo. 99% dos entrevistados relataram ter enfrentado problemas de segurança de API nos últimos 12 meses. Ao mesmo tempo, apenas 15% expressaram alta confiança na precisão de seu inventário de API, e apenas 20% monitoram APIs continuamente. Isso explica bem por que o registro manual deixa de funcionar: quando a superfície muda com essa velocidade, a lista de APIs se torna obsoleta não "com o tempo", mas no momento da próxima entrega de alterações.

Como uma porta esquecida se transforma em um incidente

Um dos exemplos recentes é o incidente 700Credit em 2025. A empresa lida com verificações de crédito e identificação de clientes para concessionárias de automóveis, e seus serviços estão conectados a um grande número de integrações com parceiros. De acordo com fontes abertas, os invasores primeiro obtiveram acesso ao sistema de um dos parceiros de integração e, em seguida, usaram uma API que permitia acessar os dados dos clientes.

Neste caso, não foi necessário invadir a rede interna da empresa, instalar malware ou usar uma cadeia complexa de vulnerabilidades. O ataque ocorreu através da camada de aplicação e integração confiável: as requisições pareciam chamadas de API, e não uma penetração clássica na infraestrutura. Como resultado, os dados de milhões de pessoas foram comprometidos, incluindo nomes, endereços, datas de nascimento e números de seguridade social.

Este exemplo ilustra bem um problema típico de segurança de API: nem sempre o atacante precisa de uma vulnerabilidade zero-day . Às vezes, basta encontrar um ponto de acesso que permita fazer mais do que deveria: solicitar em massa registros, testar identificadores, obter dados em volume incorreto ou usar um canal de parceiro contornando a lógica de negócios esperada.

Essas histórias se parecem cada vez menos com exceções.

De acordo com a Imperva/Thales , apenas na primeira metade de 2025, mais de 40 mil incidentes de API foram registrados. Entre as áreas atacadas estão APIs de acesso a dados, APIs de pagamento, métodos de autenticação, bem como pontos de acesso ocultos ou mal configurados.

A principal inconveniência de tais ataques é que eles frequentemente se parecem com requisições HTTP comuns. Não haverá necessariamente uma injeção SQL, um payload de shell ou um exploit de ruído de uma vulnerabilidade conhecida. O invasor pode simplesmente alterar parâmetros, chamar um método com muita frequência, acessar dados em um contexto incorreto ou usar uma API que não deveria estar acessível dessa forma.

Para o WAF, isso pode parecer uma requisição válida. Para o sistema de negócios — uma operação comum. Para a equipe de segurança — um incidente que só se tornará visível após a exportação em massa e análise de dados.

Segurança de API no mercado russo

O mercado russo está se movendo na mesma direção que o global, mas com suas particularidades: substituição de importações, crescimento do desenvolvimento interno, desenvolvimento de serviços móveis e requisitos regulatórios tornam o problema de inventário de API particularmente notável. Quanto mais as empresas aprimoram seus próprios sistemas, integram novas plataformas e transferem processos para canais digitais, mais pontos de acesso de API surgem, sobre os quais não apenas os desenvolvedores, mas também as equipes de segurança, operações e arquitetura devem estar cientes.

Relatórios setoriais mostram que as APIs estão se tornando cada vez mais um alvo independente para ataques, especialmente na camada de aplicação. Para uma loja online, banco, serviço de entrega ou portal de cliente, um ataque à API do catálogo, carrinho, pagamento, autorização ou verificação de status do pedido não é apenas "indisponibilidade do site". É a paralisação de um processo de negócios chave: o usuário não consegue fazer um pedido, pagar por um serviço, acessar seu portal ou obter dados sobre uma operação.

Nesse contexto, o problema de vazamento de dados pessoais persiste.

De acordo com a InfoWatch , em 2025, 739 incidentes de vazamento de informações de acesso restrito foram registrados em organizações russas, e o número de registros de dados pessoais comprometidos foi de 1,343 bilhão. Importante: nem todo vazamento desse tipo está relacionado a APIs. Mas as APIs estão se tornando cada vez mais um dos canais de acesso a dados — através de aplicativos móveis, portais de clientes, integrações com parceiros, serviços internos e trocas automatizadas entre sistemas.

Para empresas russas, o risco regulatório é adicionado ao risco técnico. A Lei Federal 152, os requisitos para infraestrutura de informação crítica e as políticas internas de segurança da informação pressupõem que a organização entenda onde os dados são processados e quais sistemas têm acesso a eles. Um Shadow API que retorna dados pessoais ou permite a execução de operações contornando o controle não é mais apenas uma lacuna na documentação. É um incidente potencial de segurança da informação, um risco legal e um indicador direto da imaturidade dos processos de gerenciamento de API.

De onde vêm os Shadow APIs

O paradoxo é que os Shadow APIs geralmente não surgem de má intenção ou de negligência flagrante. Eles surgem como um subproduto do desenvolvimento comum.

A equipe precisa fornecer dados rapidamente para um aplicativo móvel — surge um ponto de acesso separado no lado do servidor. Um parceiro precisa se conectar a um projeto piloto — uma rota temporária é configurada. A análise solicita uma exportação — um método interno /internal/export é adicionado. A equipe de DevOps abre um Ingress temporário para diagnóstico. Em um mês, todos mudam para novas tarefas, e o ponto de acesso continua funcionando.

Figura 2. Como um ponto de acesso temporário gradualmente se torna um Shadow API

Em seguida, vem a parte mais interessante. O endpoint de API já está sendo usado por alguém, mas ninguém tem certeza de quem. Desativá-lo é assustador. Ele não foi adicionado à documentação. O proprietário da tarefa mudou para outra equipe. Seis meses depois, não é mais uma solução temporária, mas parte do circuito de produção que ninguém controla adequadamente.

As fontes típicas de Shadow API parecem assim: Microsserviços e lançamentos rápidos . Quando há dezenas ou centenas de serviços e os lançamentos ocorrem diariamente, um registro centralizado rapidamente fica para trás da realidade. Especialmente se o registro de API permanecer um processo manual.

Aplicativos móveis e SPAs . O backend para o frontend muitas vezes vive separadamente do API Gateway principal. A equipe de desenvolvimento móvel conhece seus endpoints, mas eles nem sempre entram no catálogo geral. Ao mesmo tempo, basta que o atacante analise o tráfego de rede ou descompile o aplicativo para ver os endereços reais.

Integrações com contratados. Uma API temporária para um projeto piloto muitas vezes sobrevive ao próprio piloto. A documentação pode permanecer na correspondência, o responsável pode se demitir, e o ponto de acesso pode continuar funcionando.

Legado e versões antigas. A versão antiga não é desativada porque "talvez haja clientes". Um ano depois, ninguém mais sabe quem são esses clientes, mas o ponto de acesso continua recebendo requisições.

Circuitos de teste e depuração. O ambiente de teste foi acidentalmente exposto externamente. Um método de depuração foi esquecido de ser fechado antes do lançamento. Um ambiente temporário para verificar alterações não foi removido após a mesclagem do código. No Kubernetes e na infraestrutura em nuvem, esses cenários acontecem com mais frequência do que gostaríamos.

Em todos os casos, o problema não está no próprio ponto de acesso. O problema é que ele surgiu mais rápido do que a segurança, as operações e o proprietário do produto souberam dele.

Por que as ferramentas comuns não os detectam

Aqui geralmente surge a pergunta: "Nós temos um API Gateway, WAF, OpenAPI, scanner e SIEM. Por que isso não é suficiente?"

Porque cada ferramenta vê apenas sua própria camada.

Ferramenta O que vê O que frequentemente não vê API Gateway Rotas registradas APIs que operam contornando o API Gateway e chamadas diretas aos serviços WAF Tráfego que passa pelo WAF APIs internos, ambientes de teste, rotas Ingress diretas OpenAPI/Swagger Contrato documentado O que está realmente implantado e aceita requisições SAST/análise de código Rotas no código Quais rotas são publicadas e usadas em produção SIEM/APM Eventos, logs e métricas Contexto de negócios, proprietários e sensibilidade dos dados CMDB Sistemas e serviços Detalhes até o ponto de acesso, método, versão e parâmetros

O API Gateway é uma boa ferramenta de gerenciamento, mas não um registro completo de API. Ele vê apenas as rotas que foram registradas através dele. Shadow APIs frequentemente vivem ao lado: um Ingress separado, um host desatualizado, um domínio temporário, uma chamada direta de um serviço para outro, uma integração com parceiro.

OpenAPI é uma declaração. Ele mostra como a API deve parecer de acordo com a documentação. Mas apenas o tráfego real mostrará o que realmente funciona e aceita requisições.

Scanners e pentests também são limitados pelo escopo da verificação. Se um ponto de acesso não entrou no registro, ele também não entrou na tarefa de teste. Isso cria um ciclo vicioso: testamos apenas o que já sabemos, e as zonas cegas permanecem cegas.

Portanto, o inventário de API não pode ser construído apenas com base nas declarações das equipes. Um registro manual de API não se torna obsoleto "com o tempo". Ele se torna obsoleto no momento da próxima entrega de alterações.

Como deve ser um inventário de API normal

Um catálogo de API não é uma lista de endereços.

Se o registro contém apenas GET /users/{id} , isso é insuficiente para gerenciar riscos. É necessária uma ficha de endpoint de API que responda a perguntas práticas: onde o endpoint está localizado: ambiente de produção, ambiente de teste, ambiente de homologação, ambiente de desenvolvimento; quem é o proprietário: equipe, serviço, unidade de negócios; qual método e caminho são usados: GET, POST, PUT, DELETE, caminho normalizado; qual tipo de API é usado: REST, GraphQL, gRPC, WebSocket, SOAP; qual o nível de acesso da API: público, parceiro, interno, inter-serviços; por onde passa o tráfego de rede: API Gateway, WAF, Ingress; quais dados são processados: dados pessoais, dados de pagamento, segredos comerciais, dados técnicos; quais autenticação e autorização são usadas; existe uma especificação OpenAPI ou outro contrato formalizado; quando o endpoint foi chamado pela última vez; quais clientes o utilizam; existe uma versão antiga; existe um plano de desativação.

Apenas um inventário como este pode ser usado para priorização. Nem todos os Shadow APIs são igualmente perigosos. Um endpoint que fornece um diretório de cidades e um endpoint que retorna os dados do passaporte do cliente exigem reações diferentes.

Como começar a procurar Shadow APIs

É impossível se livrar completamente dos Shadow APIs: novas interfaces sempre surgirão. Mas é possível fazer com que eles permaneçam ocultos não por meses, mas por horas ou dias.

Para começar, não é necessária uma plataforma grande e um projeto de vários meses. Basta realizar o primeiro ciclo de descoberta e reconciliação de APIs.

Figura 3. Um inventário de API atualizado é coletado de várias camadas

Exportar fontes oficiais. Colete a lista de APIs do API Gateway, OpenAPI/Swagger, coleções Postman, Confluence, CMDB e catálogo de serviços. 2. Coletar rotas de infraestrutura . Verifique Kubernetes Ingress, service mesh, proxy reverso, balanceadores de carga, registros DNS, certificados e regras de firewall. 3. Coletar a imagem real do tráfego. Pegue os logs de acesso do WAF, NGINX/Envoy, API Gateway, APM ou SIEM por pelo menos 7-14 dias. É importante observar não apenas o perímetro externo, mas também o tráfego de rede interno, se possível. 4. Normalizar os caminhos . Rotas como GET /users/123 e GET /users/456 deveriam se transformar em GET /users/{id} . Caso contrário, você obterá não um inventário de API, mas ruído de endereços semelhantes. 5. Comparar a imagem real com a documentação. Tudo o que está no tráfego, mas ausente nas fontes oficiais, é um candidato a Shadow API. Tudo o que está na documentação, mas não é chamado há muito tempo, é um candidato a Zombie API. 6. Atribuir proprietários. Um endpoint sem proprietário é um risco separado. Se ninguém consegue explicar para que serve, isso é um motivo não apenas para adicioná-lo à tabela, mas para iniciar uma análise. 7. Priorizar . Comece com APIs públicos, métodos de alteração de dados, endpoints com dados pessoais, operações de pagamento, rotas administrativas e de depuração, bem como versões antigas. 8. Integrar o controle no CI/CD. Um novo endpoint deve entrar no inventário não um mês após o lançamento, mas no momento em que aparece no código, especificação ou tráfego real. O que fazer com as APIs encontradas Um Shadow API encontrado geralmente tem quatro destinos.

Figura 4. Quatro soluções possíveis para um Shadow API encontrado

Registrar e manter. A API é necessária para o negócio, mas vivia fora do processo de gerenciamento. Adicionamos proprietário, descrição, classe de dados processados, requisitos de autenticação e autorização, monitoramento e verificações de segurança.

Restringir o acesso. A API é necessária, mas não deve ser pública. Nós a protegemos através do API Gateway, políticas de rede, mTLS, lista de fontes permitidas, VPN ou autenticação inter-serviços.

Corrigir. A API é necessária, mas implementada de forma insegura: retorna dados extras, não verifica os direitos de acesso ao objeto, não limita a frequência das requisições, usa autenticação fraca ou lógica de negócios desatualizada.

Remover. O endpoint não é usado, o proprietário não foi encontrado, não há valor de negócio. Portanto, ele deve ser desativado, e não mantido "por via das dúvidas". Para a gerência, é melhor traduzir isso em métricas, e não em riscos abstratos: quantos endpoints de API foram descobertos no total; quantos foram encontrados apenas no tráfego real; quantos estão ausentes no OpenAPI; quantos não têm proprietário; quantos estão publicamente acessíveis; quantos operam com dados pessoais ou de pagamento; quantos contornam o API Gateway ou WAF; quantas versões antigas continuam respondendo a requisições; quantos APIs não foram chamados por 30, 60 ou 90 dias; quantos endpoints foram fechados, corrigidos ou removidos durante o período. A principal métrica de maturidade não é o número total de APIs. A principal métrica é a proporção de APIs ativos que estão sob gerenciamento.

Em vez de conclusão

Shadow API não é uma ameaça exótica nem um erro raro de uma equipe específica. É uma consequência estrutural do desenvolvimento moderno: rápido, distribuído e via API.

O desenvolvimento cria novas interfaces todos os dias. Segurança e operações frequentemente as descobrem mais tarde. A documentação fica para trás do código. O API Gateway não vê tudo. Testes de penetração verificam apenas o que entrou no escopo da verificação. Como resultado, a empresa não protege a totalidade das APIs, mas apenas a parte que conseguiu ver.

É por isso que nós na CodeScoring decidimos desenvolver a área de API Security. Nossa equipe vê que o problema se torna cada vez mais relevante para as empresas russas: as APIs estão aumentando, as arquiteturas estão se tornando mais complexas, os requisitos de proteção de dados estão crescendo, e o software doméstico que ajuda a descobrir, inventariar e controlar APIs de forma sistemática ainda é escasso. Por isso, reforçamos a equipe e estamos preparando um novo produto que ajudará as empresas a ver a imagem real de suas APIs — do código e infraestrutura ao tráfego de rede real.

Mas o primeiro passo honesto não é comprar mais uma ferramenta nem escrever um novo regulamento. O primeiro passo é verificar o quão bem sua imagem corresponde à realidade.

Pegue um espelho de tráfego de rede ou logs de acesso por uma semana. Normalize os caminhos. Compare-os com o registro oficial e o OpenAPI. Se as listas coincidirem — parabéns, você tem um nível raro de maturidade. Se não — você finalmente verá não as APIs que deveriam existir de acordo com a documentação, mas as que realmente existem.

E é a partir deste momento que a conversa sobre API Security se torna concreta.

Tags: codescoring shadow api api security appsec segurança da informação owasp api gateway auditoria de segurança vulnerabilidades de api