Antes de lançar um app feito no Lovable: checklist de segurança

O Lovable leva um app da ideia ao produto funcionando mais rápido do que qualquer coisa antes dele. Ele também ajuda na segurança: procura problemas comuns no banco antes de cada publicação e oferece uma revisão mais profunda do código feita por IA. Use as duas. Elas pegam muita coisa, e o próprio Lovable diz que não conseguem garantir que um app é seguro.

A lacuna está no que um scanner não tem como saber: quais dados do seu app são privados, quem deve poder fazer o quê e o que acontece quando alguém usa o app de um jeito que você não planejou. Este checklist cobre essa parte. Passe por ele uma vez antes do lançamento, e de novo depois de qualquer mudança grande.

Banco de dados #

1. O Row Level Security está ligado em todas as tabelas. Tabelas criadas por SQL, que é como as ferramentas de IA as criam, não vêm com ele ligado. A verificação de 10 minutos no Supabase mostra como listá-las.

2. Nenhuma tabela privada tem uma regra que libera tudo. Uma regra using (true) em profiles, orders ou messages significa que qualquer pessoa as lê, com RLS ou sem.

3. Usuários não conseguem se promover. Se a tabela profiles tem uma coluna role, is_admin ou plan e os usuários podem atualizar a própria linha, eles também podem mudar essa coluna, pelo navegador, numa única requisição. Guarde papéis e status de pagamento numa tabela separada que só o código de servidor grava, ou limite quais colunas a regra de atualização permite.

select table_name, column_name
from information_schema.columns
where table_schema = 'public'
  and column_name ~* '(role|admin|plan|credits|verified|status)';

Compare o resultado com as suas regras de update da verificação de RLS.

Chaves #

4. Nenhuma chave secreta no frontend. Procure sb_secret_ e service_role no app publicado. Se encontrar, siga o plano da primeira hora para uma chave secreta vazada.

5. Nenhum segredo de terceiros no frontend também. Chaves de IA, de pagamento e de e-mail ficam em funções de servidor. Procure sk-, sk_live, re_ e confira toda variável de ambiente que começa com VITE_. Como levá-las para uma função no servidor.

Storage #

6. Arquivos pessoais ficam em buckets privados. Avatares podem ser públicos; documentos, notas fiscais e contratos, não. Cada usuário deve alcançar só a própria pasta. A verificação do Storage.

7. Os buckets têm limites de tamanho e de tipo. Sem isso, qualquer pessoa autorizada a enviar pode guardar qualquer coisa, por sua conta.

Login #

8. A confirmação de e-mail está ligada, a menos que haja um motivo para desligá-la. Sem ela, alguém pode se cadastrar com o endereço de outra pessoa.

9. As URLs de redirecionamento se limitam aos seus domínios. No Supabase, em Authentication → URL Configuration, defina a Site URL como o seu domínio de produção e liste só os endereços que você usa. Remova localhost e endereços de preview de que não precisa mais.

10. O cadastro está fechado se o app é só para convidados. Uma ferramenta interna com cadastro aberto é um app público.

11. Toda página de administração confere o papel no servidor. Esconder um botão não é controle de acesso. Se uma página ou ação é para administradores, os dados por trás dela precisam estar protegidos por uma regra ou por uma função de servidor que confere o papel, para que chamar a API diretamente não retorne nada.

Pagamentos e funções #

12. Os preços são decididos no servidor. O navegador diz o que está sendo comprado; o servidor busca o preço. Uma função que aceita um valor vindo do navegador, cedo ou tarde, vai receber 0.01.

13. Os webhooks de pagamento são verificados pela assinatura. Um endpoint de webhook que confia em qualquer requisição deixa qualquer pessoa marcar um pedido como pago.

14. As Edge Functions conferem quem está chamando. Toda função que lê dados, gasta dinheiro ou envia e-mail deve verificar o usuário e validar a entrada. Uma função aberta desfaz todas as regras do seu banco.

Recuperação #

15. Você sabe como restauraria os dados de ontem. Abra Database → Backups no Supabase e veja o que o seu plano inclui; nos planos mais baixos pode ser pouco ou nada. Uma edição errada da IA ou uma migração ruim pode apagar uma tabela. Se os dados importam, tenha backups que você já restaurou de verdade uma vez, num projeto de teste.

Depois do lançamento #

A segurança não fica pronta para sempre. Cada novo prompt pode criar uma tabela sem regras, uma chave no lugar errado ou uma função que confia no navegador. Dois hábitos ajudam:

• Rode o scan do Lovable e o Security Advisor do Supabase depois de cada mudança importante, não só no lançamento.
• Peça à IA, em palavras simples, para explicar as regras de RLS e as funções que acabou de criar. Se a explicação não bater com o que você quer, é hora de olhar mais de perto.

Se quiser um segundo par de olhos antes do lançamento, o nosso Security Check gratuito passa por esses pontos de fora, sem alterar nada, e envia por escrito os problemas mais graves em até 48 horas. Quando algo precisa de correção, o Security Fix cuida disso por um preço fixo, informado antes de qualquer trabalho começar.