Chupabase: Extraindo dados de aplicações Lovable mal configuradas

Escrito por Thiago Bispo, Lucas William, Edson Araujo

Resumo

Aplicações desenvolvidas com plataformas de vibe coding vêm reduzindo significativamente a barreira de entrada para a criação de software. Ferramentas como a Lovable permitem que usuários criem aplicações completas, incluindo frontend, backend e banco de dados, sem necessidade de conhecimento profundo de programação.

Entretanto, essa abstração também desloca responsabilidades críticas de segurança para configurações que muitas vezes passam despercebidas pelos desenvolvedores. Em aplicações que utilizam Supabase como backend, permissões incorretas em políticas de acesso podem permitir que dados sensíveis sejam acessados diretamente por usuários não autenticados.

Este artigo apresenta o Chupabase, uma ferramenta desenvolvida para identificar e explorar automaticamente essas configurações inseguras em aplicações geradas com Lovable. A ferramenta analisa bundles JavaScript da aplicação, reconstrói endpoints da API e verifica quais recursos podem ser acessados pela role pública.

Introdução

Nos últimos anos, plataformas de desenvolvimento baseadas em inteligência artificial vêm transformando a forma como as aplicações são criadas. Ferramentas como a Lovable [1], permitem que usuários descrevam funcionalidades em linguagem natural e obtenham aplicações completas em poucos minutos. Esse modelo, frequentemente chamado de vibe coding, prioriza velocidade e experimentação, reduzindo significativamente o esforço necessário para construir novos produtos digitais.

A rápida adoção dessas ferramentas reflete esse potencial. Apenas alguns meses após sua criação, a Lovable alcançou um valor de mercado superior a um bilhão de dólares [2], impulsionando o uso da plataforma em diversos contextos organizacionais.

No entanto, a mesma facilidade que acelera o desenvolvimento também pode introduzir riscos relevantes de segurança. Em muitos casos, usuários sem experiência em engenharia de software ou segurança acabam publicando aplicações completas sem compreender plenamente como os mecanismos de autenticação e autorização são configurados. Quando esses controles são definidos de forma inadequada, ou simplesmente omitidos, a aplicação pode expor dados diretamente através de APIs públicas.

Por padrão, essas aplicações utilizam o Supabase como infraestrutura de backend. Nesse modelo, o banco de dados é exposto por meio de APIs automáticas, e o controle de acesso depende de políticas configuradas diretamente no banco. Quando essas políticas são mal definidas, o backend deixa de ser apenas um componente interno da aplicação e passa a se tornar um ponto de acesso direto para atacantes.

Curiosamente, esse cenário lembra um fenômeno conhecido no folclore latino-americano: o mito do Chupacabra [3]. Durante décadas, relatos sobre a criatura que atacaria rebanhos no interior das Américas espalharam medo entre criadores de animais. O simples temor da presença da criatura levou muitos produtores a reforçar cercas, proteger seus animais e vigiar melhor seus rebanhos.

No contexto de aplicações modernas, algo semelhante deveria acontecer. O risco de exploração por agentes maliciosos deveria incentivar desenvolvedores a monitorar melhor seus sistemas, revisar permissões e proteger adequadamente seus dados.

Este artigo explora como aplicações geradas com Lovable podem expor inadvertidamente seus backends quando essas proteções não são configuradas corretamente. Além disso, apresenta a ferramenta Chupabase, projetada para identificar rapidamente essas exposições e demonstrar o impacto de configurações inseguras, funcionando como um “chupacabra” capaz de drenar dados de aplicações mal protegidas.

AnonKey e as Policies RLS

