Um scanner gratuito que verifica o certificado SSL e os cabeçalhos HTTP dá uma falsa impressão de cobertura. O OWASP Top 10:2025 coloca a Configuração de Segurança em segundo lugar e introduz Falhas na Cadeia de Suprimentos de Software como uma categoria à parte. Testar a segurança de um site na internet pressupõe entender o que essas ferramentas realmente capturam e, principalmente, o que elas ignoram.
Cadeia de Suprimentos e condições excepcionais: os pontos cegos dos scanners gratuitos
A maioria das ferramentas acessíveis sem registro analisa a superfície exposta: validade do certificado TLS, presença dos cabeçalhos Content-Security-Policy, X-Frame-Options, configuração DNS. É uma base útil, mas que não cobre nem a cadeia de dependências de software nem a gestão de erros aplicacionais.
O OWASP Top 10:2025 formalizou esses dois riscos sob as categorias Falhas na Cadeia de Suprimentos de Software e Manejo Incorreto de Condições Excepcionais. Um componente JavaScript importado via npm, uma imagem Docker construída sobre uma base não mantida, um pipeline CI/CD cujos segredos estão expostos: nenhum scan externo anônimo detecta esses defeitos.
Recomendamos tratar o scan online como um primeiro filtro, não como uma auditoria. Ele identifica erros de configuração visíveis a partir do exterior. Para a cadeia de software, é necessário uma ferramenta do tipo Análise de Composição de Software (Snyk Open Source, OWASP Dependency-Check) executada no repositório de código.
Antes de iniciar um scan, é útil testar a segurança de um site na internet compreendendo precisamente o escopo coberto por cada ferramenta, a fim de evitar confundir um relatório limpo com uma superfície de ataque realmente reduzida.
Configuração de Segurança: o que os scans de cabeçalhos HTTP realmente detectam
A ascensão da Configuração de Segurança ao segundo lugar no ranking OWASP não é anedótica. Ela reflete a multiplicação das superfícies de configuração: buckets de nuvem públicos, endpoints de administração acessíveis, páginas de erro verbosas que expõem rastros de pilha, cookies sem atributo Secure ou SameSite.
Os scanners gratuitos cobrem uma parte desse escopo. Eles verificam tipicamente:
- A presença e o valor dos cabeçalhos de segurança HTTP (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- A configuração TLS (versão do protocolo, suites de criptografia, expiração do certificado)
- A exposição de informações do servidor nos cabeçalhos de resposta (Server, X-Powered-By)
- A política CORS e as origens permitidas
Por outro lado, um scan externo não testa as configurações internas: regras IAM de um bucket S3, acesso a um console de administração protegido por uma URL obscura, ou variáveis de ambiente injetadas em texto claro no código-fonte do lado do cliente. Essas verificações exigem acesso autenticado ou uma auditoria do código implantado.
Interpretar uma pontuação de segurança sem superavaliá-la
Um relatório exibindo uma pontuação alta (A ou A+) nos cabeçalhos HTTP não significa que a aplicação é segura. Isso significa que a camada de transporte e as diretrizes do navegador estão corretamente configuradas. Observamos regularmente sites classificados como A+ cujo painel de administração é acessível via /admin sem restrição de IP ou autenticação em duas etapas.
A pontuação é um indicador de maturidade em um escopo específico. Ela não cobre nem a lógica de negócios nem os controles de acesso aplicacionais.
Controle de Acesso Quebrado e testes autenticados: o limite estrutural do scan anônimo
O risco classificado como número um pelo OWASP em 2025 continua sendo o Controle de Acesso Quebrado, que agora inclui o SSRF (Server-Side Request Forgery). Esse tipo de vulnerabilidade requer contas de teste com vários níveis de privilégios e cenários de negócios concretos: um usuário padrão que tenta acessar um recurso reservado para um administrador, uma requisição API que modifica o identificador de um objeto para acessar os dados de outro usuário (IDOR).
Nenhum scanner externo anônimo pode validar os controles de acesso sem ter pelo menos duas sessões autenticadas com papéis diferentes. Uma ferramenta como o OWASP ZAP permite configurar contextos de autenticação e reproduzir cenários, mas isso vai além do escopo de um simples teste online.
Abordagem combinada para uma auditoria realista sem orçamento
Para cobrir um escopo aceitável sem investimento financeiro, recomendamos combinar três camadas:
- Um scan de cabeçalhos e configuração TLS via uma ferramenta online gratuita (Mozilla Observatory, SecurityHeaders.com) para o escopo de rede e transporte
- Um proxy de interceptação local (OWASP ZAP em modo padrão) para testar manualmente os controles de acesso e as injeções em formulários, com sessões autenticadas
- Uma análise de dependências (npm audit, pip-audit, OWASP Dependency-Check) diretamente no pipeline de build para cobrir a cadeia de software
Essa combinação cobre três dos cinco principais riscos do ranking OWASP 2025. Ela não substitui um pentest profissional, mas eleva significativamente o nível de detecção em relação a um scan único de cabeçalhos HTTP.
CORS, cookies e Content-Security-Policy: as configurações a verificar prioritariamente
Entre os elementos testáveis gratuitamente, três configurações concentram uma parte desproporcional dos erros exploráveis.
A política CORS mal configurada continua sendo frequente. Um Access-Control-Allow-Origin posicionado em * com Access-Control-Allow-Credentials como true expõe os cookies de sessão a qualquer domínio de terceiros. Os scanners gratuitos sinalizam essa combinação, mas não testam as consequências aplicacionais.
Os atributos de cookies merecem atenção especial. Um cookie de sessão sem Secure, sem HttpOnly e sem SameSite=Strict (ou Lax) é vulnerável ao roubo via XSS ou à inclusão em requisições cross-site. Os navegadores recentes atenuam alguns cenários, mas a configuração explícita continua sendo a única proteção confiável do lado do servidor.
Por fim, uma Content-Security-Policy permissiva anula a proteção contra injeções XSS. Uma diretiva script-src contendo ‘unsafe-inline’ ou ‘unsafe-eval’ torna a CSP cosmética. As ferramentas de scan online detectam essas diretivas, o que as torna um dos poucos controles aplicacionais acessíveis sem autenticação.
A gratuidade de uma ferramenta de teste não é um problema em si. O que cria uma falsa sensação de segurança é tratar o relatório como exaustivo, enquanto ele cobre apenas uma fração da superfície de ataque real. Um scan limpo nos cabeçalhos HTTP continua sendo um bom ponto de partida, desde que se siga com as camadas que a ferramenta não pode alcançar.
