Como Proteger Código Gerado por IA — Lista de Verificação de Segurança Vibe Coding

Se você codificou um app com vibes com Claude ou Cursor e está prestes a entregar para um cliente que paga, pare. Código gerado por IA vem com buracos de segurança previsíveis — chaves de API expostas, validação de entrada faltando, permissões padrão de banco de dados que deixam qualquer usuário ver os dados de todos os outros. Esses não são casos extremos. Acontecem em quase todo primeiro rascunho de codebase gerado por IA.

Este guia é a lista de verificação de segurança pré-lançamento. Siga passo a passo antes de qualquer usuário real tocar seu app. Foi escrito para a stack de vibe coding mais comum (Next.js + Supabase + Vercel), mas os princípios se aplicam independente de suas ferramentas.

Por que Código Gerado por IA Tem Problemas de Segurança

Modelos de IA otimizam para "funciona?" e não "é seguro?" Quando você diz ao Claude "construa um gerenciador de tarefas com contas de usuário", ele vai gerar código que cria usuários, armazena tarefas e as exibe. O que provavelmente não vai fazer automaticamente: garantir que o Usuário A não consiga ver as tarefas do Usuário B, validar que campos de entrada não possam aceitar scripts maliciosos, esconder suas chaves de API das ferramentas de desenvolvedor do navegador, ou adicionar limite de taxa para evitar que alguém marque seus endpoints.

Essas não são falhas da IA — são lacunas no prompt. A IA constrói o que você pediu. Você provavelmente não pediu segurança porque estava focado em recursos. Agora é hora de voltar e adicionar isso.

Passo 1: Audite Suas Variáveis de Ambiente

Este é o erro mais comum e mais perigoso em apps vibe-coded. Verifique cada arquivo do seu projeto para chaves de API codificadas, URLs de banco de dados ou segredos.

O que procurar: Procure em sua codebase por strings que começam com sk-, eyJ, sbp_, supabase, postgres://, ou qualquer string longa com aparência aleatória. Verifique estes arquivos especificamente: qualquer arquivo no seu diretório /app ou /pages, qualquer arquivo de componente, seu next.config.js, e qualquer arquivo utilitário.

A correção: Mova cada segredo para variáveis de ambiente. No Next.js, apenas variáveis prefixadas com NEXT_PUBLIC_ são expostas ao navegador. Sua URL de banco de dados, chave de função de serviço e segredos de API nunca devem ter esse prefixo.

# .env.local (NUNCA commit este arquivo)
SUPABASE_SERVICE_ROLE_KEY=sua-chave-secreta
DATABASE_URL=postgres://...

# Estes são seguros para expor ao navegador:
NEXT_PUBLIC_SUPABASE_URL=https://seu-projeto.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=sua-chave-anon

Verifique: Confirme que seu arquivo .gitignore inclui .env.local. Se você já fez commit de segredos no Git, eles estão no seu histórico mesmo após exclusão — regenere (rotate) cada chave exposta imediatamente.

Passo 2: Ative Row-Level Security no Supabase

Este é o passo único mais crítico se você está usando Supabase. Por padrão, tabelas Supabase não têm restrições de acesso — qualquer pessoa com sua chave anon pode ler e escrever cada linha em cada tabela. Isso significa que o Usuário A pode ver os dados do Usuário B com uma simples chamada de API.

A correção: Ative Row-Level Security (RLS) em cada tabela, depois crie políticas que restrinjam o acesso.

Vá para seu dashboard Supabase → Table Editor → selecione cada tabela → clique em "RLS Disabled" para ativar. Depois adicione políticas:

Para um app típico onde usuários devem ver apenas seus próprios dados, crie uma política SELECT: auth.uid() = user_id. Crie políticas similares para INSERT, UPDATE e DELETE.

Teste isso: Faça login como Usuário A, tente acessar os dados do Usuário B através da API. Se você conseguir vê-los, suas políticas estão erradas. Supabase tem um editor SQL onde você pode testar políticas diretamente.

Erro comum de IA: Claude frequentemente gera queries Supabase usando a chave service_role (que bypassa RLS) em vez da chave anon com políticas RLS apropriadas. Verifique que seu código client-side usa apenas a chave anon. A chave service role deve existir apenas em código server-side (rotas de API, server actions) e nunca ser exposta ao navegador.

Passo 3: Adicione Autenticação Corretamente

Código de autenticação gerado por IA frequentemente funciona mas toma atalhos. Verifique estes problemas específicos:

Gerenciamento de sessão: Certifique-se de que as sessões expirem. Verifique que sua configuração de autenticação inclui um timeout de sessão razoável (os padrões Supabase são geralmente bons, mas verifique). Garanta que fazer logout realmente invalida a sessão, não apenas limpa o cookie local.

Requisitos de senha: Se você tem autenticação por email/senha, enforça comprimento mínimo de senha (8+ caracteres). Supabase controla isso nas suas configurações de projeto → Authentication → Password Requirements.

Rotas protegidas: Cada página que mostra dados específicos do usuário precisa de middleware de autenticação. No Next.js App Router, crie um middleware que verifica uma sessão válida e redireciona usuários não autenticados para a página de login. Não confie apenas em verificações client-side — um usuário pode contorná-las acessando sua API diretamente.

Verificação de email: Ative confirmação de email nas configurações de Supabase Auth. Isso previne que pessoas criem contas com endereços de email falsos e adiciona uma camada básica de validade de conta.

Passo 4: Valide Todas as Entradas

Formulários gerados por IA geralmente têm validação básica (campos obrigatórios, formato de email) mas raramente protegem contra entrada maliciosa.

O que adicionar:

Validação server-side em cada endpoint de API. Nunca confie apenas em validação client-side — ela pode ser contornada enviando requisições diretamente para sua API. Use uma biblioteca de validação como Zod (para TypeScript) para definir schemas para cada peça de dado que seu app aceita.

Sanitize HTML em qualquer conteúdo gerado por usuário que é exibido. Se seu app tem comentários, descrições, ou qualquer campo de texto que renderiza no navegador, use uma biblioteca como DOMPurify para remover scripts perigosos. Sem isso, alguém pode injetar JavaScript que rouba as sessões de outros usuários (cross-site scripting / XSS).

Limite tamanho e tipos de arquivo se seu app aceita uploads de arquivo. Manipuladores de upload gerados por IA frequentemente não têm limites, significando que alguém poderia fazer upload de um arquivo de 2GB ou um executável. Adicione limites de tamanho (5MB é razoável para a maioria dos apps) e restrinja tipos de arquivo para o que você realmente precisa (imagens, PDFs, etc.).

Passo 5: Proteja Suas Rotas de API

Verifique cada rota de API ou server action no seu app para estes problemas:

Autenticação em cada endpoint. Cada rota de API que retorna ou modifica dados do usuário deve verificar primeiro a sessão do usuário. IA frequentemente gera rotas de API que aceitam requisições de qualquer pessoa.

Autorização além de autenticação. Mesmo depois de confirmar que um usuário está logado, verifique que eles estão permitidos acessar o recurso específico que estão solicitando. "Usuário A está logado" não significa "Usuário A pode editar o perfil do Usuário B." Verifique propriedade em cada acesso de dados.

Limite de taxa. Sem limite de taxa, alguém pode enviar milhares de requisições por segundo para sua API, seja para raspar dados ou para sobrecarregar seu servidor. Adicione limite de taxa básico usando uma biblioteca como rate-limiter-flexible ou use o limite de taxa embutido do Vercel em Edge Functions.

Métodos HTTP. Certifique-se de que suas rotas de API respondem apenas aos métodos HTTP que deveriam. Uma rota que manipula requisições POST não deveria também responder a requisições DELETE a menos que você tenha explicitamente desenhado isso.

Passo 6: Verifique Sua Configuração de Deployment

Sua plataforma de deployment tem configurações de segurança que IA não configura para você.

Configurações Vercel para verificar: Ative "Deployment Protection" (requer autenticação para ver deployments de preview — previne clientes de compartilhar acidentalmente URLs de preview que expõem trabalho em progresso). Configure limites de gasto para prevenir cobranças inesperadas se seu app receber picos de tráfego. Configure seus domínios permitidos em headers CORS.

Domínio customizado e SSL: Se você está entregando isso para um cliente, configure seu domínio customizado com HTTPS. Vercel e Netlify controlam SSL automaticamente. Nunca entregue um app de cliente em um subdomínio .vercel.app — parece não profissional e o cliente não pode transferi-lo facilmente.

Headers: Adicione headers de segurança ao seu next.config.js ou vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (previne seu site de ser embutido em iframes para clickjacking), Strict-Transport-Security (força HTTPS). Estas são adições uma vez que previnem classes inteiras de ataques.

Passo 7: Execute uma Verificação de Segurança Final

Antes de entregar qualquer coisa a um cliente, execute estas verificações gratuitas:

npm audit: Execute npm audit no seu diretório de projeto. Ele marca vulnerabilidades conhecidas em suas dependências. Corrija problemas de severidade crítica e alta. Execute npm audit fix para correções automáticas quando disponível.

Lighthouse: Abra seu site deployado no Chrome, abra DevTools, execute uma auditoria Lighthouse. Verifique o score "Best Practices" — ele detecta problemas de segurança comuns como HTTPS faltando, bibliotecas vulneráveis e headers inseguros.

Teste manual: Faça login como um usuário, tente acessar os dados de outro usuário modificando URLs ou chamadas de API. Tente submeter formulários vazios, entradas oversized e caracteres especiais (como payloads XSS codificados). Se qualquer um desses funcionar, você tem problemas para corrigir.

A Lista de Verificação Pré-Lançamento

Imprima isso e verifique cada item antes de colocar em produção:

• Todos os segredos em variáveis de ambiente (sem chaves codificadas)
• .env.local no .gitignore (e sem segredos no histórico Git)
• Supabase RLS ativado em cada tabela
• Políticas RLS testadas (Usuário A não consegue ver dados do Usuário B)
• Código client-side usa apenas chave anon (chave service role apenas server-side)
• Autenticação em cada rota de API
• Verificações de autorização (verificação de propriedade) em acesso de dados
• Validação de entrada em cada formulário (server-side, não apenas client-side)
• Limites de upload de arquivo (tamanho e tipo) se aplicável
• Limite de taxa em endpoints de API
• Headers de segurança configurados
• npm audit executado e problemas críticos corrigidos
• Domínio customizado com SSL configurado
• Deployments de preview protegidos
• Teste de acesso de dados cross-user manual passou

A Conclusão

Proteger um app vibe-coded não é sobre se tornar um especialista em segurança. É sobre executar uma lista de verificação que detecta as lacunas previsíveis que IA deixa para trás. Os passos acima levam 2–4 horas e previnem as vulnerabilidades mais comuns. Para um app voltado para cliente, isso não é opcional — é a diferença entre trabalho profissional e uma responsabilidade.

Se você está construindo seu primeiro app vibe-coded, comece com nosso guia completo para vibe coding. Se você quer melhorar os prompts que você usa com Claude ou Cursor, experimente nosso otimizador de prompt gratuito. E para um breakdown das melhores ferramentas de coding, veja Claude Code vs Codex.

Divulgação: Alguns links neste artigo são links de afiliado. Recomendamos apenas ferramentas que testamos pessoalmente e usamos regularmente. Veja nossa política de divulgação completa.