Aplicações desenvolvidas em Lovable utilizam o Supabase como Backend-as-a-Service (BaaS) [4], que por sua vez fornece banco de dados PostgreSQL com APIs REST em tempo real conectadas diretamente ao banco. Esta ferramenta expõe seu banco de dados via PostgREST, utilizando a uma chave anônima chamada anonKey para permitir a interação com a aplicação através do acesso público ou de usuários não autenticados. A anonKey não é um segredo de segurança, e sim um identificador de função (role “anon”), e sua exposição por si só não é considerada uma vulnerabilidade. O problema ocorre quando essa role possui permissões excessivas, o que a transforma em um convite aberto para o chupacabra de dados. A exposição (padrão) da anonKey e a URL do backend em uma aplicação Lovable pode ser vista na Figura 1.

***Figura 1*** *– Arquivo de índice com a chave de API* **`anonKey`** *e a URL do Supabase associado à aplicação.*

O Row-Level Security (RLS) [5] é uma funcionalidade do Supabase que permite definir políticas granulares que determinam exatamente quais linhas de uma tabela do banco de dados podem ser acessadas ou modificadas por uma determinada role (como as roles “anon” ou “authenticated”).

Abaixo, seguem exemplos de políticas RLS aplicadas a tabelas dos bancos de dados para restringir ou permitir acessos:

Cenário	Comando SQL (Policy)	Impacto de Segurança
Leitura Pública	`CREATE POLICY "Public Select" ON posts FOR SELECT TO anon USING (true);`	Permite leitura total na tabela posts por qualquer usuário com a `anonKey`.
Acesso Restrito ao Dono	`CREATE POLICY "Owner Access" ON profiles FOR ALL TO authenticated USING (auth.uid() = id);`	Garante que usuários logados só vejam/editem seus próprios dados (tabela profiles).
Inserção Anônima	`CREATE POLICY "Public Insert" ON leads FOR INSERT TO anon WITH CHECK (true);`	Permite que visitantes (tabela leads) enviem formulários (ex: Landing Pages), mas sem permissão de leitura.
Privilégio Zero	`ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;`	Sem políticas adicionais na tabela sensitive_data, todo acesso via API é negado por padrão.

Sem políticas de RLS ativas ou mal configuradas, uma tabela pode estar completamente exposta a qualquer pessoa que tenha posse de dois requisitos:

Endpoints de API do PostgREST (mapa de rotas da aplicação); e
Chave de API anonKey.

Mapa de rotas do lado do cliente

Por padrão, projetos em Lovable costumam utilizar como stack de desenvolvimento:

Frontend: React, Vite, Tailwind CSS e shadcn/ui.
Backend: NodeJS com Typescript.
Database: Supabase com PostgreSQL.

Aplicações que utilizam o Vite Plugin PWA buscam otimização offline e cache agressivo, mas frequentemente introduzem uma possibilidade de vazamento de informações.

O arquivo sw.js (Service Worker) atua como um mapa de rotas da aplicação. Em outras palavras, o Service Worker acaba funcionando como um mapa do tesouro da aplicação, e infelizmente o tesouro às vezes é a própria base de dados. Através do comando precacheAndRoute, o plugin gera um manifesto de todos os assets da aplicação, incluindo endpoints de API. O sw.js permite contornar o hashing de nomes de arquivos (ex: index-D8f2k9.js), fornecendo um índice direto do código-fonte, como visto na Figura 2.

***Figura 2*** *– Arquivo sw.js com o mapa de rotas da aplicação.*

Mesmo sem o service worker, o bundle principal (index.js) normalmente contém as chamadas à API. Ao analisar esse arquivo é possível reconstruir o mapa de endpoints da aplicação.

***Figura 3*** *– Exemplo de rota de API encontrada no arquivo de index.*

Lendo rota por rota, é possível construir um mapa das chamadas API. Em posse do mapa, um atacante consegue chegar no backend da aplicação sem precisar navegar pelas telas, apenas lendo o que está disponível do lado do cliente. Assim como a criatura mítica brasileira [6], uma variação do Chupacabra, um mapa permite que um adversário chegue em lugares remotos que ele não deveria ter acesso e amedrontar quem lá habita. A criatura conseguiu chegar à Goianinha e nós chegamos ao backend do Supabase, faltando apenas conseguir o acesso para consumir os endpoints.

