Scan de segurança para código gerado por IA: DAST para apps vibe-coded

Por que o código gerado AI- precisa de uma verificação de segurança diferente

AI ferramentas de codificação são treinadas em repositórios de código aberto em grande escala. Esses dados de treinamento tendem para make it work em vez de make it secure. Alguns padrões estruturais decorrem disso:

• Autocomplete bias. A importação correspondente mais próxima vence. Colar um trecho Supabase que usa a chave service_role em um arquivo torna essa chave a sugestão de preenchimento automático no próximo - mesmo em componentes React do lado do cliente, aos quais ela nunca pertenceu.
• No long-term context. Um LLM não se lembra de seu último desvio RLS ou do incidente post-mortem de sua equipe. Cada arquivo gerado é novo, muitas vezes faltando padrões defensivos que os humanos carregariam nos arquivos.
• Speed as the rewarded metric. Os usuários elogiam a velocidade; O treinamento LLM reforça isso. "Gerar a autenticação Next.js mais rápida" é melhor do que "gerar a autenticação Next.js mais segura" em sinais de feedback de latência.
• Training data gaps. As bases de código mais antigas dominam os dados de treinamento e são anteriores aos padrões de segurança modernos (estritos CSP, SameSite=Lax, HSTS, RLS). O código gerado ecoa padrões que eram normais em 2019, mas inseguros hoje.
• Implicit platform trust. Quando Cursor gera um aplicativo Vercel, ele assume que os padrões de Vercel são seguros. Alguns são (auto-HTTPS, cookies assinados). Muitos não são (não CSP por padrão, permissivas CORS, rotas de depuração padrão Next.js).

Dez classes de vulnerabilidade super-representadas em aplicativos codificados por vibração

Em milhares de verificações de aplicativos gerados por AI-, as mesmas classes de descoberta aparecem desproporcionalmente:

1. Exposed Supabase service-role keys. Um service_role JWT (inicia eyJ) comprometido com um pacote de cliente ignora todas as políticas RLS do projeto. Cursor preenche automaticamente no lado errado do limite; a chave é enviada em /_next/static/....
2. Missing Row-Level Security (RLS). O modelo vê CREATE TABLE public.items e prossegue sem habilitar RLS. Usuários anônimos podem então ler ou escrever qualquer linha por meio da chave pública anônima. Veja baas.supabase-rls.
3. Open Firebase / Firestore rules. Os arquivos de regras gerados geralmente leem allow read, write: if true; ou ignoram completamente o arquivo de regras. As regras padrão do modo de teste expiram após 30 dias e bloqueiam o banco de dados, mas somente se o desenvolvedor perceber.
4. Hardcoded API keys in bundles. Stripe chaves ativas, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* e AWS AKIA* as chaves acabam incorporadas em JS cargas úteis quando a disciplina env-var caduca. secrets.browser-storage sinaliza-os no nível da página renderizada.
5. Missing Content Security Policy. Nenhum cabeçalho de resposta Content-Security-Policy significa que cada script embutido XSS está a um clique de distância do controle total da conta. CSP é abstrato; codegen rotineiramente o ignora. headers.security-headers relata a lacuna com as orientações de correção específicas da plataforma de implantação.
6. Next.js middleware misplacement. Com o layout src/, Next.js seleciona apenas src/middleware.ts — um middleware.ts de nível raiz é ignorado silenciosamente. Auth ainda parece funcionar porque as páginas chamam requireAuth(), mas os cabeçalhos, CSP e os limites de taxa não chegam.
7. IDOR via unsigned IDs. Os manipuladores GET /api/items/[id] gerados confiam no parâmetro de caminho e nunca verificam a propriedade. Percorrer o número inteiro ou o espaço UUID expõe os dados de cada locatário.
8. Broken auth flows. Tokens de link mágico sem expires_at; JWT verificação que ignora aud e exp; chamadas getSession() do lado do cliente (que leem um cookie não verificado) em vez de getUser() do lado do servidor.
9. Debug endpoints in production. Rotas /api/debug, /api/health, /api/__nextjs_original-stack-frame ou /.next/trace geradas vazam componentes internos. discovery.platform-vercel os investiga com validação de conteúdo para evitar falsos positivos em SPA substitutos.
10. Plaintext sensitive fields. Senhas, API chaves e PII armazenados como texto simples no Postgres porque a migração não alcançou pgcrypto ou um cofre externo.

DAST vs SAST: por que ambos são importantes para o código gerado por AI-

