Teste de segurança para apps feitos no Lovable

Apps do Lovable costumam chegar funcionando e com o banco acessível pela chave pública do front. Testamos a API como um atacante faria e entregamos evidência, não opinião.

Em uma frase: App feito no Lovable costuma falhar no isolamento do banco: a chave pública está no front e a API devolve a tabela inteira.

Por que isso acontece no Lovable

O template do Lovable otimiza para a tela funcionar rápido. O banco nasce acessível pela chave pública e a política de isolamento fica para depois — quando alguém lembra que ela existe.

O que costuma ficar aberto

1. Chave de administrador no bundle. A credencial que ignora as regras vai para o JavaScript público.
2. Banco sem isolamento por registro. A API devolve a tabela inteira para a chave anônima.
3. Rota sem autenticação. O botão é escondido, mas o endpoint responde para qualquer chamada.
4. CORS permissivo com credenciais. Origem hostil consegue ler resposta autenticada.
5. Endpoint de IA sem limite. Consumo ilimitado de tokens na sua conta.

Exemplo real

Leitura de tabela inteira com a chave do front

GET /rest/v1/profiles?select=* HTTP/2
apikey: <chave pública do app>

200 · 12.481 linhas · e-mails e telefones

A chave anônima é pública por design. O que falta é a política que decide quais linhas cada usuário vê.

O que testamos

Vinte verificações: OWASP API Top 10 aplicado ao stack, mais configuração de banco, segredos no bundle, sourcemaps, CORS, rotas de debug e limite de uso. Onze rodam automatizadas; as demais entram na revisão manual de autorização.

Além do banco, o teste cobre chave administrativa no bundle, sourcemaps, CORS com credenciais, rotas de debug e o limite de uso do endpoint de IA.

Como o laudo trata esse achado

A evidência entra com método, caminho e resposta redigida; a severidade considera o que um atacante obtém sem credencial; a correção é escrita para o seu stack, não como aviso genérico. O que não conseguimos reproduzir fica fora do laudo.

Como testar em 10 minutos

1. Abra o DevTools e copie a chave usada pelo app
2. Consulte uma tabela que só você deveria ver
3. Chame a rota de dados sem cookie
4. Compare o retorno com o que a tela mostra

O que o teste não cobre

• Não cobre lógica de negócio
• Não substitui revisão de código
• Não garante ausência de falhas

Como funciona

1. Call de 15 minutos para fechar escopo, alvo e autorização.
2. Proposta com valor e prazo em 24h.
3. Teste em 48h, com laudo e correção escrita.

Sinais de que você precisa

• A chave pública do banco aparece no JavaScript.
• A tela exige login, mas a API do banco responde sem sessão.
• Ninguém testou uma tabela com a chave anônima.

Checklist rápido

• Procure a chave pública no bundle
• Consulte uma tabela com ela
• Chame /rest/v1 sem sessão
• Confira sourcemaps
• Dispare 20 requisições no login
• Teste CORS com Origin hostil

O que fazer agora

• Ligar isolamento por registro em todas as tabelas expostas.
• Remover a chave de administrador do bundle e rotacionar.
• Testar cada tabela com a chave pública, não só a tela.

Veja também todas as verificações e o checklist de 12 itens.