O risco das APIs públicas

A superfície de ataque de um projeto Supabase não se limita a tabelas. O uso indevido da anonKey expõe três vetores principais:

Tabelas REST (PostgREST): Se o RLS estiver desativado ou mal configurado, a extração de dados é direta.
RPCs (Remote Procedure Calls): Funções do Postgres expostas como API. Elas podem ser executadas com privilégios elevados dependendo do modo de execução (SECURITY DEFINER).
Edge Functions: Funções server-side que rodam em Deno. Se não houver validação explícita do JWT usando supabase.auth.getUser() ou biblioteca equivalente, elas tornam-se endpoints públicos vulneráveis.

Se algum desses vetores estiver público (configuração padrão), é possível consumir os endpoints diretamente, sem necessitar de login na aplicação. Com isso, um atacante tem o mapa da aplicação e a configuração inadequada para explorar sem necessitar de autenticação, o equivalente, para um predador, a já sentir o cheiro do rebanho.

Modelagem de ameaças

Para entender o cenário de ataque e os riscos associados foi construído um diagrama de modelagem de ameaças, como visto na Figura 4.

Ator da ameaça

O atacante considerado é um usuário externo não autenticado, sem acesso privilegiado à aplicação. O único requisito é a capacidade de acessar a interface pública da aplicação ou seus arquivos estáticos distribuídos pelo frontend.

Não é assumido acesso ao código-fonte original, credenciais internas ou acesso administrativo ao ambiente.

Pré-condições

Para que o cenário de exploração seja viável, algumas condições precisam estar presentes:

A aplicação expõe bundles JavaScript contendo referências à infraestrutura backend.
O projeto utiliza Supabase com APIs REST geradas automaticamente.
A aplicação disponibiliza publicamente a anonKey, que identifica a role anon.
Políticas de autorização (RLS) ou validações de autenticação não estão configuradas corretamente.

Essas condições são comuns em aplicações geradas por ferramentas de vibe coding da Lovable, nas quais o foco do desenvolvimento está na funcionalidade da interface.

Superfície de ataque

A superfície de ataque considerada neste estudo inclui três componentes principais da arquitetura Supabase:

APIs REST (PostgREST)
Tabelas do banco de dados expostas automaticamente via endpoints REST. Se as políticas de Row-Level Security estiverem ausentes ou permissivas, dados podem ser acessados diretamente pela role anon.
RPCs (Remote Procedure Calls)
Funções SQL expostas como endpoints de API. Caso não implementem validação explícita de autenticação, podem executar lógica sensível sem restrição adequada.
Edge Functions
Funções server-side que podem ser invocadas diretamente via HTTP. Sem validação do cabeçalho Authorization, essas funções podem se tornar endpoints públicos acessíveis por qualquer cliente.

Impacto potencial

Dependendo da configuração da aplicação, um atacante pode:

enumerar endpoints internos da API
acessar dados armazenados em tabelas do banco
executar funções expostas via RPC
extrair grandes volumes de dados sem autenticação
automatizar a exploração utilizando ferramentas como o Chupabase

Em cenários mais graves, a ausência de controles de autorização pode permitir a extração completa da base de dados da aplicação.

Chupabase – a ferramenta para exploração automatizada

Para automatizar a facilidade com que um backend mal configurado pode ser exposto, foi criada a Chupabase [7], uma ferramenta de automação inspirada em scripts de análise de aplicações criadas por inteligência artificial desta forma. O nome foi inspirado na criatura mitológica Chupacabra (e criaturas derivadas) que drena o sangue de animais, uma vez que a ferramenta drena os dados de tabelas de banco de dados quando o controle de acesso está mal configurado. Diferente da criatura de Goianinha, que atrapalha e destrói o que vê pela frente, a Chupabase foi pensada para auxiliar na detecção e demonstração de impacto das políticas de acesso mal configuradas.

