Cinco mil apps que perdem dados

O que é e porque importa

O título do vídeo vem das notícias. Segundo uma análise noticiada pela Axios (maio de 2026), de cerca de 380 000 apps publicadas com ferramentas de IA, cerca de 5000 expunham dados sensíveis. E a TechCrunch (setembro de 2026): a empresa UpGuard encontrou cerca de 16 000 bases de dados no Supabase com dados pessoais acessíveis. Quando leio notícias assim, só me interessa uma pergunta: a minha está entre elas? Ao usar a app não vês, porque com sessão iniciada os dados chegam-te como devem. Só sabes se experimentares.

O mecanismo, em resumo. Muitas apps feitas com IA falam diretamente com a base de dados, tipo Supabase, a partir do browser ou do telemóvel. Para isso levam consigo o endereço do projeto e uma chave pública, que qualquer pessoa pode ver. Está certo assim: o que protege os dados não é a chave, são as regras na base de dados. No Supabase chamam-se Row Level Security. Se faltarem, essa chave abre as tabelas a toda a gente.

Já falei disto no guia PORTA (strikt.fit/porta), com os detalhes sobre Supabase, Firebase e as duas chaves. Aqui está a versão para fazer agora: duas provas de um minuto, o prompt que fecha e volta a testar, e como ler o antes e o depois.

Só na tua própria app

Este teste fazes na tua app e na tua base de dados, com contas de teste. Nunca na app de outra pessoa, nem sequer para ver se está entre essas cinco mil: ler dados sem autorização pode ser crime, mesmo que a porta esteja aberta. Se achas que uma app que não é tua está exposta, avisa quem a gere.

1. Sem login

A primeira prova responde a uma pergunta: o que vê alguém que não tem conta nenhuma? Demora um minuto.

1. Abre a tua app numa janela anónima, sem entrar. Assim o browser não tem a tua sessão e és um visitante qualquer.
2. Botão direito > Inspecionar > Rede (Network), depois recarrega a página.
3. Encontra um pedido que vá para .supabase.co e clica nele. Aí vês o endereço do projeto e a chave pública (publishable, ou «anon» nos projetos mais antigos). É normal vê-la: foi feita para estar na app.

Depois abre um terminal e corre esta linha, só com esses dois dados. Põe o teu projeto, a tua chave e o nome de uma das tuas tabelas:

curl "https://O-TEU-PROJETO.supabase.co/rest/v1/NOME_TABELA?select=*" -H "apikey: CHAVE_PUBLICA"

Experimenta-a em cada tabela com dados de pessoas: perfis, mensagens, encomendas, emails. E fá-lo em tabelas que tenham mesmo dados, porque uma tabela vazia responde [] mesmo que esteja aberta: confirma antes no painel do Supabase. Se voltarem linhas, qualquer pessoa as pode ler. Se uma tabela cheia devolver [] ou um erro de permissão, essa tabela não responde a quem passa.

2. Como utilizador A, os dados de B

A segunda prova é a que mais vezes se salta. A porta pode estar fechada a quem não fez login e aberta a qualquer pessoa que tenha entrado. Mais um minuto.

1. Cria duas contas de teste, A e B.
2. Com cada uma guarda alguns dados: um perfil, uma nota, uma encomenda.
3. Entra como A e tenta abrir as linhas de B, por exemplo mudando o id no pedido ou no endereço da página.

Se as vires, as regras não existem. Ou existem mas dizem «quem fez login lê tudo», o que não chega para dados pessoais: o controlo certo é sobre quem é o dono da linha.

3. O prompt para o Claude Code

Quando sabes o que está aberto, mandas fechar. Abre o Claude Code na pasta do projeto e cola isto:

Verifica cada tabela da minha base de dados Supabase: diz-me se tem a Row Level Security ativa e que regras (policies) tem. Onde faltar, ativa-a e escreve as regras: cada utilizador lê, cria, altera e elimina só as suas linhas; as tabelas públicas por opção só de leitura. Nunca ponhas a chave secreta (secret ou service_role) no código da app. Depois repete o teste: sem login com a chave pública, e como utilizador A nas linhas de B. Mostra-me tabela a tabela o resultado antes e depois.

Cada parte tem um motivo. «Lê, cria, altera e elimina» porque no Supabase as regras escrevem-se para cada operação: fechar só a leitura deixa o resto aberto. «Públicas por opção» porque um catálogo pode ser lido por todos, mas tem de ser uma decisão tua, não um acaso. E «repete o teste» porque uma regra verifica-se experimentando-a, não lendo-a.

O Claude verifica o que consegue ver. Se as tabelas estão no código do projeto, por exemplo nos ficheiros de migração, encontra-as lá. Se as criaste à mão no painel do Supabase, diz-lhe tu quais são, ou faz os dois testes à mão e passa-lhe o resultado. E se o Claude Code te pedir autorização para correr um comando, lê o que vai fazer antes de dizeres que sim.

Como ler o antes e o depois

Convém-te o resultado numa forma que se leia num relance. Podes acrescentar ao prompt «numa tabela assim» e colar este modelo:

Tabela | RLS antes | RLS depois | Sem login antes | Sem login depois | A em B antes | A em B depois
perfis | não | sim | linhas | [] | linhas | nada

No fim queres ver três coisas: a Row Level Security ativa em cada tabela, nenhuma linha sem login exceto nas tabelas públicas por opção, e A sem ver nada de B. Se uma tabela não ficar assim, pergunta ao Claude porquê antes de avançares.

Duas coisas que convém saber

Mais vale fechado do que aberto

Com a Row Level Security ativa e nenhuma regra, pela chave pública não passa nada. Por isso mais vale fechado do que aberto, e depois abres só o que é preciso. Se depois da correção um ecrã deixar de carregar, não desligues a segurança: falta uma regra. Pede que acrescentem essa:

O ecrã [nome] deixou de carregar os dados desde que ativaste a Row Level Security. Descobre que regra falta e acrescenta a mais apertada que chegue. Não desatives a segurança em nenhuma tabela. Depois repete os dois testes, sem login e de A para B.

A chave secreta

A chave secreta (secret ou service_role) salta todas as regras. Fica só no servidor: nunca na app, nunca no GitHub. Se foi parar à app ou a um repositório, muda-a já no painel do Supabase. Tirá-la do código não chega: fica no histórico e com quem já a viu.

Não usas o Supabase?

Faz o mesmo teste com a tua plataforma: sem login, depois de A para B. Os nomes mudam, o conceito não. No Firebase, por exemplo, as regras chamam-se regras de segurança: o que procurar e o prompt para as verificar estão no guia PORTA.

Os erros mais comuns

• Fazer o teste com sessão iniciada. Usa uma janela anónima, senão vês os dados porque és tu.
• Testar uma só tabela. Cada tabela tem as suas regras: testa-as todas, primeiro as que têm dados de pessoas.
• Confiar num [] vindo de uma tabela vazia. Uma tabela vazia responde [] mesmo que esteja aberta: testa uma que tenha dados.
• Parar no teste sem login. Faz também o de A para B: é aí que se esconde a regra «quem fez login lê tudo».
• Desligar a Row Level Security quando um ecrã não carrega. Acrescenta a regra que falta e deixa o resto fechado.
• Confiar na correção sem voltar a testar. Repete os dois testes e vê o antes e o depois, tabela a tabela.

Checklist

• Teste sem login, em janela anónima, em cada tabela com dados de pessoas.
• Teste de A para B com duas contas de teste.
• Row Level Security ativa em cada tabela, com regras para ler, criar, alterar e eliminar.
• Tabelas públicas só de leitura, e só por opção.
• Chave secreta só no servidor, nunca na app.
• Os dois testes repetidos depois da correção, com o antes e o depois à frente.

Perguntas frequentes