Chave privilegiada no frontend
Chaves service-role e secret ignoram RLS e nunca devem chegar ao navegador.
Verificações do Supabase
Verifique a fronteira do Supabase alcançada pelos usuários
A BoringSec diferencia chaves públicas de segredos privilegiados e usa sondas limitadas de leitura quando o projeto e a chave pública são verificáveis.
Use após mudanças em políticas, armazenamento, autenticação ou ambiente e antes de expor dados reais.
Escaneie apenas sistemas próprios ou autorizados. Os mecanismos profundos exigem autorização verificada e podem não estar disponíveis para um alvo.
relatório / achado de exemploIlustrativo
Crítico
Estrutura de exemplo do relatório
Solicitação anônima pode ler linhas
- Evidência
- Uma leitura limitada com contexto público retornou dados; a evidência é minimizada.
- O que significa
- O caminho observado indica RLS ausente ou ampla demais.
- Corrigir e verificar
- Ative RLS, aplique menor privilégio, revise a exposição e verifique.
Este achado é ilustrativo, não um resultado da sua aplicação. Relatórios reais mostram o scanner, o estado da evidência e os limites de cobertura do alvo.
Caminhos de risco comuns
O que merece análise mais cuidadosa
São padrões relevantes para projetos Supabase, não afirmações sobre todos eles. Um achado só aparece quando o scanner fornece evidência.
Leitura anônima de linhas
Políticas ausentes ou amplas podem expor dados pela API pública.
Armazenamento público ou enumerável
Políticas de buckets e objetos podem expor arquivos não vinculados.
Cobertura honesta
O que cada superfície de varredura pode provar
URL, código conectado e mecanismos profundos autorizados respondem perguntas diferentes. A BoringSec separa as fontes e mostra estados parciais, bloqueados e indisponíveis.
Ler a metodologia pública (em inglês)Classificação de projeto e chaves
Detecta URLs suportadas e diferencia chaves públicas de formatos privilegiados.
Sondas limitadas de tabelas
Usa leituras com limite e relata resultados restritos, vulneráveis, não verificados ou ignorados.
Postura do armazenamento
Verifica listagens limitadas sem enviar, alterar ou excluir objetos.
Incerteza explícita
Falhas, limites e rejeições reduzem a cobertura em vez de gerar aprovação.
Da observação à verificação
Um relatório voltado à próxima ação
- 01
Observar
Inspecione a resposta pública e inicie os mecanismos de segundo plano aplicáveis.
- 02
Verificar evidências
Veja o que foi observado, por qual scanner e com qual confiança.
- 03
Corrigir com contexto
Use uma correção concreta e o contexto relevante para RLS do Supabase.
- 04
Testar novamente
Execute uma nova avaliação; o monitoramento detecta regressões posteriores.
Perguntas antes de escanear
Uma chave anon do Supabase é segredo vazado?
Não. Chaves públicas são esperadas; RLS e políticas de armazenamento são a fronteira.
A varredura modifica o banco?
Não. As sondas são limitadas e somente leitura; não inserem, atualizam ou excluem.
Ela prova todas as políticas RLS?
Não. Prova apenas caminhos observados; funções autenticadas exigem contexto autorizado.
Um resultado limpo prova que o Supabase está seguro?
Não. Cobertura parcial, bloqueada ou indisponível permanece visível.
Verifique a aplicação publicada e valide cada correção
Comece pela URL pública. Adicione código ou contexto autenticado apenas quando quiser ampliar a cobertura.
Iniciar varredura de segurança