Um cadeado verde na barra de endereços não garante muito. Qualquer site pode obter um certificado SSL gratuito, incluindo páginas de phishing. Verificar a segurança de um site exige ir além desse simples indicador visual, examinando camadas que nem o navegador nem o usuário médio conseguem ver.
Segurança de APIs: o ponto cego de uma auditoria de site web
Você acessa uma página web, vê texto, imagens, um formulário. Nos bastidores, essa página frequentemente consulta várias APIs para recuperar ou enviar dados. Essas interfaces programáticas tornaram-se um alvo prioritário para os atacantes.
Os relatórios de 2024 confirmam que os ataques direcionados às APIs representam uma parte crescente dos incidentes em aplicações web. O problema: a maioria das verificações clássicas se limita às páginas visíveis. Os endpoints de API, por sua vez, permanecem nas sombras.
Uma auditoria eficaz começa com um inventário completo desses endpoints. Alguns foram criados para uma necessidade pontual e depois esquecidos. Outros estão documentados de maneira incompleta. São precisamente esses que causam problemas, porque ninguém pensa em verificar sua autenticação ou suas permissões.
Concretamente, cada ponto de entrada de API deve ser testado individualmente. Verificamos se a autenticação funciona objeto por objeto (um usuário A não deve poder acessar os dados do usuário B), se limites de taxa estão em vigor e se as APIs depreciadas foram realmente removidas. Vários ferramentas permitem automatizar parte dessa verificação de segurança de sites web, mas a revisão manual continua sendo necessária para os controles de autorização.
Priorizar as falhas: por que a pontuação CVSS não é suficiente
Quando um scanner apresenta uma lista de vulnerabilidades, cada uma vem acompanhada de uma pontuação de gravidade (CVSS). A tentação é tratar primeiro as pontuações mais altas. Essa abordagem parece lógica, mas perde um dado crucial: os atacantes exploram principalmente falhas conhecidas e documentadas, não necessariamente as mais sofisticadas.
A CISA mantém um catálogo chamado Known Exploited Vulnerabilities (KEV). Ele lista as falhas ativamente exploradas na natureza. Uma vulnerabilidade com uma pontuação CVSS média, mas presente nesse catálogo, merece uma correção imediata. Por outro lado, uma falha teórica classificada muito alta, mas nunca explorada, pode esperar.
Para uma verificação realmente útil, cruze três critérios:
- A gravidade técnica dada pela pontuação CVSS, que mede o potencial de dano da falha.
- A presença no catálogo KEV da CISA, que indica se a falha está ativamente sendo explorada por atacantes.
- A exposição real do componente em questão: um serviço acessível pela internet é mais urgente do que uma ferramenta interna atrás de um VPN.
Cruzando gravidade técnica, exploração ativa e exposição real muda radicalmente a ordem de prioridade das correções. Sem essa triagem, uma empresa pode passar semanas em uma falha teórica enquanto uma brecha explorada permanece aberta.
Componentes open source e modelos de IA na análise de segurança
A maioria dos sites web modernos baseia-se em bibliotecas open source. Um CMS, um framework JavaScript, um módulo de pagamento: cada um incorpora código de terceiros com suas próprias vulnerabilidades potenciais.
Verificar esses componentes exige um inventário preciso, frequentemente chamado de Software Bill of Materials (SBOM). Este documento lista cada dependência, sua versão e seu estado de manutenção. Um componente abandonado por seus mantenedores é um risco silencioso: nenhuma atualização virá corrigir as falhas descobertas após o abandono.
As funcionalidades que integram inteligência artificial apresentam um problema adicional. Um modelo de IA exposto via uma API pode ser manipulado por requisições projetadas para extrair dados de treinamento ou contornar filtros. Esses vetores de ataque ainda são mal cobertos pelos scanners clássicos.
Verificar a configuração do servidor e os cabeçalhos HTTP
Antes mesmo de procurar falhas no código, a configuração do servidor frequentemente revela problemas simples de corrigir. Os cabeçalhos HTTP, por exemplo, controlam como o navegador interage com o site.
Um cabeçalho Content-Security-Policy bem configurado bloqueia a maioria dos ataques XSS. Por outro lado, alguns cabeçalhos que antes eram recomendados agora estão obsoletos. X-XSS-Protection, por exemplo, não é mais útil nos navegadores modernos, segundo a documentação MDN. Copiar e colar uma configuração encontrada em um fórum de 2018 pode dar uma falsa sensação de segurança.
Os pontos a verificar do lado do servidor:
- O protocolo HTTPS está ativo com um certificado válido, e os redirecionamentos HTTP para HTTPS funcionam sem loops.
- Os arquivos sensíveis (backups, arquivos de configuração, diretórios .git) não estão acessíveis publicamente.
- Os cabeçalhos de segurança estão atualizados e adaptados ao contexto do site, não simplesmente copiados de um modelo genérico.
- As mensagens de erro do servidor não divulgam informações técnicas (versões de software, caminhos de arquivos).
Verificação após correção: a etapa que a maioria das empresas pula
Detectar uma falha, corrigi-la, passar para a próxima. Esse ciclo parece completo, mas falta uma etapa formal: confirmar que a correção realmente funciona.
Os dados de 2024 mostram que vulnerabilidades conhecidas permanecem abertas por períodos prolongados, mesmo em empresas equipadas com scanners. O patch foi implantado em um ambiente de teste, mas não em produção. Ou a atualização foi aplicada, mas uma versão vulnerável do componente ainda está rodando em outro servidor.
A verificação após a correção deve incluir uma nova varredura focada na falha tratada, uma verificação manual para garantir que o patch não criou uma regressão (uma funcionalidade quebrada, um formulário que não valida mais as entradas) e um controle de que as versões vulneráveis foram removidas de todos os ambientes expostos.
Essa etapa transforma um relatório de auditoria em uma melhoria mensurável. Sem ela, o relatório permanece um documento PDF arquivado em uma pasta, e a falha continua explorável.
