Toda vez que você abre uma aplicação, acontece muito mais do que o que aparece na tela. Ao consultar a previsão do tempo, seu telefone nunca mede a temperatura externa; ele solicita a leitura mais recente a um serviço meteorológico. Ao fazer login em um site novo com sua conta do Google, esse site nunca vê sua senha; ele pede ao Google que responda por você. Cada uma dessas trocas viaja por meio de uma interface de programação de aplicações (API), e um único toque pode desencadear dezenas delas em segundo plano.
As APIs são o tecido conjuntivo do software moderno e, silenciosamente, tornaram-se uma das partes mais amplas e menos compreendidas da superfície de ataque de uma organização. Antes de abordar por que elas atraem os atacantes e como defendê-las, convém saber o que é realmente uma API.
O que é uma API?
Uma API é um conjunto de regras que permite a um software solicitar dados ou ações de outro, em um formato que ambas as partes concordaram antecipadamente. Ela define quais requisições são permitidas, como cada uma deve ser redigida, quais informações carrega e qual a estrutura do retorno.
Imagine uma única troca. O programa que faz a requisição é o cliente e o que responde é o servidor. O cliente envia uma requisição a um endereço específico exposto pela API, chamado endpoint, e o servidor realiza o trabalho por trás desse endpoint e devolve uma resposta, normalmente um bloco de dados estruturados. O cliente nunca precisa saber como o servidor funciona por dentro; precisa apenas saber como perguntar e como ler a resposta.
Essa separação é a razão pela qual as APIs estão em toda parte. Uma equipe que cria um produto não precisa escrever seu próprio motor de mapas, processador de pagamentos ou sistema de login; pode invocar um serviço que já realiza essas tarefas e usar os resultados. Uma aplicação típica é montada a partir de muitas chamadas desse tipo, algumas a serviços da própria organização e outras a terceiros. Esse alcance também é a razão pela qual protegê-las é uma disciplina própria: a segurança de uma aplicação depende agora de cada porta que ela abre para o exterior.
Os principais tipos de APIs
As APIs vêm em vários estilos de arquitetura, e as diferenças determinam como os dados se movem e para onde se concentra a atenção em matéria de segurança. Quatro tipos abrangem a maioria dos que você encontrará.
REST (transferência de estado representacional) está por trás da maioria das APIs web atuais. Usa métodos HTTP comuns para atuar sobre recursos identificados por uma URL: basicamente, GET para ler, POST para criar, PUT para atualizar e DELETE para remover. Não tem estado, o que significa que cada requisição carrega tudo o que o servidor precisa, e costuma enviar os dados em formato JSON, um formato de texto leve. REST não tem segurança própria; a proteção é adicionada pela forma como a API é projetada e implementada.
SOAP (protocolo simples de acesso a objetos) é mais antigo e mais rígido. Envolve as mensagens em XML e carrega extensões de segurança padronizadas, conhecidas como WS-Security, que podem assinar e cifrar mensagens individuais. Continua comum no setor bancário e de pagamentos, onde as exigências de conformidade são altas. Convém ser preciso neste ponto, já que algumas descrições dão a entender que o SOAP é seguro por padrão: os padrões existem, mas ainda precisam ser implementados corretamente para oferecer qualquer proteção.
GraphQL expõe um único endpoint e permite que o cliente solicite exatamente os campos que deseja. Essa flexibilidade reduz o desperdício de dados, mas transfere o trabalho ao servidor, que precisa lidar com consultas cujo custo ele não consegue prever totalmente. Uma consulta profundamente aninhada ou em lote pode exigir muito mais do que sua aparência simples sugere, por isso as APIs GraphQL se apoiam em limites de profundidade de consulta e tempos limite.
Os estilos RPC (chamada de procedimento remoto), incluindo o moderno gRPC, permitem que um cliente invoque uma função em um servidor remoto como se ela fosse executada localmente. Adaptam-se a serviços internos fortemente acoplados, em que a velocidade e um contrato fixo importam mais do que a compatibilidade ampla.
O que é a segurança de APIs?
Se as APIs são as portas entre os sistemas de software, a segurança de APIs é a prática de garantir que apenas as pessoas certas passem por elas, que levem apenas o que lhes é permitido levar e que ninguém possa deixar uma porta aberta ou se esgueirar por outra que tenha ficado destrancada. Dito com mais precisão, a segurança de APIs é o conjunto de práticas e controles que protegem as APIs contra acesso não autorizado, exposição de dados, abuso e interrupção ao longo de todo o seu ciclo de vida, do projeto até a desativação.
Muitas definições giram em torno de si mesmas, descrevendo o campo como "segurança para as suas APIs". A essência está no que se protege: a confidencialidade, a integridade e a disponibilidade dos dados e serviços que uma API expõe.
Uma API não se protege sozinha apenas porque o aplicativo por trás dela tem uma tela de login ou está atrás de um firewall. As APIs expõem diretamente a lógica do aplicativo e os dados, muitas vezes a clientes que a organização não controla, e tendem a atender qualquer requisição que chegue corretamente formatada e autenticada, mesmo uma elaborada para alcançar algo que jamais deveria. Proteger uma API significa examinar cada requisição em seus próprios termos: quem está pedindo, se pode realizar essa ação sobre esses dados e se a requisição tenta fazer algo para o qual a API nunca foi concebida.
Qual a diferença entre segurança de APIs e segurança de aplicações?
A segurança de APIs faz parte da segurança de aplicações, mas as APIs são construídas e atacadas de forma suficientemente diferente para que tratá-las como páginas web comuns deixe lacunas. Três diferenças se destacam:
A primeira é o tamanho e o formato da superfície de ataque. Uma aplicação web tradicional é criada principalmente para um tipo de visitante, uma pessoa diante de um navegador, e boa parte de sua defesa se concentra em como a entrada (input) dessa pessoa é tratada na tela. Uma API atende a muitos clientes ao mesmo tempo: aplicativos móveis, frontends web, sistemas de parceiros, serviços internos e outras APIs. Cada endpoint é mais uma via de entrada (as APIs expõem muitos deles), e as equipes adicionam e alteram endpoints constantemente, de modo que a superfície é mais ampla e dinâmica.
A segunda é como a identidade é estabelecida. As aplicações web se apoiam em sessões e cookies, muitas vezes reforçados por uma verificação de duplo fator que uma pessoa pode responder. As APIs costumam se autenticar por meio de tokens ou chaves transmitidos em cada requisição, como tokens OAuth ou JSON Web Tokens. Um token de API costuma ser o único fator que separa um atacante de uma conta, sem que haja uma pessoa presente para responder a um segundo desafio, o que torna os tokens roubados ou falsificados especialmente valiosos e o abuso automatizado mais difícil de distinguir do tráfego legítimo.
A terceira diferença é a que mais importa. Os ataques web clássicos costumavam ser de "uma só tentativa": uma única requisição com uma carga maliciosa (payload) conhecida dirigida a uma fraqueza conhecida. Isso ainda acontece, mas os ataques a APIs mais custosos são diferentes. Como cada API codifica sua própria lógica de negócio, os ataques mais graves são abusos lentos e pacientes dessa lógica, mais do que exploits genéricos. Um atacante passa dias, semanas ou até meses aprendendo como uma API se comporta, como seus endpoints se relacionam, qual sequência de chamadas de aparência corriqueira produz um resultado extraordinário, e então automatiza o abuso. Em sentido estrito, cada um desses ataques é personalizado, razão pela qual as ferramentas que funcionam comparando o tráfego com assinaturas de ataques conhecidos tendem a deixá-los passar por completo. A sequência maliciosa é composta por requisições individualmente válidas.
Por que a segurança de APIs é importante?
Até o final de 2025, metade do tráfego web dinâmico observado pela Cloudflare estava relacionada a APIs, e essa proporção continua aumentando. A maior parte é automatizada, software conversando com software, que é exatamente o tipo de tráfego que oculta bem o abuso. Cada chamada é uma solicitação para fazer ou entregar algo, e cada uma é um alvo potencial.
A indústria já previa isso. Em um relatório de 2017, a Gartner previu que, até 2022, o abuso de APIs se tornaria o vetor de ataque mais frequente por trás de vazamentos de dados em aplicações web corporativas. Essa era uma previsão em vez de um fato medido, mas os anos seguintes confirmaram essa tese. Quando uma API é comprometida, os atacantes podem acessar diretamente os dados e as funcionalidades que estão por trás dela, roubando registros, esvaziando contas ou interrompendo o serviço. As consequências incluem sanções regulatórias sob marcos normativos como o GDPR e a CCPA, além do desgaste gradual da confiança dos clientes.
Duas violações recentes mostram o quanto os erros subjacentes costumam ser comuns. Em janeiro de 2023, a T-Mobile revelou que um atacante havia usado uma única API para extrair dados de cerca de 37 milhões de contas. A extração ocorreu sem ser detectada do fim de novembro de 2022 até o início de janeiro de 2023, cerca de seis semanas de requisições de aparência válida drenando registros antes que alguém percebesse.
O caso da Optus é mais alarmante por ter sido tão básico. Em setembro de 2022, a operadora australiana expôs dados de cerca de 10 milhões de clientes. Mais tarde, o órgão regulador do país descreveu o ataque em um processo judicial como uma simples tentativa e erro. Um endpoint estava em um domínio voltado para a Internet sem exigir autenticação, e esse único descuido abriu a porta para todo o resto. Os tipos de fraqueza por trás de ambas as violações têm, cada um, um nome na lista padrão de riscos de APIs do setor.
O OWASP API Security Top 10
A referência comum para o que dá errado com APIs é o OWASP API Security Top 10, mantido pela organização sem fins lucrativos Open Worldwide Application Security Project. A edição atual foi publicada em 2023 e substituiu a lista original de 2019. Algumas entradas foram renomeadas, duas antigas (exposição excessiva de dados e atribuição em massa) foram fundidas em uma única categoria, e preocupações novas foram adicionadas, como o consumo inseguro de APIs de terceiros. Uma ideia percorre quase toda a lista: o cliente controla a requisição, e o servidor nunca deve presumir que a requisição é honesta.
API1. Autorização quebrada em nível de objeto. Este é o risco de API mais comum e prejudicial. Ocorre quando uma API verifica que você fez login, mas não confirma que o item específico que você solicita realmente pertence a você. As APIs identificam as coisas constantemente por um ID na requisição: um número de pedido, um ID de usuário ou uma referência de conta. Se o servidor não confirma que você tem permissão para tocar nesse objeto em particular, você pode mudar o ID e acessar os dados de outra pessoa. Considere uma API que devolve uma fatura:
A requisição está devidamente autenticada, de modo que um servidor descuidado devolve a fatura 4517. Nada impede o usuário de pedir em seguida a 4518 e a 4519, e assim por diante, coletando faturas que pertencem a outros. Identificadores sequenciais como esses são o que permitiu ao atacante da Optus percorrer todo um banco de dados de clientes.
API2. Autenticação quebrada. A autenticação é a forma como uma API verifica que você é quem diz ser, e os endpoints que a gerenciam (login, redefinição de senha, emissão de tokens) estão expostos a todos, o que os torna alvos principais. Uma API é vulnerável quando permite senhas fracas, possibilita tentativas ilimitadas de adivinhação ou não valida os tokens que aceita. Uma fraqueza frequente e subestimada do GraphQL é que um cliente pode agrupar várias operações em uma única requisição. Se uma API limita as tentativas de login a algumas por minuto, mas não leva em conta o processamento em lote, um atacante pode burlar esse limite enviando dezenas de tentativas dentro de uma só chamada:
Para o limitador de taxa de requisições, isso parece uma única requisição, mas, na realidade, contém várias tentativas de senha.
API3. Autorização quebrada em nível de propriedade de objeto. Enquanto o primeiro risco se refere ao acesso a um objeto inteiro, este se refere aos campos individuais dentro dele. Uma API pode devolver campos que deveria ocultar ou aceitar campos que deveria ignorar. A segunda forma, conhecida há tempos como atribuição em massa, é fácil de imaginar. Suponha que uma plataforma de vídeo permita que os usuários editem a descrição de um vídeo por meio desta requisição:
Um usuário cujo vídeo foi bloqueado repete a requisição e adiciona um campo que a interface nunca ofereceu:
Se o servidor mapeia cegamente os campos recebidos sobre o objeto armazenado, o usuário acaba desbloqueando o próprio conteúdo apenas adivinhando o nome de uma propriedade. O mesmo truque pode mudar um preço, conceder um papel ou alterar qualquer indicador interno que o desenvolvedor supôs que só o sistema controlava.
API4. Consumo irrestrito de recursos. Cada requisição custa algo: largura de banda, memória, tempo de processamento e, às vezes, dinheiro, como quando uma chamada envia uma mensagem de texto por meio de um provedor pago. Sem limites quanto à frequência ou à intensidade com que pode ser chamada, uma API pode sair do ar ou acumular uma fatura enorme. Um fluxo de redefinição de senha que envia um SMS pago a cada tentativa, disparado dezenas de milhares de vezes por um script, custa um dinheiro considerável em questão de minutos.
API5. Autorização quebrada em nível de função. O primo do primeiro risco: em vez de acessar os dados de outro usuário, o atacante alcança as ações de outro papel. Aparece quando uma API não impõe que apenas certos usuários possam realizar certas operações, especialmente as administrativas. O sinal revelador é se um usuário comum consegue fazer algo privilegiado apenas adivinhando o endpoint certo ou mudando o método da requisição, por exemplo, chamando um endpoint exclusivo de administradores que cria uma conta com papel de administrador.
API6. Acesso irrestrito a fluxos de negócio sensíveis. Alguns ataques exploram uma funcionalidade que opera exatamente como foi projetada, numa escala para a qual ela nunca foi pensada. Um caso comum é a revenda especulativa (scalping): um varejista lança um produto escasso e de alta demanda, e um atacante programa, por meio de scripts, o fluxo de compra para adquirir todo o estoque no instante do lançamento, e depois o revende com sobrepreço. Nenhum endpoint está quebrado; nenhum dado vaza; simplesmente o fluxo de compra não estava protegido contra a automação em massa.
API7. Falsificação de requisições do lado do servidor. Isso ocorre quando uma API busca um recurso em um endereço web fornecido pelo cliente sem verificar para onde ele aponta. Como a requisição parte do servidor, ela pode alcançar sistemas internos a que um agente externo não tem acesso. Por exemplo, uma funcionalidade que carrega uma foto de perfil a partir de uma URL pode ser apontada para um endereço interno de metadados na nuvem que devolve as próprias chaves de acesso do servidor, ou seja, o tipo de exposição de credenciais que abordamos no escaneamento de segredos.
API8. Configuração incorreta de segurança. Uma categoria ampla de ajustes e fortalecimentos que passam despercebidos: patches ausentes, funcionalidades desnecessárias deixadas ativas, falta de criptografia, regras de origem cruzada (CORS) permissivas e mensagens de erro que vazam detalhes internos. Um exemplo memorável é um tipo de ataque em que um componente de registro (logging) vulnerável interpreta e executa no servidor um valor manipulado em um cabeçalho de requisição, transformando uma entrada de registro comum em uma execução remota de código.
API9. Gestão inadequada de inventário de ativos. Não se pode proteger o que não se sabe que se tem. Esse risco consiste em perder o controle das APIs e dos dados que elas tocam: versões antigas deixadas em funcionamento, endpoints não documentados ou esquecidos, hosts de teste e de pré-produção expostos à Internet e registros pouco claros sobre quais terceiros recebem seus dados. O endpoint da Optus que vazou quase 10 milhões de registros vivia em um domínio esquecido que permaneceu on-line depois que a correção chegou apenas ao domínio principal. Um controle de segurança colocado na frente da API atual não serve de nada se ainda for possível acessar uma versão mais antiga da API em outro lugar.
API10. Consumo inseguro de APIs. O último risco muda a perspectiva para as APIs que você consome, em vez das que você expõe. Os desenvolvedores tendem a confiar nos dados de um serviço de terceiros, especialmente um conhecido, mais do que confiam na entrada direta de um usuário do próprio sistema. Se esse serviço for comprometido ou simplesmente se comportar de forma inesperada, os dados que ele devolve podem introduzir um ataque no seu sistema. Por exemplo, um serviço que segue cegamente um redirecionamento de um terceiro pode ser induzido a reenviar dados confidenciais de um usuário a um endereço controlado pelo atacante.
Anatomia de um ataque a uma API
Os dez riscos raramente aparecem um de cada vez. Uma violação grave em uma API costuma encadear vários deles, cada passo comum por si só, até um resultado que é tudo menos comum. Percorrer um exemplo inventado, mas realista, mostra como as peças se encaixam e por que uma defesa que vigia assinaturas de ataques conhecidos tende a não ver o quadro completo.
Imagine uma loja on-line cujo aplicativo móvel se comunica com um backend por meio de uma API. Um atacante começa pelo reconhecimento, a primeira fase de qualquer intrusão real. Ao inspecionar o tráfego do aplicativo, ele mapeia os endpoints que este chama e percebe um padrão de nomenclatura. Testando variações, encontra um endpoint anterior, api.store.com/v1/, que continua respondendo às requisições muito depois de o aplicativo ter passado para a versão v2. Ninguém o vigia, porque ninguém se lembra de que ele existe. Isso é uma gestão inadequada de inventário (API9), e constitui o ponto de apoio inicial.
O atacante sonda o endpoint esquecido e descobre que ele nunca pergunta quem ele é. A autenticação que protege a versão atual só foi adicionada na frente da v2; a cópia antiga ficou aberta. A autenticação quebrada (API2) significa que ele agora pode chamá-lo livremente, como qualquer usuário anônimo.
Em seguida, ele estuda o que o endpoint retorna. Uma requisição para /v1/orders/10231 entrega o pedido de outro cliente, acompanhado de nome, endereço e os últimos dígitos de um cartão. O endpoint não verifica nada sobre a quem pertence o pedido 10231. Isso é uma autorização quebrada em nível de objeto (API1), e os números de pedido são sequenciais, de modo que cada registro está a um dígito de distância do anterior.
O último passo é a automação. Sem nenhum limite de taxa, consumo irrestrito de recursos (API4), o atacante escreve um pequeno script que percorre em ordem crescente os números de pedido e extrai um registro a cada volta. Cada requisição é válida individualmente, está bem estruturada e é indistinguível de uma chamada legítima. Não há nenhuma carga maliciosa a detectar, nenhuma cadeia de exploit conhecida a sinalizar. Ao longo de horas ou dias, o script drena silenciosamente o banco de dados.
Nenhum passo aqui foi sofisticado. O dano veio de quatro pequenos descuídos que se alinharam, com a mesma forma da violação da Optus, e pela mesma razão pela qual as ferramentas baseadas em assinaturas têm dificuldade: nada na sequência parece um ataque até que você dê um passo atrás e veja tudo em conjunto.
Melhores práticas de segurança de APIs
Proteger as APIs é menos um produto único do que um conjunto de hábitos aplicados de forma contínua, do primeiro esboço de projeto até o dia em que uma API é desativada. As práticas a seguir abordam os riscos anteriores sem tratar nenhum deles de forma isolada.
Conheça o que você tem, porque não dá para defender um endpoint que você esqueceu. Mantenha um inventário atualizado de cada API, host e versão; descubra de forma ativa as APIs ocultas (shadow), obsoletas e de terceiros; desative as versões antigas de maneira deliberada; e mantenha os dados reais dos clientes fora dos ambientes de teste e de pré-produção.
Exija autenticação e autorização em cada requisição. Confirme quem está chamando e, separadamente, verifique o que pode fazer, checando a permissão para o objeto específico e a função específica antes de agir. Negue o acesso por padrão, conceda o menor privilégio necessário, valide cada token, adicione autenticação multifator onde puder e apoie-se em padrões comprovados em vez de esquemas "caseiros".
Valide a entrada e limite o consumo. Trate cada requisição como não confiável, aceite apenas os campos e formatos que você espera, e rejeite o restante. Aplique limites de taxa e cotas, restrinja o tamanho e a quantidade de operações por requisição, e configure alertas de gasto para qualquer serviço de terceiros pago que uma chamada possa acionar.
Criptografe os dados em trânsito. Envie todo o tráfego da API por TLS, o protocolo que sustenta o HTTPS, tanto nas chamadas internas quanto nas públicas, de modo que o tráfego interceptado não revele nada.
Desconfie das APIs que você consome. Valide e sanitize os dados dos serviços de terceiros com o mesmo rigor que a entrada de um usuário, restrinja para onde a sua API pode enviar requisições e nunca siga redirecionamentos para destinos não verificados.
Integre a segurança desde o início e faça testes de forma contínua. Leve a segurança às revisões de projeto, incluindo a lógica de negócio que os atacantes sondam, e aplique os patches de segurança assim que forem divulgados. Combine o escaneamento automatizado e o fuzzing, que detectam com rapidez falhas conhecidas e casos extremos, com testes de penetração manuais, que revelam as falhas de lógica e de controle de acesso que as ferramentas não conseguem. Registre e monitore a atividade para reduzir a janela em que o abuso passa despercebido, e refaça os testes após cada correção para confirmar que ela se sustenta.
Fluid Attacks ajuda a proteger suas APIs
Na Fluid Attacks, protegemos APIs e microsserviços como parte de uma abordagem contínua e abrangente da segurança de aplicações ao longo de todo o ciclo de vida de desenvolvimento. Combinamos o escaneamento automatizado com o trabalho manual de pentesters certificados, incluindo testes de penetração, revisão de código seguro e engenharia reversa, para detectar as falhas de lógica de negócios que as ferramentas sozinhas deixam passar, reunindo tudo em uma única plataforma com taxas mínimas de falsos positivos e orientação clara para a remediação. Inicie um teste gratuito para começar a testar suas APIs hoje mesmo.