A ferramenta consiste em um script em python que transforma um bundle JavaScript minificado em uma documentação estruturada, com swagger, efetivamente realizando a engenharia reversa automatizada da API.

Fluxo de Funcionamento

A ferramenta funciona através de 6 passos:

Mapeamento: Busca o sw.js para identificar os assets precached (passo opcional, caso a aplicação tenha sw.js).
Identificação: Localiza o maior arquivo .js (index), geralmente o bundle principal da aplicação.
Extração de Segredos: Detecta automaticamente a URL do Supabase e a anonKey.
Reconstrução de API: Varre o código em busca de chamadas .from(), .rpc() e URLs de Edge Functions.
Geração de Swagger: Consolida todos os endpoints encontrados em um arquivo swagger.yaml. Isso permite que o auditor utilize ferramentas como Swagger UI ou Postman para testar a API com um clique.
Auditoria Ativa: Se executado com a flag de teste, o script verifica quais endpoints respondem com 200 OK sob a role anon.

Comandos de Uso

Conforme definido na lógica do script, a ferramenta opera com flags flexíveis:

python run.py –url https://app.lovable.app (Análise completa e download)
python run.py –url https://app.lovable.app –skip-download (Auditoria sem persistência local)
python run.py –url https://app.lovable.app –skip-download –no-test (Geração de documentação sem probing)
python run.py –url https://app.lovable.app –methods get (Específica o método HTTP para realizar as requisições, por exemplo, apenas GET)

Explorando a vulnerabilidade

Durante testes preliminares utilizando a ferramenta Chupabase, foram identificadas diversas aplicações com tabelas acessíveis pela role anon, incluindo dados de usuários, logs e registros de formulários.

A Figura 5 mostra a execução da Chupabase em uma aplicação criada e publicada na plataforma Lovable, utilizando o index para identificar as rotas do backend. Além disso, ela mapeia a chave de API e a URL do Supabase para montagem do Swagger.

***Figura 5****– Executando a ferramenta em uma aplicação publicada na Lovable.*

Com isso, a ferramenta testa os endpoints usando a chave de API (anonkey) encontrada, o que pode ser visto na Figura 6.

***Figura 6*** *– Teste dos endpoints mapeados no passo anterior.*

Eventualmente, os testes podem realizar a extração de dados que não deveriam ser públicos, como mostrado na Figura 7.

***Figura 7****– Extração de dados de usuários, evidenciando problemas no controle de acesso.*

CVE-2025-48757

O pesquisador Matt Palmer identificou esse cenário de exploração através da vulnerabilidade registrada sob a CVE-2025-48757, reportada inicialmente em março de 2025 e tornada pública em maio do mesmo ano [8]. Ele expôs dados de mais de 170 aplicações geradas pela plataforma Lovable devido à ausência ou má configuração de políticas de Row Level Security (RLS). Embora o problema já tenha sido amplamente reportado na comunidade de segurança, a resolução centralizada é complexa. Como a arquitetura da plataforma delega os controles de acesso e a segurança do banco de dados diretamente para o usuário final, a própria Lovable argumenta que cada cliente assume a responsabilidade de proteger os dados da sua respectiva aplicação. Sendo assim, como a segurança efetiva precisa ser implementada e validada individualmente em cada projeto, torna-se extremamente difícil para a plataforma controlar e garantir que todas as aplicações geradas estejam blindadas contra ataques.

Onde treinar

O Hacking Club [9] é uma plataforma de treinamento e formação de profissionais em cibersegurança. A máquina Anomaly simula um servidor com a vulnerabilidade tratada nesse post e pode ser usada para reforçar os conhecimentos apresentados.

Prevenção

A segurança nunca deve depender da ocultação das chaves públicas. É natural que a anonKey seja de conhecimento público, então para proteger a aplicação de ataques como o demonstrado neste post, devem ser configuradas permissões para o acesso mínimo absoluto. As formas de proteger esses endpoints envolvem alguns possíveis controles:

Verificação de Autenticação dentro da Função (RPC)

