// 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
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
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:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- 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 → run → results usually in under a minute | 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 | Every shipped chunk, with provider-aware key detection | 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 | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
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?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
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.