Se você codificou um aplicativo com Claude ou Cursor e está prestes a entregá-lo a um cliente pagante, pare. Código gerado por IA vem com buracos de segurança previsíveis — chaves de API expostas, validação de entrada ausente, permissões de banco de dados padrão que permitem que qualquer usuário veja os dados de todos os outros. Estes não são casos extremos. Acontecem em quase todas as bases de código geradas por IA na primeira tentativa.
Este guia é o checklist de segurança pré-lançamento. Siga passo a passo antes de qualquer usuário real tocar seu aplicativo. Foi escrito para a pilha de codificação vibe mais comum (Next.js + Supabase + Vercel), mas os princípios se aplicam independentemente de suas ferramentas.
Por que Código Gerado por IA Tem Problemas de Segurança
Modelos de IA otimizam para "funciona?" não "é seguro?" Quando você diz ao Claude "construa-me um gerenciador de tarefas com contas de usuário," ele gerará código que cria usuários, armazena tarefas e as exibe. O que provavelmente não fará automaticamente: garantir que o Usuário A não possa ver as tarefas do Usuário B, validar que campos de entrada não possam aceitar scripts maliciosos, ocultar suas chaves de API das ferramentas do desenvolvedor do navegador, ou adicionar limite de taxa para evitar que alguém bombardeie seus endpoints.
Estes 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 adicioná-la.
Etapa 1: Audite Suas Variáveis de Ambiente
Este é o erro mais comum e mais perigoso em aplicativos codificados por vibe. Verifique cada arquivo em seu projeto para chaves de API codificadas, URLs de banco de dados ou segredos.
O que procurar: Procure em sua base de código por strings que começam com sk-, eyJ, sbp_, supabase, postgres://, ou qualquer string longa com aparência aleatória. Verifique especificamente estes arquivos: qualquer arquivo em seu diretório /app ou /pages, qualquer arquivo de componente, seu next.config.js, e qualquer arquivo de utilidade.
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 este prefixo.
# .env.local (NUNCA faça commit deste arquivo)
SUPABASE_SERVICE_ROLE_KEY=sua-chave-secreta
DATABASE_URL=postgres://...
# Estes são permitidos para expor ao navegador:
NEXT_PUBLIC_SUPABASE_URL=https://seu-projeto.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=sua-chave-anonVerifique: Verifique se seu arquivo .gitignore inclui .env.local. Se você já fez commit de segredos no Git, eles estão em seu histórico mesmo após exclusão — rotacione (regenere) cada chave exposta imediatamente.
Etapa 2: Ative Row-Level Security no Supabase
Este é o passo único mais crítico se você estiver usando Supabase. Por padrão, as 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 painel Supabase → Table Editor → selecione cada tabela → clique em "RLS Disabled" para habilitá-lo. Depois adicione políticas:
Para um aplicativo típico onde os 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: Faça login como Usuário A, tente acessar os dados do Usuário B através da API. Se 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 ignora RLS) em vez da chave anon com políticas RLS apropriadas. Verifique se seu código do lado do cliente usa apenas a chave anon. A chave de função de serviço deve existir apenas em código do lado do servidor (rotas de API, ações do servidor) e nunca ser exposta ao navegador.
Etapa 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 geralmente são bons, mas verifique). Garanta que fazer logout realmente invalida a sessão, não apenas limpa o cookie local.
Requisitos de senha: Se você tiver autenticação por email/senha, enforce comprimento mínimo de senha (8+ caracteres). Supabase lida com isso em suas configurações de projeto → Autenticação → Requisitos de Senha.
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 do lado do cliente — um usuário pode contornar essas ao acessar sua API diretamente.
Verificação de email: Ative confirmação de email nas configurações de Supabase Auth. Isso evita que pessoas criem contas com endereços de email falsos e adiciona uma camada básica de validade de conta.
Ganhando valor com isso? Publicamos um deep-dive por semana em ferramentas de IA, fluxos de trabalho e guias práticos. Junte-se aos leitores que recebem primeiro →
Etapa 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 entradas maliciosas.
O que adicionar:
Validação do lado do servidor em cada endpoint de API. Nunca confie apenas em validação do lado do cliente — pode ser contornada enviando solicitações diretamente para sua API. Use uma biblioteca de validação como Zod (para TypeScript) para definir esquemas para cada dado que seu aplicativo aceita.
Limpe HTML em qualquer conteúdo gerado pelo usuário que for exibido. Se seu aplicativo 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 sessões de outros usuários (cross-site scripting / XSS).
Limite o tamanho e tipos de arquivo se seu aplicativo 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 aplicativos) e restrinja tipos de arquivo para o que você realmente precisa (imagens, PDFs, etc.).
Etapa 5: Proteja Suas Rotas de API
Verifique cada rota de API ou ação do servidor em seu aplicativo para estes problemas:
Autenticação em cada endpoint. Cada rota de API que retorna ou modifica dados do usuário deve verificar a sessão do usuário primeiro. IA frequentemente gera rotas de API que aceitam solicitações de qualquer pessoa.
Autorização além de autenticação. Mesmo após confirmar que um usuário está conectado, verifique se ele tem permissão para acessar o recurso específico que está solicitando. "Usuário A está conectado" 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 solicitações por segundo para sua API, tanto para raspar dados quanto para sobrecarregar seu servidor. Adicione limite de taxa básico usando uma biblioteca como rate-limiter-flexible ou use o limite de taxa integrado do Vercel nas Edge Functions.
Métodos HTTP. Certifique-se de que suas rotas de API respondem apenas aos métodos HTTP que devem. Uma rota que manipula solicitações POST não deveria também responder a solicitações DELETE a menos que você tenha explicitamente projetado para isso.
Etapa 6: Verifique Sua Configuração de Implantação
Sua plataforma de implantação tem configurações de segurança que IA não configura para você.
Configurações Vercel a verificar: Ative "Deployment Protection" (requer autenticação para ver implantações de visualização — evita que clientes compartilhem acidentalmente URLs de visualização que exponham trabalho em progresso). Configure limites de gastos para evitar cobranças inesperadas se seu aplicativo receber picos de tráfego. Configure seus domínios permitidos em headers CORS.
Domínio personalizado e SSL: Se você está entregando isso a um cliente, configure seu domínio personalizado com HTTPS. Vercel e Netlify lidam com SSL automaticamente. Nunca entregue um aplicativo de cliente em um subdomínio .vercel.app — parece pouco 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 (evita que seu site seja incorporado em iframes para clickjacking), Strict-Transport-Security (força HTTPS). Estas são adições únicas que evitam classes inteiras de ataques.
Etapa 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 em 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 onde disponível.
Lighthouse: Abra seu site implantado no Chrome, abra DevTools, execute uma auditoria Lighthouse. Verifique a pontuação "Best Practices" — ela detecta problemas comuns de segurança como HTTPS ausente, 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 enviar formulários vazios, entradas muito grandes e caracteres especiais (como payloads XSS codificados). Se qualquer um desses funcionar, você tem problemas a corrigir.
O Checklist Pré-Lançamento
Imprima isto e verifique cada item antes de ir ao vivo:
- Todos os segredos em variáveis de ambiente (sem chaves codificadas)
.env.localem.gitignore(e sem segredos no histórico Git)- Supabase RLS habilitado em cada tabela
- Políticas RLS testadas (Usuário A não consegue ver dados do Usuário B)
- Código do lado do cliente usa apenas chave anon (chave de função de serviço apenas do lado do servidor)
- Autenticação em cada rota de API
- Verificações de autorização (verificação de propriedade) no acesso de dados
- Validação de entrada em cada formulário (do lado do servidor, não apenas do lado do cliente)
- Limites de upload de arquivo (tamanho e tipo) se aplicável
- Limite de taxa em endpoints de API
- Headers de segurança configurados
npm auditexecutado e problemas críticos corrigidos- Domínio personalizado com SSL configurado
- Implantações de visualização protegidas
- Teste manual de acesso a dados entre usuários passou
A Conclusão
Proteger um aplicativo codificado por vibe não é sobre se tornar um especialista em segurança. É sobre executar um checklist que detecta as lacunas previsíveis que IA deixa para trás. As etapas acima levam 2–4 horas e evitam as vulnerabilidades mais comuns. Para um aplicativo voltado ao cliente, isso não é opcional — é a diferença entre trabalho profissional e uma responsabilidade.
Se você está construindo seu primeiro aplicativo codificado por vibe, comece com nosso guia completo para codificação por vibe. Se você quer melhorar os prompts que você usa com Claude ou Cursor, tente nosso otimizador de prompt gratuito. E para uma análise das melhores ferramentas de codificação, veja Claude Code vs Codex.
Isto é o que fazemos toda semana. Um deep-dive em ferramentas de IA, fluxos de trabalho e opiniões honestas — sem hype, sem preenchimento. Junte-se a nós →
Divulgação: Alguns links neste artigo são links de afiliados. Recomendamos apenas ferramentas que testamos pessoalmente e usamos regularmente. Veja nossa política de divulgação completa.