Este é o terceiro relatório trimestral público da Varredura. Nele, consolidamos os achados de 500 aplicações web brasileiras auditadas entre 1 de junho e 31 de agosto de 2026, todas com pelo menos uma varredura completa em produção ou staging. Nenhuma organização é nomeada. Os dados foram agregados e anonimizados antes da análise.

Achados agregados

• 87% das aplicações apresentaram ao menos uma vulnerabilidade classificada como Alta ou Crítica.
• 62% apresentaram três ou mais vulnerabilidades distintas.
• 41% apresentaram algum vetor de SQL Injection (parametrização ausente, ORM em raw query, filtros por concatenação).
• 34% apresentaram alguma variante de SSRF explorável — número que sobe conforme a aplicação usa mais integrações externas. Ver anatomia de uma SSRF.
• 28% tinham JWT com segredo hardcoded, algoritmo none aceito, ou ausência de validação de expiração.
• 19% expunham .env ou .git acessível via HTTP.
• 14% tinham bucket S3 público listável.
• 11% aceitavam upload de arquivo sem validação de tipo, com path traversal.

Comparado ao Q2 2026, SSRF subiu 6 pontos percentuais. Atribuímos isso à explosão de integrações com APIs externas e a padrões introduzidos por código gerado por IA — o que confirma o observado em 12 vulnerabilidades de vibe coding.

Distribuição por stack

Coletamos stack a partir dos headers, fingerprint de framework e comportamentos observáveis. Auto-declaração do cliente foi usada apenas como desempate.

| Stack backend | % da base | % com falha Alta/Crítica | |---|---|---| | Node.js (Express/Fastify/Nest) | 34% | 89% | | Python (Django/Flask/FastAPI) | 22% | 82% | | PHP (Laravel/Symfony/legacy) | 16% | 91% | | Java (Spring Boot) | 11% | 78% | | Ruby (Rails) | 6% | 84% | | Go | 5% | 71% | | .NET | 4% | 79% | | Outros | 2% | 88% |

Frontend:

| Stack | % da base | |---|---| | React (CRA/Next.js/Vite) | 61% | | Vue (Vite/Nuxt) | 14% | | Server-rendered puro (Blade/ERB/etc) | 12% | | Angular | 6% | | Svelte / SolidJS | 4% | | HTMX / Hotwire | 3% |

Observação: Go tem a menor taxa de falhas críticas. Correlação com maturidade da base (idade média de app Go é maior) e comunidade menor mais experiente. Não recomendamos escolher stack por segurança — recomendamos escolher stack e depois testá-lo.

Distribuição por indústria vertical

| Vertical | % da base | Falhas críticas médias por app | |---|---|---| | Fintech e pagamentos | 21% | 4.2 | | E-commerce e marketplaces | 18% | 3.8 | | Saúde e healthtech | 12% | 5.1 | | Educação e edtech | 11% | 3.4 | | Logística | 9% | 3.9 | | Real estate | 7% | 4.7 | | RH e recruiting | 7% | 3.6 | | Agtech | 5% | 4.3 | | Governo e serviços públicos | 5% | 5.8 | | Outros | 5% | 3.5 |

Saúde e governo lideram em falhas críticas por aplicação. Ambos concentram dado sensível (art. 5º LGPD) e ambos têm ciclos de patch mais lentos que a média — governo por licitação, saúde por dependência de sistemas legados integrados a HL7/TISS.

Distribuição por idade da aplicação

| Idade da codebase | % da base | % com pelo menos uma falha crítica | |---|---|---| | < 6 meses | 12% | 93% | | 6 – 18 meses | 21% | 88% | | 18 meses – 3 anos | 27% | 84% | | 3 – 5 anos | 22% | 87% | | 5 – 10 anos | 13% | 91% | | > 10 anos | 5% | 96% |

Contra-intuitivo: aplicações com menos de 6 meses lideram em falhas críticas. Nossa hipótese é dupla: (1) pressão de time-to-market suprime revisão de segurança, (2) uso intensivo de código gerado por IA em fase inicial. Aplicações mais velhas caem para um ponto, depois voltam a subir por dívida acumulada e dependências desatualizadas.

Top 15 categorias por frequência

| # | Categoria | % dos apps | |---|---|---| | 1 | Header de segurança ausente (HSTS, CSP, X-Frame) | 71% | | 2 | Cookies sem HttpOnly ou Secure | 58% | | 3 | Dependência com CVE conhecida | 54% | | 4 | Rate limit ausente em endpoints sensíveis | 47% | | 5 | Verbose errors (stack trace em produção) | 46% | | 6 | CORS mal configurado (* com credenciais) | 44% | | 7 | SQL Injection (qualquer variante) | 41% | | 8 | Enumeração de usuário no login | 39% | | 9 | SSRF explorável | 34% | | 10 | Falta de MFA no admin | 32% | | 11 | JWT com problema | 28% | | 12 | Upload de arquivo sem validação | 26% | | 13 | XSS refletido | 24% | | 14 | IDOR (Insecure Direct Object Reference) | 22% | | 15 | Diretório listável / arquivo .env público | 19% |

Categorias mais corrigidas primeiro

Analisando as varreduras de re-teste após 30 dias:

| Categoria | Taxa de correção em 30 dias | |---|---| | .env público | 96% | | S3 bucket público | 91% | | Verbose errors | 87% | | JWT hardcoded | 82% | | Dependências CVE | 74% | | Headers de segurança | 63% | | SSRF | 41% | | IDOR | 38% | | SQL Injection | 34% | | Rate limit | 22% |

O que fica sem correção não é o mais difícil tecnicamente — é o que exige refatoração de fluxo. IDOR e rate limit dependem de mudança arquitetural; .env e verbose errors resolvem em uma linha de config.

Tempo médio de detecção → correção → varredura de confirmação

• Detecção → primeiro commit de correção: 4.2 dias (mediana).
• Commit → deploy em produção: 1.8 dias.
• Deploy → re-varredura confirmando fix: 9.7 dias.

Ou seja, uma vulnerabilidade típica fica 15.7 dias com risco residual antes de fechar o ciclo. Isso é aceitável para severidade média, insuficiente para crítica.

Conclusões

• Segurança contínua ganhou tração: 67% dos apps auditados no Q3 estavam sob monitoramento recorrente, contra 52% no Q1.
• AI-generated code amplifica o problema: aplicações que declararam uso intensivo de Copilot/Cursor tinham 1.4x mais falhas críticas médias.
• Falhas de configuração ainda dominam: 5 das top 10 são configuração, não código. Baixo custo de correção, alto retorno.

Metodologia completa, universo amostral e política de anonimização estão disponíveis mediante solicitação para pesquisadores acadêmicos.

A Varredura roda no seu app hoje e devolve um relatório equivalente ao deste estudo, em 24 horas, sem tocar em código-fonte. Rode agora.