A análise estática (SAST) e a análise dinâmica (DAST) são complementos, não substitutos. A divisão é mais importante para AI-código gerado do que para código escrito à mão.

SAST lê o código-fonte no disco. Ele captura segredos em arquivos de origem, chamadas de funções perigosas e padrões arriscados antes da execução da compilação. Ele não pode ver a configuração do tempo de execução, as variáveis ​​de ambiente implementadas ou como um bundler transformou seu código.

DAST atinge o aplicativo implantado como um usuário. Ele vê as respostas enviadas, executa no pacote de produção e detecta desvios de configuração entre o repositório e a implantação. Ele encontra chaves codificadas em JavaScript transpilado que SAST nunca viu porque foram inseridas por meio de uma atribuição process.env no momento da construção.

For AI-generated code, DAST is essential porque o que é enviado difere do que o modelo escreveu. Agrupamento, agitação de árvores, transpilação e inlining de variável ambiental criam novas superfícies. SAST na fonte pode perder completamente os segredos incorporados ao pacote. DAST captura ambas as camadas. Um pipeline maduro é executado SAST em CI e DAST na visualização implantada — esse é o padrão FixVibe.

O que procurar em um scanner de código AI-

A maioria dos scanners DAST de uso geral (Burp Suite, OWASP ZAP, Nessus) foram projetados para aplicativos monolíticos e fluxos de autenticação tradicionais. A digitalização de um aplicativo Vercel + Supabase + Stripe AI- gerado precisa de:

• BaaS coverage. Verificações reais em Supabase RLS, Firebase / regras do Firestore, configuração do Clerk, AWS Amplify e as formas JWT emitidas por esses serviços. As regras OWASP genéricas não sabem o que sinalizar.
• JS bundle inspection. Regex ajustado para formatos API-key, tokens assinados e padrões específicos do provedor (Stripe sk_live_, Anthropic sk-ant-, Supabase JWTs começando com eyJ). A heurística genérica de entropia gera muitos falsos positivos.
• Passive + active split. Verificações passivas (cabeçalhos, cookies, segredos, BaaS configuração, DNS) são executadas com segurança em qualquer URL. Testes ativos (SQLi, XSS, SSTI, IDOR caminhada) exigem um limite de autorização porque disparam cargas úteis de estilo de ataque.
• Framework awareness. Reconhecendo Next.js App Router vs Pages Router, Vite SPA reescritas, Vercel proteção de implantação, Cloudflare roteamento de páginas. Um scanner que não distingue um substituto do Vite SPA de um /_next/build-manifest.json real gera ruído.
• Rate-limit safety. Orçamentos de solicitação limitados por varredura, comparação de linha de base-resposta para evitar WAF-falsos positivos confusos, linhas de base de investigação de caminho aleatória para detectar implantações cobertor-403.
• Authorization gating for intrusive payloads. Enviar cargas de comando SQLi ou OS- para um domínio que você não possui é ilegal na maioria das jurisdições. Um scanner real requer verificação de propriedade de arquivo DNS ou HTTP- antes de permitir que você execute o modo ativo em um alvo.

Abordagem de FixVibe: varredura baseada em evidências, baixa carga de falsos positivos

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe vs Burp Suite, ZAP e Nessus: quando cada ferramenta vence

Nenhuma ferramenta cobre todos os fluxos de trabalho. O enquadramento honesto de onde FixVibe se encaixa:

Onde as ferramentas se complementam

• Start with FixVibe passive como uma linha de base gratuita de 30 segundos em qualquer visualização de implantação. Se nada surgir, você terá um sinal de confiança rápido.
• Move to FixVibe active em um domínio verificado quando você deseja cobertura ativa total (SQLi/SSTI/IDOR/etc.) em sua própria infraestrutura.
• Layer SAST (Semgrep, CodeQL, Snyk) no código-fonte em CI. SAST captura o que o tempo de execução não consegue ver: padrões arriscados em caminhos de código que nunca chegam à implantação.
• Reach for Burp Suite quando você precisar de cadeias de ataque personalizadas (desvios de autenticação específicos, cenários IDOR intrincados, falhas de lógica de negócios). Burp é a bancada manual mais profunda disponível; FixVibe é a linha de base automatizada mais rápida.

Próximas etapas

Continue com Vibe coding security checklist para uma auditoria pré-envio de 44 itens ou vá para How to secure an app built with AI coding tools para proteção passo a passo com trechos de código.