ScanYourSite

Veja o que seu projeto Supabase mostra para o mundo

A anon key foi feita para ser pública. A proteção é o Row Level Security — e a única chave que o ignora nunca pode chegar ao navegador. Verificamos as duas coisas de fora, do jeito que um atacante faria, sem tocar nos seus dados.

Grátis, sem cadastro. A análise básica faz apenas as requisições que um navegador comum faria.

Ver um relatório completo de exemplo

O que verificamos

Verifique você mesmo em cinco minutos

Tudo o que verificamos de fora você pode verificar no seu próprio painel e terminal. Faça isso só no seu próprio projeto.

  1. Liste as tabelas sem Row Level Security

    Painel do Supabase → SQL Editor. Qualquer tabela pública com rowsecurity = false pode ser lida pela chave anon se as permissões (grants) padrão estiverem valendo. O Security Advisor (Advisors → Security) mostra a mesma lista.

    select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

  2. Teste como um estranho

    Use a chave anon do seu site — a mesma que todo visitante tem. Se isto retornar linhas, retorna para qualquer pessoa também.

    curl 'https://<project>.supabase.co/rest/v1/<table>?select=*&limit=1' \
  -H "apikey: <anon key>" \
  -H "Authorization: Bearer <anon key>"

  3. Garanta que a chave secreta nunca chegou ao navegador

    No seu site no ar, abra o DevTools e procure em todos os arquivos carregados (Cmd/Ctrl + Option/Alt + F) por service_role e sb_secret_. Qualquer resultado significa: gere uma nova chave em Project Settings → API e depois mova esse código para uma Edge Function.

  4. Ative o RLS e adicione uma política

    Ativar o RLS sem uma política bloqueia tudo — adicione uma que combine com o jeito como a tabela é usada. Para uma tabela de perfis de usuário:

    alter table public.profiles enable row level security;

create policy "read own profile"
on public.profiles for select
using (auth.uid() = id);

Uma correção que sua IA pode aplicar

O prompt do relatório nomeia as tabelas e o problema exato, e pede à sua IA que ative o RLS com políticas que combinem com a forma como o app usa cada tabela.

Corrija estes problemas em app.example.com.

1. A tabela "profiles" retorna 1.240 linhas para a anon key.
   Ative o Row Level Security nela e adicione uma política para que cada usuário só possa fazer select da própria linha (auth.uid() = id).

2. A tabela "orders" retorna 87 linhas para a anon key.
   Ative o RLS; permita select só para o dono do pedido.

Ao terminar, verifique de novo: https://scanyoursite.app/pt?check=app.example.com

Tabela nova, risco novo

Toda migration pode adicionar uma tabela sem política. Com o Pro, a verificação de tabelas roda em toda análise agendada, e você fica sabendo de uma tabela recém-aberta no mesmo dia.

Ver planos

Perguntas

Por que preciso confirmar meu domínio para a verificação de tabelas?

Consultar um banco de dados vai além do que um navegador faz em uma página, então só fazemos isso para o dono. A confirmação é feita com um registro DNS, um arquivo ou uma meta tag.

Vocês guardam meus dados?

Não. Contamos as linhas com uma requisição HEAD e guardamos só o número e o nome da tabela.

A anon key é um vazamento?

Não. Ela é pública por design. Mostramos como informativo, não como problema.

Para vibe coders

Cole sua URL. Receba a lista em cerca de um minuto.

Cada achado vem com o que ele significa para você e como corrigir — ou com um prompt que sua ferramenta de IA pode aplicar.

Grátis, sem cadastro. A análise básica faz apenas as requisições que um navegador comum faria.