Por que ferramentas de IA deixam lacunas de segurança

Por que o código AI-gerado difere em segurança

AI as ferramentas de codificação têm razões estruturais para as lacunas de segurança que produzem. Não são descuidos aleatórios; eles são artefatos previsíveis de treinamento e otimização.

• Training data skews toward "make it work." Repositórios e tutoriais de código aberto dominam o treinamento LLM. O repositório mediano OSS foi escrito para resolver um problema, não para ser um exemplo de reforço de segurança. Um LLM aprende a distribuição de código em estado selvagem, não a distribuição de código seguro.
• Autocomplete is sticky. Quando você cola um trecho de código que usa uma chave service_role, ele se torna o modelo para o próximo arquivo. O preenchimento automático de Cursor irá sugeri-lo em um componente cliente ao qual nunca pertenceu. A ferramenta está fazendo o que foi otimizada (velocidade) — mas não está ciente do limite de segurança.
• No long-term context or incident memory. Um desenvolvedor humano que queimou um banco de dados de produção com uma cláusula WHERE ausente leva essa lição adiante por anos. Um LLM não tem memória episódica. Cada arquivo é um novo começo. A ferramenta não aprende com seu último desvio RLS ou com a postmortem do incidente de sua equipe.
• Speed is the rewarded metric. Os desenvolvedores escolhem essas ferramentas porque elas são entregues rapidamente. O feedback de latência é imediato e direto. O feedback de segurança está ausente ou atrasado — uma vulnerabilidade encontrada em uma varredura FixVibe três semanas após o envio. O LLM foi otimizado para a métrica de humanos recompensados ​​em tempo real.
• Implicit trust in platform defaults. Quando Cursor gera um aplicativo Vercel, ele assume que os padrões de Vercel são reforçados. Alguns são: auto-HTTPS, cookies assinados, proteção DDoS. Outros não são: não CSP por padrão, não HSTS, permissivo CORS. O código gerado herda pressupostos da plataforma que nem sempre são justificados.

Lacuna 1: segredos em pacotes de clientes

Chaves API de função de serviço, tokens OAuth e chaves privadas terminam em pacotes JavaScript enviados ao navegador. FixVibe sinaliza isso como resultados secrets.browser-storage e secrets.bundle-leak. As chaves podem ser descobertas em mapas de origem, código reduzido ou texto simples JS.

Why it happens: Cursor colar um trecho Supabase que inicializa um cliente com a função de serviço significa que o código agora está no preenchimento automático. Um componente React gerado pede "obter todos os itens do banco de dados" e Cursor sugere a importação do cliente-serviço. A fronteira entre o código somente do servidor e do lado do cliente é abstrata para LLM.

Fix: Armazene segredos em variáveis de ambiente sinalizadas NEXT_PUBLIC_ apenas para chaves públicas. Chaves de serviço, chaves privadas API e segredos de assinatura devem residir em src/lib/secrets.ts com import 'server-only'. Use ações de servidor ou rotas API para chamar serviços confidenciais, nunca componentes de cliente.

Lacuna 2: Segurança em nível de linha ausente ou incompleta

Supabase tabelas são criadas sem RLS habilitado. Firebase As regras do Firestore nunca são escritas ou são deixadas no modo de teste permissivo. Os usuários Anon podem ler e escrever todas as linhas. FixVibe sinaliza isso como baas.supabase-rls e baas.firebase-rules.

Why it happens: RLS é um recurso específico do Postgres. LLMs treinados em Rails, Django, Laravel e Express consideram as verificações de autenticação da camada de aplicação como norma. Habilitar RLS em Supabase requer instruções ALTER TABLE explícitas e definições de políticas – padrões menos comuns em dados de treinamento.

Fix: Para Supabase, aplique RLS com ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY; em todas as tabelas. Políticas de criação que abrangem linhas para o usuário ou organização autenticado. Para Firebase, nunca deixe as regras como modo de teste padrão; escreva regras explícitas com escopo para o usuário autenticado.

Lacuna 3: confusão de limites de autenticação

As sessões são validadas no lado do cliente usando getSession() (que lê um cookie não verificado). Links mágicos não têm validade. JWTs pula as verificações aud e exp. As redefinições de senha são reversíveis. FixVibe sinaliza isso como active.auth-flow descobertas.

