Três pontos que todo CISO precisa saber sobre segurança de APIs

No terceiro episódio do F5 Global CISO: Para defensores, por defensores, convidei Corey Ball, um dos meus hackers de API favoritos. Corey atua em TI e segurança cibernética há 15 anos e escreveu literalmente o livro sobre hacking de APIs, ao perceber que havia pouca informação consolidada sobre o tema. Foi assim que nos conhecemos.

O livro é Hacking APIs: Quebrando Interfaces de Programação de Aplicações Web, que oferece um curso intensivo sobre testes de segurança em APIs web. Corey também fundou a APIsec University, um recurso gratuito para aprender sobre segurança de APIs, e é fundador e CEO da hAPI Labs, que realiza testes de segurança em APIs e penetração em aplicações web.

Corey é, sem dúvida, um especialista em segurança de APIs, então lhe fiz a pergunta principal do dia: Quais são as três coisas que todo CISO precisa saber sobre segurança de APIs? Mais especificamente, quis saber o que ele acredita que os defensores podem aprender ao analisar a segurança de APIs do ponto de vista dos atacantes.

APIs são a tecnologia responsável pela transferência de dados — um dos recursos mais valiosos do mundo. “Mas, mesmo implementando camadas de proteção como firewalls e firewalls para aplicativos web para proteger esses dados,” disse Corey, “APIs expostas à internet podem se tornar portas de entrada para ataques.” Se existir uma API sem segurança, que não exija autenticação nem aplique autorização, ela cria uma brecha direta para atacantes que podem fazer solicitações não autorizadas e roubar dados protegidos pelas outras camadas.

“Quero garantir que os defensores entendam a importância de usar as ferramentas e abordagens corretas para testar a segurança da API,” afirmou ele. Não basta apontar um scanner automatizado para uma API, receber um relatório limpo e assumir que está tudo seguro. Você precisa testar e analisar ativamente as solicitações da API para identificar problemas reais e corrigir qualquer exposição de segurança existente.

Testando seus testadores. Uma forma prática de validar suas habilidades e ferramentas de teste, segundo Corey, é praticar contra aplicações intencionalmente vulneráveis, alvos seguros e criados para que você experimente, reproduza e compreenda problemas comuns de segurança em APIs. “Por exemplo, o OWASP API Security Project oferece o crAPI, uma ferramenta de treinamento repleta de vulnerabilidades de API, criada para ensinar, aprender e praticar segurança em APIs. Você pode apontar seu scanner diretamente para o crAPI e verificar os resultados que obtém.” Se encontrar apenas vulnerabilidades superficiais, como falta de cabeçalhos HSTS ou proteções contra clickjacking mal configuradas, sua ferramenta pode estar deixando passar vulnerabilidades mais graves, como as listadas no OWASP API Top 10.  “Isso mostraria que suas ferramentas de teste podem não ser tão eficazes quanto imagina,” alertou Corey.

Corey e eu também conversamos sobre o fato de que ferramentas tradicionais de gerenciamento e análise de vulnerabilidades corporativas não funcionam para APIs, pois as APIs são vulneráveis a tipos de ataques diferentes daqueles que visam aplicações web tradicionais. Por exemplo, autorização quebrada a nível de objeto (BOLA) e autorização quebrada a nível de propriedade do objeto (BOPLA) são falhas de segurança específicas de API que estão relacionadas à lógica central de negócios da API. Perguntei ao Corey: se uma empresa já tem um WAF e um gateway de API implantados, o que ainda falta para proteger efetivamente as APIs?

WAFs e gateways de API são fundamentais para a segurança das aplicações e autenticação dos usuários, afirmou ele, mas não bastam para proteger APIs por conta própria. O maior desafio para proteger APIs é a autorização, que garante que os usuários só acessem, visualizem, modifiquem ou excluam seus próprios dados. “Você deve garantir que o usuário A interaja apenas com os recursos do usuário A. Ele não pode alterar, ler, atualizar ou excluir os recursos do usuário B”, explicou. “A autorização em APIs é realmente complexa. O pedido de um invasor tentando acessar recursos de outra pessoa quase sempre se parece com um pedido legítimo, a menos que existam regras de autorização muito detalhadas.”

Você deve incluir controles de autorização em uma abordagem multicamadas para segurança de API, combinando controles complementares para garantir proteção mesmo se uma camada falhar.

À medida que você investe mais em IA generativa e em aplicações impulsionadas por IA, precisa compreender que essas tecnologias ampliam a superfície de ataque das APIs. Isso acontece porque as aplicações de IA generativa são APIs “em todos os níveis.” Ou seja, um mundo onde a IA prevalece é também um mundo de APIs; a estrutura fundamental dessas aplicações depende intensamente de APIs, e quase todos os componentes do sistema de IA estão expostos por meio dessas interfaces.

Mas, como Corey e eu discutimos, as APIs representam apenas parte do desafio de proteger aplicativos e arquiteturas de IA: Os motores de IA e os grandes modelos de linguagem (LLMs) também expõem outras vulnerabilidades a ataques. Por exemplo, o Model Context Protocol (MCP) é um padrão open source que cria uma estrutura única para conectar LLMs a ferramentas e serviços externos. Embora o MCP traga muitos benefícios para integrar IA em aplicativos, ele também gera desafios significativos de segurança. “Quando você entende o funcionamento da IA generativa”, disse Corey, “ela já depende de várias APIs, e aí entram os MCPs, que geralmente são vulneráveis por controles fracos de autenticação e autorização — apesar de as proteções de segurança estarem evoluindo.”

Outra preocupação de segurança dos MCPs são os ataques de injeção de prompt e o hacking por linguagem natural. “Eles podem gerar riscos para a empresa quando agentes de IA e chatbots representam seu negócio. Invasores podem manipular seus agentes de IA para emitir declarações prejudiciais que não refletem sua empresa, ou induzir chatbots a conceder descontos não autorizados.” É fundamental que as organizações compreendam que chatbots podem ser considerados representantes legais da empresa e responsabilizados pelas suas declarações e ações. Você precisa agir com cautela: não pode perder as oportunidades que as aplicações de IA oferecem, mas deve garantir, com diligência, que esses recursos e chatbots sejam treinados com dados precisos e protegidos contra injeções de prompt.

É sempre um prazer conversar com Corey, e agradeço por aceitar meu convite para discutir o que podemos aprender sobre segurança ao olhar pela perspectiva do atacante. Como defensores, precisamos que nossa defesa seja guiada pelo entendimento do ataque. Por isso, é fundamental compreendermos como operam essas ameaças e o que elas buscam, para direcionar nossos recursos de forma estratégica e criar uma defesa em camadas eficaz para sua empresa, ministério ou agência.