// docs / baas security / umbrella scanner
Scanner de configurações incorretas de BaaS: encontre caminhos de dados públicos antes dos utilizadores
Fornecedores Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — todos falham em segurança da mesma forma: a plataforma entrega defaults sensatos, o programador (ou a ferramenta de codificação com IA) apanha 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 o varrimento BaaS guarda-chuva do FixVibe funciona, compara os quatro principais fornecedores e contrasta o scanner ciente de BaaS contra ferramentas DAST gerais.
Porque é que configurações incorretas de BaaS têm uma forma recorrente
Toda plataforma BaaS segue a mesma arquitetura: um backend gerido 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 controlos de acesso em nível de plataforma (RLS, regras, allowlists) a fazerem o seu trabalho.
Ferramentas de codificação com IA constroem sobre esta arquitetura sem internalizar a camada de controlos 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 desta forma.
As cinco classes recorrentes de configuração incorreta
Estas aparecem em cada fornecedor BaaS. Um varrimento completo cobre todas as cinco contra cada fornecedor 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 torna-se um cliente admin sem restrições. Coberto pela verificação de segredos em bundle do FixVibe.
Classe 2: camada de controlo 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á a fazer o 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 gestão Auth0 acessível anonimamente. O varrimento pergunta: "sem credenciais, o que posso ler?"
Classe 4: artefactos de modo de teste em produção
Chaves de teste (pk_test_*, sb_test_*) num 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. O varrimento 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 os seus payloads. Um handler que não verifica a assinatura é uma primitiva de escrita em base de dados para qualquer atacante que adivinhe a URL. Detetada via formato da resposta — um pedido não assinado que recebe 200 significa que a verificação foi saltada.
Como funciona o varrimento BaaS guarda-chuva do FixVibe
A fase BaaS do FixVibe corre 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 fornecedor. Para cada fornecedor detetado, o scanner corre a verificação específica do fornecedor:
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 corre independentemente — um achado Supabase não bloqueia o varrimento Firebase. - Estágio 3 — correlação entre fornecedores. 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 isto. Múltiplos fornecedores de identidade (Clerk + Auth0 + auth customizada) na mesma app é um achado estrutural marcado para revisão.
Cada sondagem é passiva: no máximo uma leitura anónima por recurso, com formato da resposta registado mas conteúdo de linhas nunca paginado ou armazenado. Sondagens de escrita e modificação estão protegidas atrás de verificação de propriedade de domínio — nunca correm contra alvos não verificados.
O que o scanner encontra por fornecedor
Cada fornecedor BaaS tem uma superfície diferente e uma estratégia de varrimento 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:
| Aspeto | 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 fornecedor | Análise estática apenas do repo; sem validação em produção |
| Tempo de configuração | URL → correr → 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 | Descodifica JWTs, casa prefixos de secret, percorre chunks | Limitada — apenas grep baseado em strings | Sim, mas apenas no lado do repo, não publicado |
| Varrimento contínuo | 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 / equipa 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. Corra 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 o 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 committado. Use
git-secretsougitleakspara higiene de repo. - Cobre serviços de backend não-BaaS. Se a sua app usa um backend customizado (Express, Rails, Django, FastAPI), o FixVibe varre a sua superfície HTTP mas não sonda a base de dados ou infraestrutura por trás. Esse é território de DAST + SAST geral.
Perguntas frequentes
O varrimento guarda-chuva funciona se a minha app usa dois fornecedores BaaS (p. ex., Supabase + Clerk)?
Sim — fingerprinting de fornecedor e sondagens por fornecedor são independentes. O scanner deteta ambos, corre ambos os conjuntos de verificação e reporta correlações entre fornecedores (p. ex., um template JWT Supabase do Clerk que envia email como claim junto com RLS ausente).
Em que é que isto difere de correr Burp Suite Pro contra a minha app?
Burp é uma bancada DAST geral. Out of the box, Burp não sabe o que é PostgREST, Firestore ou o caminho de callback Auth0 — tem de 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 varrimentos externos oportunistas devolverem 403 em cada sondagem — o resultado correto para um bot malicioso. Um varrimento do FixVibe de um cliente sem attestation comporta-se da mesma forma. Se tem App Check habilitado e o FixVibe ainda reporta achados, significa que as 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 a minha correção?
Sim — corra 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 pode comparar 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
Execute um varrimento gratuito do FixVibe contra a 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 fornecedor, os artigos individuais desta secção cobrem cada fornecedor em detalhe: RLS Supabase, Exposição de chave de serviço Supabase, Storage Supabase, Regras Firebase, Firebase if-true, Clerk, e Auth0.