Quais são os riscos de segurança ao usar Lovable, Bolt, Cursor ou v0?

Cada ferramenta de vibe coding tem seus próprios padrões de risco — determinados pela stack que ela favorece, pelo ambiente onde o código roda e pelo nível de controle que dá ao desenvolvedor. O Lovable integra Supabase automaticamente mas raramente configura o RLS. O Bolt opera em um ambiente onde projetos podem ser públicos por padrão. O Cursor segue instruções ao pé da letra — inclusive as inseguras. O v0 gera componentes de interface que precisam de API routes externas sem guardrails. Conhecer o padrão de risco da sua ferramenta é o primeiro passo para proteger o app antes do lançamento.

Lovable

Stack típica: Next.js + Supabase + Vercel

O Lovable é a plataforma de vibe coding mais integrada ao Supabase — ela configura o banco automaticamente ao iniciar um projeto. Isso é conveniente, mas cria um risco estrutural: o código gerado frequentemente usa a service_role key com o prefixo NEXT_PUBLIC_, expondo credenciais administrativas no bundle JavaScript público. Além disso, as tabelas Supabase criadas automaticamente raramente têm o Row Level Security configurado.

O deploy automático para Vercel é prático, mas significa que o app vai ao ar rapidamente — antes que haja chance de uma revisão de segurança. Problemas que em outros fluxos seriam pegos durante o setup do ambiente de produção chegam ao ar junto com o código.

// Padrão comum gerado pelo Lovable — service role key exposta
import { createClient } from '@supabase/supabase-js';

// ❌ SERVICE_ROLE_KEY com NEXT_PUBLIC_ — acesso admin exposto publicamente
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY! // crítico
);

// ✅ Separar clientes por contexto
// lib/supabase/client.ts — para o frontend (usa anon key)
import { createBrowserClient } from '@supabase/ssr';
export const createClient = () =>
  createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // anon key é pública por design
  );

// lib/supabase/server.ts — para API routes (service role nunca vai ao browser)
import { createServerClient } from '@supabase/ssr';
export const createAdminClient = () =>
  createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!, // sem NEXT_PUBLIC_
    { cookies: { getAll: () => [] } }
  );

Bolt.new

Stack típica: SvelteKit ou Next.js + Supabase/Neon + StackBlitz

O Bolt.new opera dentro do ambiente StackBlitz — um IDE no navegador onde o projeto tem uma URL própria. Por padrão, projetos StackBlitz podem ser acessados publicamente por qualquer pessoa com o link. Isso significa que durante o desenvolvimento, dados de teste e estrutura do projeto ficam expostos para quem tiver a URL.

O código gerado pelo Bolt frequentemente não inclui verificação de autenticação nos endpoints de API — a prioridade é fazer o fluxo funcionar. Endpoints de mutação (criação, atualização, deleção) ficam abertos, e o padrão de aceitar userId no body da requisição sem verificar sessão é recorrente.

// Padrão Bolt — endpoint sem autenticação
// api/update-user/+server.ts (SvelteKit) ou similar
export async function POST({ request }) {
  const { userId, nome, email } = await request.json();

  // ❌ Nenhuma verificação de quem está fazendo a requisição
  // Qualquer pessoa pode passar qualquer userId
  await db.from('users').update({ nome, email }).eq('id', userId);

  return json({ success: true });
}

Cursor

Stack: qualquer — o Cursor edita projetos existentes

O Cursor é diferente das outras ferramentas: ele não cria um projeto do zero numa plataforma própria — ele opera no seu repositório local, editando arquivos reais. Isso dá mais controle, mas também significa que o desenvolvedor é inteiramente responsável pela segurança. O Cursor não tem guardrails de segurança automáticos: se você pedir para "remover a autenticação para testar mais rápido", ele removerá — e o código vai para o repositório assim.

O risco mais específico do Cursor são os comentários // TODO: reativar autenticação que ficam no código e nunca são revisitados. Em projetos onde o desenvolvedor está focado em velocidade, é comum que essas marcações cheguem à produção — especialmente quando o Cursor está sendo usado para iterar rapidamente.

// Cursor segue instruções literalmente
// Se você pediu "remova a autenticação para testar":

// ❌ Middleware desabilitado para "facilitar o desenvolvimento"
export function middleware(request: NextRequest) {
  // TODO: reativar autenticação
  // if (!isAuthenticated(request)) redirect('/login');
  return NextResponse.next();
}

// Esse TODO vai para produção junto com o código

v0 (Vercel)

Stack típica: Next.js + Vercel — foco em componentes UI

O v0 é fundamentalmente diferente: ele gera componentes de interface, não apps completos. O risco de segurança direto é menor — um componente React não tem acesso a banco de dados ou chaves de API por si só. O problema aparece quando o desenvolvedor cria as API routes que dão suporte a esses componentes: sem um template de referência seguro, essas rotas frequentemente ficam abertas.

Um ponto específico do ecossistema Vercel: preview deployments herdam as variáveis de ambiente configuradas no projeto. Se você usa a mesma chave de banco de dados em produção e em previews, qualquer colaborador com acesso ao Vercel pode interagir com os dados de produção a partir de um deploy de preview.

// v0 gera componentes React — o risco fica nas API routes
// que o desenvolvedor cria para dar suporte ao componente

// ❌ API route sem validação de entrada gerada manualmente
// após o v0 criar o componente de formulário
export async function POST(request: Request) {
  const body = await request.json();
  // Sem validação de tipo, sem auth check, sem sanitização
  await db.insert('submissions').values(body); // injection risk
  return Response.json({ ok: true });
}

O que todas têm em comum

Independente da ferramenta, o padrão de risco é o mesmo: velocidade de entrega priorizada sobre segurança. Nenhuma dessas plataformas executa uma revisão de segurança automática antes do deploy. Nenhuma alerta quando uma chave privada usa um prefixo público. Nenhuma verifica se o RLS está ativo ou se os endpoints têm autenticação.

A responsabilidade pela segurança em produção não é da ferramenta — é do desenvolvedor. O que muda entre as ferramentas é onde os problemas mais prováveis aparecem, o que permite uma revisão direcionada e eficiente antes do lançamento.

Leia também