Validar o papel (role) do usuário dentro do código da função SQL. O Supabase fornece funções auxiliares para identificar se o usuário está autenticado, por exemplo, adicionar auth.role() = ‘authenticated’ para garantir que apenas usuários logados executem a lógica.

RLS

Adicionar a diretiva TO authenticated em cada política das tabelas para dados que não devem ser públicos. Se as RPCs forem definidas como SECURITY INVOKER (o padrão), ela respeitará as políticas de RLS das tabelas que ela acessa.

Revogação de Permissões de Execução

Por padrão, no Supabase, funções no esquema public podem ser executadas por usuários anônimos e autenticados. Isso pode ser restringido por SQL através do comando para revogar a permissão de execução do papel anon para uma função específica: REVOKE EXECUTE ON FUNCTION <nome_da_funcao>() FROM anon. Isso garante que o endpoint retorne um erro de autorização imediatamente se a anonKey for utilizada.

Edge Functions para Lógica Sensível

Para operações que exigem segurança máxima e não devem ser expostas diretamente via API REST de banco de dados, podem ser utilizadas as Edge Functions. Elas são funções do lado do servidor que permitem implementar validações personalizadas antes de interagir com o banco de dados, oferecendo uma camada extra de isolamento. Para implementar, no painel do Supabase, dentro do editor de SQL, é possível gerenciar essas permissões. Através da interface do Lovable, é possível simplesmente pedir via chat (prompt): “Altere a função RPC [nome] para que apenas usuários autenticados possam executá-la”, e a ferramenta aplicará as alterações necessárias no banco de dados.

Conclusão

Arquiteturas baseadas em Supabase e outros modelos de Backend-as-a-Service exigem uma mudança importante de mentalidade: nesse tipo de arquitetura, o banco de dados deixa de ser apenas um componente interno e passa a atuar como a primeira e a última linha de defesa da aplicação. Quando políticas de acesso não são definidas corretamente, a própria infraestrutura que deveria proteger os dados pode acabar expondo-os diretamente por meio de APIs públicas.

A ferramenta Chupabase foi desenvolvida justamente para demonstrar esse risco na prática. Ao reconstruir endpoints da aplicação a partir do bundle JavaScript e testar o acesso utilizando a role pública, ela permite validar rapidamente se o backend está devidamente protegido ou se permissões indevidas estão permitindo acesso não autorizado aos dados.

Para reduzir essa superfície de ataque, algumas práticas são fundamentais:

Schema Protection: mover tabelas críticas para schemas fora do public ou restringir drasticamente as permissões de uso do schema para a role anon.
RLS Everywhere: habilitar Row-Level Security em todas as tabelas e utilizar ALTER TABLE name FORCE ROW LEVEL SECURITY; para garantir que as políticas não sejam ignoradas em sessões de API.
Princípio do Privilégio Mínimo: a anonKey deve possuir o mínimo possível de permissões, idealmente nenhuma. O acesso aos dados deve ser controlado por políticas baseadas em auth.uid() ou auth.jwt().
Validação de RPC e Functions: nunca assumir que uma função é segura apenas por estar escondida no bundle JavaScript. A verificação do JWT deve ocorrer explicitamente dentro da lógica da função.
Monitoramento de Bundles: auditar regularmente o que o processo de build expõe através do Service Worker e dos assets de produção, utilizando ferramentas como o próprio Chupabase.

No folclore latino-americano, histórias sobre o Chupacabra fizeram muitos criadores reforçarem cercas e vigiarem melhor seus rebanhos. O medo ajudou a melhorar a proteção dos animais.

Com aplicações modernas, a lógica deveria ser semelhante. A possibilidade de exploração por atacantes deveria motivar desenvolvedores a revisar permissões, validar autenticação e proteger adequadamente seus dados.

Se tudo estiver configurado corretamente, a Chupabase encontrará apenas respostas 401 e 403. Caso contrário… o chupacabra vai jantar seu banco de dados.