Segurança em Vibe Coding e Supabase: RLS, Anon Key, Service Role e Como Auditar Apps do Lovable, Bolt e Cursor

Segurança em Vibe Coding e Supabase: RLS, Anon Key, Service Role e Como Auditar Apps do Lovable, Bolt e Cursor

Em resumo: Sim, o Supabase é seguro quando configurado corretamente, mas 8 em cada 10 aplicativos criados com Vibe Coding (no Lovable, Bolt.new, v0, Replit, Cursor e Claude Code) vão para o ar com falhas críticas porque conectam o navegador diretamente ao banco usando a supabase anon key sem políticas rigorosas de Row Level Security (supabase rls). Como a anon key é pública no front-end, qualquer pessoa que abrir o DevTools pode ler, editar ou apagar tabelas inteiras via PostgREST (/rest/v1/) se o RLS estiver desativado, se faltar a cláusula WITH CHECK em um UPDATE ou se uma VIEW não tiver security_invoker = true.

Neste guia prático de engenharia de segurança e auditoria de código, você vai aprender a diferença exata entre anon key e service_role key, como corrigir as 7 vulnerabilidades mais exploradas em apps Lovable + Supabase, como conectar o Supabase MCP (supabase mcp) em modo somente leitura no Claude Code, Cursor e Antigravity para auditar seu schema automaticamente, e quando blindar sua operação com um BFF em Cloudflare Workers.

Por que o Vibe Coding no Lovable e Bolt cria falhas silenciosas no Supabase?

Ferramentas como Lovable (lovable supabase), Bolt.new e Replit Agent foram desenhadas para maximizar a velocidade do primeiro protótipo. Para evitar que você precise programar um servidor back-end (API), elas geram código React/Vite que chama supabase.from('tabela').select('*') ou .update(...) diretamente do navegador do usuário.

O problema é que agentes de IA otimizam para o código funcionar na primeira tentativa, não para o princípio do menor privilégio. Quando uma query falha por falta de permissão durante o Vibe Coding, o próprio agente frequentemente aplica um destes três "atalhos" fatais na migração SQL:

1. Cria novas tabelas sem executar ALTER TABLE ... ENABLE ROW LEVEL SECURITY;
2. Cria uma política permissiva genérica (USING (true)) que libera leitura ou escrita pública para qualquer visitante anônimo;
3. Permite que o próprio front-end envie colunas sensíveis no UPDATE (como role: 'admin', is_pro: true ou credits: 99999) sem bloquear a alteração via WITH CHECK ou trigger.

Se você ainda está dando os primeiros passos no banco, recomendamos assistir em paralelo ao nosso Curso Grátis de Supabase sem Mistério (14 aulas), onde mostramos na prática a arquitetura interna do PostgREST, GoTrue (supabase authentication) e Storage.

Supabase Anon Key vs. Service Role Key: o que pode e o que NUNCA pode ir para o front-end

Uma das dúvidas mais buscadas por quem pesquisa se o Supabase é seguro é: "Vazar a SUPABASE_ANON_KEY no código JavaScript do navegador é uma falha de segurança?"

A resposta curta é: a anon key (ou publishable key sb_publishable_...) foi feita para ser pública, desde que 100% das suas tabelas tenham RLS ativo. Já a service_role key (ou secret key sb_secret_...) ignora completamente todo o RLS — se ela vazar no front-end, seu banco inteiro está comprometido.

As 7 vulnerabilidades fatais em apps Vibe Coding + Supabase (e como corrigir em SQL)

1. Tabelas sem RLS ativo ou com USING (true)

Por padrão no Postgres, qualquer tabela recém-criada no schema public com CREATE TABLE nasce com o RLS desligado — o que significa que a anon key tem acesso total de SELECT, INSERT, UPDATE e DELETE via API REST automática do Supabase.

Além disso, quando o Lovable ou Cursor tenta corrigir um erro 42501 (new row violates row-level security policy), é comum ele gerar CREATE POLICY "Enable all" ON public.orders FOR ALL USING (true);. Isso equivale a deixar a porta destrancada.

2. UPDATE sem WITH CHECK (Auto-Promoção para Admin ou Plano Pro)

Muitos desenvolvedores escrevem a seguinte política na tabela profiles:

-- ❌ VULNERÁVEL: Permite que o usuário edite a própria linha, INCLUSIVE mudando role = 'admin' ou plan = 'enterprise'!
CREATE POLICY "Users can update own profile"
ON public.profiles
FOR UPDATE
TO authenticated
USING ((SELECT auth.uid()) = id);

Com a política acima, o usuário logado abre o console do navegador e executa:

await supabase.from('profiles').update({ role: 'admin', credits: 999999 }).eq('id', myUserId)

Como corrigir? Combine USING + WITH CHECK e revogue a permissão de escrita em colunas sensíveis no nível do Postgres (ou separe billing/roles em uma tabela que somente o back-end escreve):

-- 1. Ative e force o RLS na tabela
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.profiles FORCE ROW LEVEL SECURITY;

-- 2. Revogue UPDATE irrestrito e libere apenas colunas seguras de perfil para o cliente
REVOKE UPDATE ON public.profiles FROM anon, authenticated;
GRANT UPDATE (full_name, avatar_url, bio, updated_at) ON public.profiles TO authenticated;

-- 3. Use (SELECT auth.uid()) em USING e WITH CHECK (otimizado com InitPlan e seguro)
CREATE POLICY "profiles_select_own"
ON public.profiles
FOR SELECT
TO authenticated
USING ((SELECT auth.uid()) = id);

