← todos os posts
Segurança 6 min de leitura

"Login que aparece e login que protege: a diferença que o Security Scan não pega"

A tela pede senha e o verificador fica verde. Os três lugares onde a checagem de login pode morar, qual deles o scan lê e o mapa pra fazer hoje.

"Autenticação feita só no cliente, sem validação no backend."

Está numa lista de falhas comuns em app feito com IA que circulou entre programadores brasileiros. Traduzindo: autenticação é o login, o app conferindo quem você é. Cliente é o seu navegador, a tela. Backend é a parte de trás: o servidor e o banco de dados, onde o dado mora de verdade. A frase inteira quer dizer: o app pede senha na tela, mas atrás da tela ninguém confere nada.

De fora, as duas versões são idênticas. Senha errada não entra, botão de sair funciona, o verificador da plataforma fica verde. Você publica.

Não é desatenção sua

Esse defeito não dá sintoma. As duas versões mostram a mesma tela pra quem usa do jeito certo, e você nunca usa o seu app do jeito errado.

E o verificador automático não foi feito pra pegar todo caso. Em 2025, o engenheiro Matt Palmer escreveu que o scanner do Lovable "só checa se existe alguma regra, não se ela está correta". Isso mudou: conferi a documentação desta semana, e o scan rápido de hoje, o que roda sozinho ao publicar, também acusa "regras que deixam todo mundo passar". Melhorou.

Só que a própria Lovable, no anúncio de junho de 2026, escreve o limite com todas as letras: o scan básico "não analisa o código do seu app em busca de falhas de lógica". Ele lê o banco. Não lê a tela. Se a única checagem de login do seu app mora na tela, o scan rápido não tem onde olhar. E a documentação fecha: essas ferramentas "não substituem uma revisão de segurança completa".

O mapa: três lugares onde o login pode morar

1. Na tela — o porteiro de condomínio sem muro. O app esconde o botão de admin de quem não é admin, e manda pra página de login quem não entrou. É só a guarita: quem chega por outro caminho (um endereço digitado direto, um pedido feito fora da tela) passa pelo gramado. Aparece. Não protege. O scan rápido não lê esse lugar.

2. No servidor — o porteiro que confere antes de entregar. Uma função no servidor recebe o pedido, olha quem está logado e só devolve o dado se for dele. Protege, se existir em todo caminho que entrega dado.

3. No banco — a regra por linha. O próprio banco recusa entregar a linha de quem não é o dono, venha o pedido de onde vier. No Supabase (o banco por trás do Lovable e de muita outra ferramenta), isso se chama RLS, regra por linha. Protege, e é o único dos três que o scan rápido lê.

E tem um quarto lugar, que é armadilha: onde fica guardado quem é admin. Se o app anota "essa pessoa é administradora" num campo que a própria pessoa consegue editar, o login protege, mas a pessoa se promove sozinha. A documentação do Supabase avisa sobre um desses campos, o de metadados do usuário: ele pode ser alterado pelo próprio usuário logado e "não é um bom lugar para guardar dado de autorização". Autorização é a outra metade do login: não quem é você, mas o que você pode ver.

Resumo em uma tabela:

Onde mora a checagem Protege? O scan rápido vê?
Só na tela Não Não
No servidor Sim, se cobre todo caminho Não
No banco (regra por linha) Sim Sim, se a regra existe e não libera geral
"É admin" num campo que o usuário edita Não Não necessariamente

O que fazer hoje: o mapa do seu app

Trinta minutos. Uma folha com três colunas: tela, onde mora a checagem, ok?

Passo 1. Liste as telas que mostram dado de cliente. Lista de pedidos, ficha do cliente, painel, relatório, exportar. Uma por linha.

Passo 2. Peça o mapa pra IA, nessas palavras:

"Para cada uma destas telas: [cole a lista]. Me diga onde mora a checagem de quem pode ver o dado: só na tela, numa função do servidor, ou numa regra do banco. Mostre o nome do arquivo ou da regra. Diga também onde está guardado quem é administrador e se o próprio usuário consegue alterar esse campo. Não mude nada, só me responda."

O "não mude nada" é de propósito: hoje você quer o mapa, não um conserto.

Passo 3. Marque a coluna "ok?". Linha que só tem "tela" ganha um ✗. Admin guardado em campo que o usuário edita ganha um ✗. Resposta sem nome de arquivo ou de regra também: não é mapa, é opinião.

Passo 4. Se você usa Lovable, rode o scan profundo. Ele não roda sozinho: na tela de segurança do projeto (Security), clique em "Run deep scan". A documentação diz que rodar é de graça; consertar o que ele achar é que gasta crédito, depois de dez consertos grátis. Ele revisa o código, inclusive controle de acesso, que o rápido não olha. Compare com a sua folha.

Passo 5. Confira na prática o que a folha diz. Mapa da IA também é relato. Pra cada ✓, o teste das duas contas prova se a regra segura um cliente longe do dado do outro, e o teste da janela anônima prova se alguém sem login nenhum vê alguma coisa.

Achou ✗? Um pedido por linha: "a tela X só checa o login na tela; crie a regra por linha no banco pra essa tabela". Depois, refaça o teste daquela linha.

Onde isso se encaixa

"Login protege ou só aparece?" é uma das dez perguntas do checklist que eu uso pra separar protótipo de produto. É a letra D do ciclo, Definir: antes de pedir segurança, saber em qual dos três lugares ela precisa estar. A folha que você fez hoje é isso.

E ela é uma parede de várias. Pra regra existir, o banco precisa estar numa conta sua. Pra corrigir sem medo, precisa de ponto de retorno. Pra saber se a regra está certa, e não só presente, precisa ler o que ela diz. Cada uma tem seu teste, e elas têm ordem.

Fontes