Por que API Security difere de Web Application Security?

Se você já conhecia a OWASP Top 10, mas não sabia que havia uma lista específica da entidade para APIs, provavelmente você deve ter estranhado. Porém, quando você pensa em termos de arquitetura da aplicação, faz todo o sentido haver uma lista dedicada para enfrentar problemas específicos de API.

A OWASP Top 10 para aplicações web surgiu em uma época em que a maioria das aplicações seguia uma arquitetura em que o front-end era renderizado no servidor. Sendo assim, as regras de negócio eram todas processadas no servidor, que entregava os arquivos HTML já com os dados incorporados. Isso limitava muito a superfície de ataque, sendo necessário um pouco de engenhosidade para conseguir manipular dados, por isso a prevalência de SQL Injection e XSS.

Nessa mesma época, as aplicações eram majoritariamente monolíticas, sendo executadas em um grande bloco de código homogêneo, dentro de máquinas em um datacenter ou em VMs em cloud. Os pontos de entrada na aplicação eram poucos, sendo mais simples de controlar. Era simples passar todo o tráfego pelo mesmo nó de uma ferramenta de WAF e normalmente, autenticação e autorização eram realizadas em um ponto único na entrada da aplicação. Problemas de autenticação e autorização já se faziam presentes, mas não com a mesma força de injections.

O que muda com as APIs? Dada a função delas, os dados são expostos de forma bem mais direta do que em uma página renderizada no servidor. Uma simples falha de quem programa já é suficiente para expor informações sensíveis sem muito trabalho de quem está explorando. Talvez você esteja se perguntando por que isso é um problema, dado que o que é mais simples também é mais fácil de revisar a qualidade. O grande problema é que a evolução das APIs vem acompanhada com o crescimento da complexidade.

As APIs diminuem o acoplamento das funções de uma aplicação, permitindo uma distribuição mais eficiente do trabalho de desenvolvimento, o que acelera a entrega de novos produtos a um nível que antes era inviável. Como consequência, geramos uma malha cada vez mais complexa de comunicação entre back-end e front-end e dentro do próprio back-end.

O tráfego externo que antes era forçado para entrar em apenas um nó, hoje pode ter à disposição inúmeros pontos de entradas (às vezes desconhecidos). O controle e conhecimento pleno da arquitetura que uma equipe de segurança, se perdeu como consequência da velocidade com que novos produtos são lançados. As assinaturas de padrões de ataque, normalmente associados às linguagens e frameworks específicos utilizados em um monolito, perderam eficiência em um ambiente que pode envolver a comunicação de microsserviços construídos em diferentes linguagens.

Como exemplo das consequências deste fenômeno, vemos que a OWASP Top 10 para APIs tem uma presença muito forte de falhas de autenticação e autorização quando comparada com a OWASP Top 10 para aplicações web de 2017. Provavelmente, a ascensão da Quebra de Controle de Acesso à primeira posição na lista para aplicações web divulgada em 2021 tenha relação com a importância das APIs nas aplicações web hoje. O processo de autenticação e autorização em aplicações distribuídas (que muitas vezes estão por trás de APIs) pode ser extremamente desafiador em relação ao mesmo processo em um monolito.

Isso não significa que ferramentas de Web Application Security não funcionam mais. WAF (Web Application Firewall), SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) entre outras soluções para segurança de aplicações web continuam a ter o seu papel, uma vez que os problemas solucionados por elas continuam existindo, principalmente no contexto individual de cada microsserviço. O que muda é que com a complexidade trazida pelas arquiteturas de aplicação viabilizadas pelas APIs, novos comportamentos emergem, sendo necessárias novas abordagens para mitigar os riscos.

Quer aprender mais sobre API Security? Baixe nosso Ebook Grátis!