A maioria das equipas de QA testa funcionalidade de APIs exaustivamente, mas trata a segurança como uma fase separada, manual e tardia — quando existe. O resultado é previsível: vulnerabilidades críticas só aparecem em auditorias pontuais, longe do ciclo de desenvolvimento onde seriam baratas de corrigir.

Esta apresentação mostra como integrar o OWASP API Security Top 10 no ciclo normal de testes, transformando riscos como Broken Object Level Authorization (BOLA), autenticação quebrada e exposição excessiva de dados em verificações automatizadas e repetíveis. Partindo de casos reais, percorremos os riscos mais críticos do Top 10 com exemplos concretos de exploração e, mais importante, de deteção. Demonstramos como ferramentas que o QA já domina — Postman e Frameworks de automação como Playwright — cobrem grande parte destes riscos sem exigir um perfil dedicado de segurança nem orçamento adicional.

O fio condutor é o mapeamento entre cada item do OWASP e o ponto exato do pipeline onde deve ser testado: o que valida o teste funcional, o que exige um teste de segurança específico, e o que pode (e deve) correr automaticamente em cada build. O objetivo é prático: dar a quem testa APIs um conjunto de técnicas aplicáveis na segunda-feira seguinte, mostrando que “security testing” não é um mundo à parte, mas uma extensão natural do trabalho de QA. Sai-se da sessão com um mapa claro e acionável, não com uma lista de ameaças abstratas.