CREATE POLICY "profiles_update_own"
ON public.profiles
FOR UPDATE
TO authenticated
USING ((SELECT auth.uid()) = id)
WITH CHECK ((SELECT auth.uid()) = id);

3. Views SQL criadas sem security_invoker = true

No PostgreSQL, uma VIEW padrão executa com as permissões do dono da view (postgres), ignorando completamente as políticas de RLS das tabelas subjacentes! Se o Lovable ou o Cursor criar uma CREATE VIEW public.user_billing_summary AS ..., qualquer visitante com a anon key conseguirá consultar a view inteira.

Sempre declare security_invoker = true (disponível no Postgres 15+ do Supabase):

CREATE OR REPLACE VIEW public.user_billing_summary
WITH (security_invoker = true)
AS
SELECT id, user_id, plan_status, current_period_end
FROM public.subscriptions;

4. Funções RPC (SECURITY DEFINER) sem search_path fixo

Funções criadas com SECURITY DEFINER rodam com os poderes de quem as criou. Se você criar uma RPC acessível via supabase.rpc('minha_funcao'), precisa obrigatoriamente:

1. Definir SET search_path = '' para impedir sequestro de objetos por schema injection;
2. Validar (SELECT auth.uid()) dentro do corpo da função;
3. Revogar a execução de PUBLIC e anon se a função for restrita:

REVOKE EXECUTE ON FUNCTION public.admin_grant_credits(uuid, int) FROM PUBLIC, anon, authenticated;
GRANT EXECUTE ON FUNCTION public.admin_grant_credits(uuid, int) TO service_role;

5. Buckets do Supabase Storage sem validação de pasta por auth.uid()

Marcar um bucket como "Public" no Supabase Storage permite que qualquer pessoa baixe qualquer arquivo se descobrir o caminho. Para documentos privados (contratos, notas fiscais, fotos de clientes, comprovantes), mantenha o bucket privado e exija que o primeiro segmento da pasta seja o auth.uid() do usuário:

CREATE POLICY "storage_user_private_folder"
ON storage.objects
FOR ALL
TO authenticated
USING (
  bucket_id = 'documentos-privados'
  AND (storage.foldername(name))[1] = (SELECT auth.uid()::text)
)
WITH CHECK (
  bucket_id = 'documentos-privados'
  AND (storage.foldername(name))[1] = (SELECT auth.uid()::text)
);

6. Proteção de Senhas Vazadas (Leaked Password Protection Supabase) e Auth

No painel do Supabase Authentication (Authentication -> Providers -> Email e Attack Protection), três configurações costumam ficar desligadas em projetos recém-criados:

• Leaked Password Protection (leaked password protection supabase): Integra o Supabase Auth com a base do HaveIBeenPwned.org via k-anonymity para impedir que usuários cadastrem senhas já expostas em vazamentos globais;
• Confirm Email + Secure Email Change: Se "Confirm email" estiver desativado, qualquer atacante pode criar uma conta usando o e-mail de outra pessoa antes dela e sequestrar pré-cadastros ligados pelo endereço de e-mail;
• Rate Limits + Cloudflare Turnstile: Sempre ative o CAPTCHA nativo (Cloudflare Turnstile) nas rotas de signUp, signInWithPassword e signInWithOtp para bloquear ataques de força bruta e exaustão de cota de e-mail/SMS.

7. Performance + Segurança: (SELECT auth.uid()) vs auth.uid()

Chamar auth.uid() = user_id diretamente na política RLS faz o Postgres reexecutar a função a cada linha varrida na tabela. Quando você envolve em um subselect escalar — (SELECT auth.uid()) = user_id — e cria um índice CREATE INDEX idx_tabela_user_id ON public.tabela (user_id);, o planejador do Postgres faz o cache do UID uma única vez por query (InitPlan), acelerando consultas em até 100x e evitando ataques de negação de serviço (DoS) no banco.

-- 1. Lista tabelas no schema public com RLS DESATIVADO (Vulnerabilidade Crítica)
SELECT
  n.nspname AS schema_name,
  c.relname AS table_name,
  c.relrowsecurity AS rls_enabled,
  c.relforcerowsecurity AS rls_forced,
  'CRÍTICO: Tabela exposta na API PostgREST sem RLS!' AS diagnostico
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public'
  AND c.relkind = 'r'
  AND NOT c.relrowsecurity
ORDER BY c.relname;

-- 2. Lista políticas permissivas perigosas (FOR ALL / INSERT / UPDATE / DELETE com true)
SELECT
  schemaname,
  tablename,
  policyname,
  cmd,
  roles,
  qual AS using_expression,
  with_check AS with_check_expression
FROM pg_policies
WHERE schemaname = 'public'
  AND (
    (cmd IN ('ALL', 'UPDATE', 'DELETE') AND COALESCE(qual, '') = 'true')
    OR (cmd IN ('ALL', 'INSERT', 'UPDATE') AND COALESCE(with_check, '') = 'true')
  );

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": [
        "-y",
        "@supabase/mcp-server-supabase@latest",
        "--read-only",
        "--project-ref=SEU_PROJECT_REF_DE_STAGING"
      ],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "${SUPABASE_ACCESS_TOKEN}"
      }
    },
    "escola-aplicativos": {
      "type": "http",
      "url": "https://www.escoladeaplicativos.com.br/api/publico/mcp"
    }
  }
}

claude mcp add supabase -- npx -y @supabase/mcp-server-supabase@latest --read-only --project-ref=SEU_PROJECT_REF