O lado obscuro do Vibe Coding

O movimento Vibe Coding transformou a maneira como criamos software. A promessa é sedutora: você descreve sua ideia em linguagem natural, e uma plataforma de IA (Bolt.new, Lovable, Abacus) que são ferramentas especializadas para gerar um aplicativo full-stack funcional em minutos.

No entanto, há um perigo silencioso nesse fluxo de trabalho. Muitas dessas ferramentas utilizam o Supabase como backend padrão. Se você não for específico no seu prompt, pode acabar com uma aplicação onde qualquer pessoa na internet consegue ler, alterar ou deletar os dados de todos os seus usuários.

O Contexto Histórico: Da Rebeldia de Karpathy ao Mainstream

O termo Vibe Coding não nasceu em um laboratório de engenharia tradicional, mas sim de uma observação provocativa de Andrej Karpathy (cofundador da OpenAI) em fevereiro de 2025. Ao descrever um fluxo de trabalho onde a sintaxe é irrelevante e a "vibe" (a intenção e o feedback visual) é tudo, Karpathy deu nome a um movimento que o lendário produtor Rick Rubin comparou ao "Punk Rock do Software".

Em 2025, o termo foi eleito a palavra do ano pelo dicionário Collins, consolidando a ideia de que qualquer pessoa com uma boa ideia e um prompt pode ser um desenvolvedor. No entanto, essa origem focada na velocidade e na expressão criativa trouxe um efeito colateral: a negligência com fundamentos invisíveis, como o RLS, que agora, em 2026, define a fronteira entre um protótipo amador e um app profissional seguro.

No presente artigo, vamos entender a vulnerabilidade de RLS (Row Level Security) desabilitado e como corrigi-la com uma simples mudança na sua instrução inicial.

O que é Vibe Coding e por que o Supabase?

Vibe Coding é o termo cunhado para descrever o desenvolvimento de software focado na intenção e na iteração rápida através de prompts de IA, onde o desenvolvedor atua mais como um "maestro" do que como um digitador de sintaxe.

Para que essa "mágica" aconteça, a IA precisa de um backend que seja fácil de configurar programaticamente. O Supabase é a escolha ideal por ser um "Firebase Open Source" baseado em PostgreSQL, oferecendo banco de dados, autenticação e armazenamento de forma instantânea.

O problema surge na configuração padrão.

O Perigo: A Chave Anon e o RLS Desabilitado

Quando uma plataforma (Bolt.new, Lovable, Abacus) cria um app Supabase para você, ela gera um arquivo de configuração (geralmente .env) contendo a SUPABASE_URL e a SUPABASE_ANON_KEY.

Diferente de backends tradicionais onde a chave do banco de dados fica escondida no servidor, no modelo de arquitetura moderna (PostgREST), a chave anon é pública e fica exposta no navegador do usuário.

O que é RLS (Row Level Security)?

RLS significa Row Level Security (Segurança em Nível de Linha). É um recurso do banco de dados PostgreSQL que permite definir regras granulares para quem pode ver ou modificar cada linha em uma tabela.

Sem RLS: Se você tem a chave anon, você tem acesso total às tabelas.

Com RLS: Mesmo com a chave anon, o banco de dados pergunta: "Quem é este usuário e ele tem permissão para ver esta linha específica?"

A Anatomia da Vulnerabilidade

Imagine que você pediu na plataforma (Bolt.new, Lovable, Abacus):

"Crie um app de gestão de clientes para minha agência".

A plataforma (Bolt.new, Lovable, Abacus) cria uma tabela chamada clientes. Por padrão, para facilitar o desenvolvimento e garantir que o app "funcione de primeira" (a famosa "vibe"), muitas ferramentas de geração de código criam as tabelas sem habilitar o RLS.

O Cenário de Desastre

1. O hacker acessa seu site.
2. Abre o console do desenvolvedor (F12) e encontra sua SUPABASE_ANON_KEY.
3. Utiliza uma ferramenta simples ou até o próprio terminal para fazer uma requisição à API do seu Supabase:
curl 'https://seu-projeto.supabase.co/rest/v1/clientes?select=*' \
-H "apikey: SUA_CHAVE_ANON" \
-H "Authorization: Bearer SUA_CHAVE_ANON"


O resultado? O invasor recebe um JSON com todos os dados de todos os clientes, e-mails, faturamentos e notas administrativas. Se o RLS estiver desabilitado, a chave "Anônima" tem poderes de administrador sobre os dados públicos.

A Solução: Ajustando o seu Prompt

A boa notícia é que a IA é obediente. O erro não está na tecnologia, mas na omissão da segurança no prompt inicial. Para garantir que seu app seja seguro desde o "dia zero", você deve incluir instruções explícitas de segurança.

O "Prompt Seguro"

Sempre que iniciar um projeto de Vibe Coding, adicione este parágrafo ao seu comando:

"Habilite o Row Level Security (RLS) em todas as tabelas criadas no Supabase. Crie políticas de segurança para que usuários autenticados possam ler e escrever apenas seus próprios dados, e garanta que dados administrativos não sejam acessíveis via chave anon sem as devidas permissões."

Ao fazer isso, a IA na plataforma (Bolt.new, Lovable, Abacus) gerará o SQL necessário para proteger seu banco, parecido com este:

-- Exemplo do que a IA deve gerar nos bastidores
ALTER TABLE clientes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Usuários só vêem seus próprios clientes"
ON clientes FOR SELECT

USING (auth.uid() = user_id);

Tabela Comparativa: Sem RLS vs. Com RLS

Recurso	Sem RLS (Padrão Vibe)	Com RLS (Prompt Seguro)
Visibilidade da Chave	Exposta no Browser (Normal)	Exposta no Browser (Normal)
Acesso a dados alheios	Livre (Risco Total)	Bloqueado pelo Banco
Privacidade	Inexistente	Garantida por UID
Escalabilidade	Perigosa	Segura para Produção

Considerações finais

O Vibe Coding é o futuro, mas a segurança não pode ser deixada para depois. Ao entender que o Supabase delega a segurança para o nível da linha (RLS), você assume o controle da integridade dos dados dos seus usuários.

Não deixe que a agilidade de um prompt comprometa a confiança dos seus clientes. Segurança também faz parte da "vibe".

Feito!