5 Erros de Segurança que Todo Programador Vibe Comete (E Como Corrigi-los)

Código gerado por IA funciona. Ele roda. Parece correto. Também vem com as mesmas cinco vulnerabilidades de segurança em quase todos os projetos. Esses não são riscos teóricos — são os furos específicos que aparecem em quase todos os codebases produzidos por Claude, Cursor, Replit ou Copilot quando você não pede explicitamente por segurança.

Auditei dezenas de projetos vibe-coded no ano passado, e os mesmos cinco erros aparecem em pelo menos 80% deles. Cada um leva menos de 30 minutos para corrigir. Aqui está o que procurar e exatamente como corrigir.

Erro 1: Chaves de API Hardcoded no Código Frontend

Como acontece: Você diz ao Claude "conectar ao Supabase" ou "adicionar pagamentos com Stripe", e ele gera código com a chave de API colada diretamente em um componente React. O código funciona perfeitamente — e sua chave secreta é visível para qualquer um que abra o DevTools do navegador e verifique a aba Network ou o código-fonte JavaScript.

Por que é perigoso: Sua chave de service role do Supabase ignora toda a segurança do banco de dados. Sua chave secreta do Stripe permite que alguém cobre cartões ou emita reembolsos. Sua chave OpenAI permite que alguém acumule milhares em chamadas de API em sua conta. Bots ativamente verificam repositórios públicos do GitHub e sites implantados em busca de chaves expostas.

A correção: Mova cada segredo para variáveis de ambiente. No Next.js, apenas variáveis começando com NEXT_PUBLIC_ chegam ao navegador. Qualquer chave que conceda acesso de escrita, acesso de admin ou acesso financeiro deve ser apenas do lado do servidor.

Após mover chaves para .env.local, procure em todo o seu codebase pelos antigos valores de chave para garantir que estão desaparecidos. Depois verifique seu histórico do Git — se a chave foi commitada alguma vez, ainda está no histórico do seu repo mesmo que você a tenha deletado. Regenere (rotacione) qualquer chave que foi exposta, mesmo que brevemente.

Tempo para corrigir: 15–30 minutos.

Erro 2: Tabelas Supabase Sem Row-Level Security

Como acontece: IA gera queries de criação de tabelas Supabase e operações CRUD, mas não ativa Row-Level Security (RLS). Por padrão, tabelas Supabase com RLS desativada são totalmente acessíveis para qualquer um com sua URL de projeto e chave anon — ambas são públicas (e devem ser).

Por que é perigoso: Sem RLS, Usuário A pode consultar dados do Usuário B. Uma simples chamada fetch do console do navegador pode puxar cada linha de cada tabela. Seu banco de dados inteiro é efetivamente público.

Como identificar: Vá ao seu dashboard Supabase → Table Editor. Se qualquer tabela mostrar "RLS Disabled", você tem este problema. Também verifique se seu código do lado do cliente usa a chave service_role em vez da chave anon — isso é ainda pior.

A correção: Ative RLS em cada tabela. Depois crie políticas que correspondam aos padrões de acesso do seu app. A política mais comum: usuários podem apenas SELECT, INSERT, UPDATE e DELETE linhas onde auth.uid() = user_id. Teste fazendo login como um usuário e tentando acessar dados de outro usuário através da REST API do Supabase.

Tempo para corrigir: 30–60 minutos dependendo da quantidade de tabelas.

Erro 3: Nenhuma Validação de Input em Formulários ou Rotas de API

Como acontece: IA gera formulários que aceitam qualquer input e rotas de API que confiam em qualquer dado que chegar. O formulário tem um atributo "required" em HTML, mas nenhuma validação do lado do servidor. Alguém ignora o formulário inteiramente enviando uma requisição de API direta com qualquer payload que quiser.

Por que é perigoso: Sem validação do lado do servidor, invasores podem injetar scripts no seu banco de dados (stored XSS), enviar payloads gigantes que derrubam seu servidor ou submeter dados que quebram a lógica do seu app (como um preço negativo ou um campo de email contendo SQL).

Como identificar: Abra qualquer rota de API ou server action no seu codebase. Se usa req.body ou dados de formulário sem verificar a forma, tipo e comprimento de cada campo, você tem este problema.