Why it happens: Supabase Auth, Clerk e serviços semelhantes lidam com o estado da sessão, mas seus APIs têm modos seguros e inseguros. getSession() é conveniente, mas não verificado. O LLM vê a conveniência API com mais frequência do que a segurança nos dados de treinamento. A validação do token do lado do servidor é abstrata e requer cabeçalhos HTTP explícitos ou invocação de middleware.

Fix: Sempre use supabase.auth.getUser() no lado do servidor. Nunca confie em getSession() em rotas protegidas. Valide JWTs em cada solicitação, verificando exp, aud e assinatura. Defina a expiração do token como 1 hora para tokens de acesso e use tokens de atualização para sessões mais longas.

Lacuna 4: cabeçalhos de segurança HTTP ausentes

Não Content-Security-Policy, não X-Frame-Options, não Strict-Transport-Security, não X-Content-Type-Options. FixVibe sinaliza isso como headers.security-headers descobertas.

Why it happens: Os cabeçalhos de segurança são específicos da plataforma de implantação. Cursor gera código para Next.js; definir CSP requer um ajuste next.config.js, um middleware ou uma substituição vercel.json. Eles não estão nos andaimes padrão do projeto. O modelo mental de “cabeçalhos são para DevOps” ainda é comum.

Fix: Defina CSP em next.config.js ou middleware com suporte nonce: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; .... Adicione HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains. Use vercel.json cabeçalhos ou middleware de Vercel para hosts estáticos.

Lacuna 5: Configurações incorretas de integração de terceiros

Chaves Stripe, tokens Sentry, chaves antrópicas API são codificadas ou comprometidas com repositórios. As origens do Analytics são excessivamente permissivas. As dependências do npm estão desatualizadas. As varreduras FixVibe sinalizam isso como descobertas em discovery.tech-fingerprint e em nossos verificadores de segredos.

Why it happens: As integrações são coladas de documentação e tutoriais. O LLM copia o padrão, incluindo quaisquer valores codificados. A disciplina Env-var requer disciplina explícita em CI/CD - que LLM não pode impor.

Fix: Use variáveis ​​de ambiente para cada credencial de terceiros. Armazene segredos em sua plataforma de implantação (Vercel, Netlify, Heroku ou um cofre). Audite as dependências do npm com npm audit mensalmente. Use Dependabot ou Renovate para PRs automatizados quando atualizações de segurança estiverem disponíveis.

O padrão de remediação

Fechar essas lacunas não requer reconstrução do zero. O padrão é consistente:

1. Audit: Execute FixVibe em seu aplicativo ativo. Para varreduras de repositório, habilite o aplicativo FixVibe GitHub. Colete as descobertas – segredos, RLS, autenticação, cabeçalhos, terceiros.
2. Reforçar: Corrija os achados de alta confiança. Ative RLS + FORCE. Mova os segredos para variáveis de ambiente. Defina CSP e HSTS no middleware. Use validação de auth no servidor. Use o prompt do agente de código apenas onde se aplicam mudanças de código/configuração, e siga os passos do operador para correções de DNS ou gerenciadas pelo provedor.
3. Monitor: Agende verificações passivas diárias ou verificações ativas semanais em um domínio verificado. Configure webhooks no Slack. Cada descoberta crítica deve acionar um alerta minutos após o envio.
4. Responder: Quando um achado surgir, copie a ação de remediação da FixVibe que corresponde ao responsável pela correção: um prompt do agente de código para trabalho de código/configuração, ou passos do operador para DNS, console do provedor, rotação de segredos e revisão manual. Rode novamente a varredura para confirmar.

Para onde o campo está indo

Corrigir essas lacunas é trabalho para as equipes hoje. Nos próximos 2 a 3 anos, a fronteira está se movendo: melhores padrões em estruturas e ferramentas (Next.js middleware auto-CSP, Supabase RLS como padrão), IDE-time feedback de segurança (Cursor sugestões que avisam quando você está prestes a colar uma chave de serviço em um componente do cliente) e MCP-drive autofix (seu agente de codificação tem acesso a FixVibe descobertas e pode corrigi-las de forma autônoma). FixVibe público changelog rastreia quais lacunas estão sendo fechadas primeiro.

Próximas etapas

Para a lista de verificação go/no-go antes do lançamento, consulte Pre-launch SaaS security checklist. Para obter um passo a passo de proteção com trechos de código e padrões de falha reais, leia How to secure an app built with AI coding tools.