// docs / baas security / umbrella scanner
Scanner de configurações incorretas de BaaS: encontre caminhos de dados públicos antes dos usuários
Provedores Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — todos falham em segurança da mesma forma: a plataforma entrega padrões sensatos, o desenvolvedor (ou a ferramenta de codificação com IA) pega um atalho e um caminho público abre entre um atacante não autenticado e dados de cliente. Um scanner de configurações incorretas de BaaS é a única ferramenta que sonda esse caminho de fora do jeito que um atacante faria. Este artigo mapeia as cinco classes recorrentes de configuração incorreta, explica como a varredura BaaS guarda-chuva do FixVibe funciona, compara os quatro principais provedores e contrasta o scanner ciente de BaaS contra ferramentas DAST gerais.
Por que configurações incorretas de BaaS têm uma forma recorrente
Toda plataforma BaaS segue a mesma arquitetura: um backend gerenciado com um SDK cliente fino que fala com ele do navegador. O cliente voltado ao navegador precisa de alguma credencial — uma chave anon, uma chave publicável, um ID de projeto Firebase — para se identificar ao backend. Essa credencial é intencionalmente pública; a segurança da arquitetura repousa em controles de acesso em nível de plataforma (RLS, regras, allowlists) fazendo seu trabalho.
Ferramentas de codificação com IA constroem sobre essa arquitetura sem internalizar a camada de controles de plataforma. Cabeiam o SDK cliente corretamente, aceitam as regras permissivas padrão da plataforma (que existem para amizade-com-tutoriais) e publicam. A forma recorrente é: credencial pública + regra permissiva padrão + override ausente = exposição de dados. As cinco classes de configuração incorreta abaixo são todas variantes dessa forma.
As cinco classes recorrentes de configuração incorreta
Estas aparecem em cada provedor BaaS. Uma varredura completa cobre todas as cinco contra cada provedor em uso:
Classe 1: chave errada no bundle do navegador
O navegador entrega a chave secret/admin (Supabase service_role, chave privada do SDK Admin Firebase, Clerk sk_*, client secret Auth0) em vez do equivalente público/anon. O navegador se torna um cliente admin sem restrições. Coberto pela verificação de segredos em bundle do FixVibe.
Classe 2: camada de controle de acesso desabilitada ou permissiva
RLS está desligado, regras do Firebase são if true, a lista de callbacks do Auth0 tem wildcard. A credencial no navegador é a correta — mas a fronteira em nível de plataforma que era para restringi-la não está fazendo seu trabalho.
Classe 3: leituras anônimas de recursos sensíveis
Coleções Firestore legíveis anonimamente, buckets Supabase Storage listáveis anonimamente, API de gerenciamento Auth0 acessível anonimamente. A varredura pergunta: "sem credenciais, o que posso ler?"
Classe 4: artefatos de modo de teste em produção
Chaves de teste (pk_test_*, sb_test_*) em um deploy de produção; apps Firebase em modo dev alcançáveis do domínio live; aplicações Auth0 de tenant de teste com configurações mais fracas que produção. A varredura compara as chaves de runtime contra os prefixos esperados de produção.
Classe 5: verificação de assinatura de webhook ausente
Webhooks do Clerk, Stripe e Supabase todos assinam seus payloads. Um handler que não verifica a assinatura é uma primitiva de escrita em banco para qualquer atacante que adivinhe a URL. Detectada via formato da resposta — uma requisição não assinada que recebe 200 significa que a verificação foi pulada.
Como funciona a varredura BaaS guarda-chuva do FixVibe
A fase BaaS do FixVibe roda em três estágios, cada um produzindo achados distintos:
- <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
- Estágio 2 — sondagens específicas de provedor. Para cada provedor detectado, o scanner roda a verificação específica do provedor:
baas.supabase-rlssonda PostgREST;baas.firebase-rulessonda Firestore + RTDB + Storage;baas.clerk-auth0valida o prefixo de chaves no bundle; a verificação de segredos em bundle valida que nenhuma credencial de nível de serviço vazou. Cada sondagem roda independentemente — um achado Supabase não bloqueia a varredura Firebase. - Estágio 3 — correlação entre provedores. O scanner cruza achados. Uma chave de role de serviço Supabase vazada ao lado de RLS ausente é mais grave que qualquer achado sozinho — o relatório destaca isso. Múltiplos provedores de identidade (Clerk + Auth0 + auth customizada) no mesmo app é um achado estrutural marcado para revisão.
Cada sondagem é passiva: no máximo uma leitura anônima por recurso, com formato da resposta registrado mas conteúdo de linhas nunca paginado ou armazenado. Sondagens de escrita e modificação são protegidas atrás de verificação de propriedade de domínio — nunca rodam contra alvos não verificados.
O que o scanner encontra por provedor
Cada provedor BaaS tem uma superfície diferente e uma estratégia de varredura diferente. Aqui está o que está coberto:
- Supabase: RLS ausente em tabelas, buckets de storage listáveis anonimamente, JWT
service_rolevazado ou chavesb_secret_*no bundle, schemas expostos via listagem OpenAPI anônima. Veja Scanner de RLS Supabase e Checklist de Storage. - Firebase: regras
if trueem Firestore, Realtime Database e Cloud Storage; buckets de Storage listáveis anonimamente; ausência de App Check. Veja Scanner de regras Firebase e Explicador da regra if-true. - Clerk: chaves secretas
sk_*no bundle,pk_test_*em produção, verificação de assinatura de webhook ausente, origens permitidas com wildcard. Veja Checklist Clerk. - Auth0: client secrets no bundle, grant Implicit habilitado, URLs callback / logout com wildcard, PKCE ausente em SPAs. Veja Checklist Auth0.
Como um scanner BaaS se compara a ferramentas DAST e SAST gerais
Um scanner ciente de BaaS faz trabalho específico que outras ferramentas não fazem. A comparação:
| Aspecto | FixVibe (DAST ciente de BaaS) | DAST geral (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| Cobertura BaaS | Verificações nativas para Supabase, Firebase, Clerk, Auth0, Appwrite | Crawl web genérico; sem sondagens específicas de provedor | Análise estática apenas do repo; sem validação em produção |
| Tempo de configuração | URL → rodar → resultados em 60 segundos | Horas: configurar spider, auth, escopo | Dia: integrar no CI do repo |
| O que prova | Exposição em runtime de produção com evidência em nível HTTP | Vulns de app web (XSS, SQLi); BaaS via config manual | Padrões de código que podem ou não ser publicados |
| Inspeção de bundle JavaScript | Decodifica JWTs, casa prefixos de secret, percorre chunks | Limitada — apenas grep baseado em strings | Sim, mas apenas no lado do repo, não publicado |
| Varredura contínua | Mensal / no deploy via API + MCP | Manual; configure o agendamento você mesmo | Por commit (bom para código, cego ao runtime) |
| Preço para solo / equipe pequena | Plano gratuito; pago a partir de $19/mês | Burp Pro $499/ano; ZAP gratuito mas com muitos falsos positivos | Snyk gratuito / Semgrep gratuito; planos pagos a partir de $25/dev |
Escopo honesto: o que este scanner não substitui
Um scanner DAST ciente de BaaS é uma ferramenta focada, não um programa de segurança completo. Ele não:
- Substitui SAST ou SCA. Análise estática encontra CVEs de dependências (Snyk, Semgrep) e vulnerabilidades em nível de código (SonarQube) que um scanner DAST não consegue. Rode ambos.
- Substitui testes de penetração manuais. Um pentester humano encontra falhas de lógica de negócio, casos extremos de autorização e vulnerabilidades encadeadas que nenhum scanner consegue. Contrate um pentester antes de um lançamento grande ou auditoria de conformidade.
- Audita seu código ou repo em busca de segredos no histórico git. A verificação de segredos em bundle cobre o que está publicado atualmente, não o que foi historicamente commitado. Use
git-secretsougitleakspara higiene de repo. - Cobre serviços de backend não-BaaS. Se seu app usa um backend customizado (Express, Rails, Django, FastAPI), o FixVibe varre sua superfície HTTP mas não sonda o banco ou infraestrutura por trás. Esse é território de DAST + SAST geral.
Perguntas frequentes
A varredura guarda-chuva funciona se meu app usa dois provedores BaaS (p. ex., Supabase + Clerk)?
Sim — fingerprinting de provedor e sondagens por provedor são independentes. O scanner detecta ambos, roda ambas as suítes de verificação e reporta correlações entre provedores (p. ex., um template JWT Supabase do Clerk que envia email como claim junto com RLS ausente).
Como isso difere de rodar Burp Suite Pro contra meu app?
Burp é uma bancada DAST geral. Out of the box, Burp não sabe o que é PostgREST, Firestore ou o caminho de callback Auth0 — você precisa configurar manualmente escopo, escrever extensões e interpretar respostas. FixVibe vem com sondagens BaaS embutidas e formatação de evidência em formato BaaS. Burp ganha em cobertura geral de app web (XSS, SQLi, lógica de negócio); FixVibe ganha em achados específicos de BaaS.
E sobre App Check (Firebase) ou attestation (Apple / Google)?
App Check faz varreduras externas oportunistas retornarem 403 em cada sondagem — o resultado correto para um bot malicioso. Uma varredura do FixVibe de um cliente sem attestation se comporta da mesma forma. Se você tem App Check habilitado e o FixVibe ainda reporta achados, significa que suas regras estão abertas também para clientes com attestation, que é o risco real. App Check + regras corretas é o padrão de defesa em profundidade.
O scanner pode verificar minha correção?
Sim — rode de novo após aplicar a correção. Os IDs de verificação (p. ex., baas.supabase-rls) são estáveis entre execuções, então você pode diffar achados: um achado que era open na execução 1 e ausente na execução 2 é prova de que a correção funcionou.
Próximos passos
Rode uma varredura gratuita do FixVibe contra sua URL de produção — as verificações de fase BaaS estão em todos os planos, incluindo o gratuito. Para mergulhos específicos por provedor, os artigos individuais desta seção cobrem cada provedor em detalhe: RLS Supabase, Exposição de chave de serviço Supabase, Storage Supabase, Regras Firebase, Firebase if-true, Clerk, e Auth0.