A correção: Adicione validação do lado do servidor em cada endpoint usando uma biblioteca de validação de schema. Zod é o padrão para projetos TypeScript:

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// In your API route:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

Para qualquer campo que renderize como HTML (comentários, descrições, bios), também sanitize a saída com DOMPurify antes de exibir.

Tempo para corrigir: 30–60 minutos.

Erro 4: Nenhum Rate Limiting em Endpoints de API

Como acontece: IA nunca adiciona rate limiting a menos que você peça. Cada rota de API que seu app expõe pode ser atingida milhares de vezes por segundo por qualquer um com um script.

Por que é perigoso: Sem rate limiting, alguém pode fazer força bruta no seu endpoint de login, fazer scraping do seu banco de dados atingindo endpoints de lista repetidamente, sobrecarregar seu servidor (negação de serviço) ou queimar sua quota de API se seus endpoints chamam serviços externos como OpenAI ou Stripe.

Como identificar: Se nenhuma de suas rotas de API verificam quantas requisições um único IP ou usuário fez recentemente, você não tem rate limiting.

A correção: A abordagem mais simples para apps hosted no Vercel é um rate limiter em memória para desenvolvimento e um baseado em Redis para produção. Edge Middleware do Vercel pode lidar com rate limiting básico. Upstash Redis (tier gratuito) com @upstash/ratelimit dá a você rate limiting de qualidade produção em uma pequena quantidade de código.

Um ponto de partida razoável: 60 requisições por minuto para usuários autenticados, 20 por minuto para usuários não autenticados e 5 por minuto para endpoints de login/signup (para prevenir força bruta).

Tempo para corrigir: 20–45 minutos.

Erro 5: Falta de Verificações de Auth em Páginas e APIs Protegidas

Como acontece: IA gera uma página de dashboard linda e rotas de API que retornam dados do usuário, mas não adiciona middleware para verificar que o usuário está realmente logado. A página "funciona" porque durante desenvolvimento você sempre está logado. Em produção, alguém pode acessar a URL do dashboard diretamente sem fazer login ou bater no endpoint de API e obter dados.

Por que é perigoso: Acesso não autenticado a páginas protegidas significa que qualquer um pode ver dashboards de usuário, painéis de admin ou dados privados apenas adivinhando a URL. Rotas de API desprotegidas significam que qualquer ferramenta como Postman ou curl pode puxar dados sem credenciais.

Como identificar: Abra uma janela incógnita do navegador (não logado) e navegue diretamente para suas URLs de dashboard, settings ou admin. Se conseguir ver qualquer conteúdo sem ser redirecionado para uma página de login, você tem este problema. Depois tente bater nas suas rotas de API diretamente — se retornarem dados sem um cookie de sessão válido ou auth token, essas também estão desprotegidas.

A correção: Adicione middleware de autenticação que roda antes de cada rota protegida. No Next.js App Router, crie um middleware.ts na raiz do seu projeto:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

Adapte o matcher para cobrir cada rota que deveria exigir autenticação. Teste em incógnito após implementar.

Tempo para corrigir: 15–30 minutos.

Como Prevenir Isso em Projetos Futuros

O padrão é claro: IA gera código que funciona funcionalmente mas pula segurança porque você não pediu. A correção é pedir upfront.

Adicione isto ao fim do seu prompt inicial para qualquer projeto vibe-coded:

SECURITY REQUIREMENTS:
- All secrets in environment variables (never hardcoded)
- Supabase RLS enabled on all tables with per-user policies
- Server-side input validation on every API route (use Zod)
- Rate limiting on all public endpoints
- Authentication middleware on all protected routes
- No service role key in client-side code

Isso não vai pegar tudo, mas elimina as cinco vulnerabilidades mais comuns na primeira passada em vez de exigir uma limpeza depois.

Se você quer ficar melhor em escrever prompts que produzem código mais seguro desde o início, nosso otimizador de prompt gratuito pode ajudá-lo a estruturar suas instruções. E para um walkthrough de segurança completo, veja nosso guia passo a passo: Como Proteger um App Vibe-Coded Antes de Entregar para Clientes.

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