// docs / baas security / umbrella scanner
Scanner de mauvaises configurations BaaS : trouvez les chemins de données publics avant les utilisateurs
Les fournisseurs Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — échouent tous en sécurité de la même façon : la plateforme livre des défauts raisonnables, le développeur (ou l'outil de codage IA) prend un raccourci, et un chemin public s'ouvre entre un attaquant non authentifié et les données client. Un scanner de mauvaises configurations BaaS est le seul outil qui sonde ce chemin depuis l'extérieur comme un attaquant le ferait. Cet article cartographie les cinq classes récurrentes de mauvaises configurations, explique comment le scan BaaS parapluie de FixVibe fonctionne, compare les quatre fournisseurs majeurs et oppose le scanner conscient du BaaS aux outils DAST généraux.
Pourquoi les mauvaises configurations BaaS ont une forme récurrente
Chaque plateforme BaaS suit la même architecture : un backend géré avec un SDK client léger qui lui parle depuis le navigateur. Le client orienté navigateur a besoin de quelques identifiants — une clé anon, une clé publiable, un ID de projet Firebase — pour s'identifier auprès du backend. Cet identifiant est intentionnellement public ; la sécurité de l'architecture repose sur les contrôles d'accès au niveau de la plateforme (RLS, règles, listes blanches) faisant leur travail.
Les outils de codage IA construisent par-dessus cette architecture sans intérioriser la couche de contrôles de la plateforme. Ils câblent le SDK client correctement, acceptent les règles permissives par défaut de la plateforme (qui existent pour la convivialité des tutoriels) et livrent. La forme récurrente est : identifiant public + règle permissive par défaut + remplacement manquant = exposition de données. Les cinq classes de mauvaises configurations ci-dessous sont toutes des variantes de cette forme.
Les cinq classes récurrentes de mauvaises configurations
Elles apparaissent chez chaque fournisseur BaaS. Un scan complet couvre les cinq contre chaque fournisseur utilisé :
Classe 1 : mauvaise clé dans le bundle navigateur
Le navigateur livre la clé secrète/admin (Supabase service_role, clé privée du SDK Admin Firebase, Clerk sk_*, client secret Auth0) au lieu de l'équivalent public/anon. Le navigateur devient un client admin sans contraintes. Couvert par le check secrets-de-bundle de FixVibe.
Classe 2 : couche de contrôle d'accès désactivée ou permissive
RLS est désactivé, les règles Firebase sont if true, la liste de callbacks Auth0 est à joker. L'identifiant dans le navigateur est le bon — mais la frontière au niveau de la plateforme qui devait le contraindre ne fait pas son travail.
Classe 3 : lectures anonymes de ressources sensibles
Collections Firestore lisibles anonymement, buckets Supabase Storage listables anonymement, API de gestion Auth0 accessible anonymement. Le scan demande : « sans identifiants, que puis-je lire ? »
Classe 4 : artefacts de mode test en production
Clés de test (pk_test_*, sb_test_*) dans un déploiement de production ; applications Firebase en mode dev accessibles depuis le domaine live ; applications Auth0 de tenant de test avec des paramètres plus faibles que la production. Le scan compare les clés runtime aux préfixes de production attendus.
Classe 5 : vérification de signature de webhook manquante
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.
Comment fonctionne le scan BaaS parapluie de FixVibe
La phase BaaS de FixVibe s'exécute en trois étapes, chacune produisant des résultats distincts :
- 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.
- Étape 3 — corrélation inter-fournisseurs. Le scanner croise les résultats. Une clé de rôle de service Supabase fuitée à côté d'un RLS manquant est plus grave que l'un ou l'autre résultat seul — le rapport le met en évidence. Plusieurs fournisseurs d'identité (Clerk + Auth0 + auth personnalisée) dans la même application est un résultat structurel signalé pour examen.
Chaque sondage est passif : au plus une lecture anonyme par ressource, avec la forme de la réponse enregistrée mais le contenu des lignes jamais paginé ou stocké. Les sondages d'écriture et de modification sont conditionnés par la vérification de la propriété de domaine — ils ne s'exécutent jamais contre des cibles non vérifiées.
Ce que le scanner trouve par fournisseur
Chaque fournisseur BaaS a une surface différente et une stratégie de scan différente. Voici ce qui est couvert :
- Supabase : RLS manquant sur les tables, buckets de stockage listables anonymement, JWT
service_rolefuité ou clésb_secret_*dans le bundle, schémas exposés via listing OpenAPI anonyme. Voir Scanner RLS Supabase et Liste de contrôle Storage. - Firebase : règles
if truesur Firestore, Realtime Database et Cloud Storage ; buckets de stockage listables anonymement ; absence d'App Check. Voir Scanner de règles Firebase et Explicateur de la règle if-true. - Clerk : clés secrètes
sk_*intégrées,pk_test_*en production, vérification de signature de webhook manquante, origines autorisées à joker. Voir Liste de contrôle Clerk. - Auth0 : client secrets intégrés, grant Implicit activé, URLs callback / logout à joker, PKCE manquant sur les SPAs. Voir Liste de contrôle Auth0.
Comment un scanner BaaS se compare aux outils DAST et SAST généraux
Un scanner conscient du BaaS fait un travail spécifique que d'autres outils ne font pas. La comparaison :
| Aspect | FixVibe (DAST conscient du BaaS) | DAST général (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| Couverture BaaS | Checks natifs pour Supabase, Firebase, Clerk, Auth0, Appwrite | Crawl web générique ; pas de sondages spécifiques au fournisseur | Analyse statique du repo uniquement ; pas de validation en production |
| Temps de configuration | URL → run → results usually in under a minute | Heures : configurer spider, auth, scope | Jour : intégrer dans le CI du repo |
| Ce qu'il prouve | Exposition runtime production avec preuve au niveau HTTP | Vulns app web (XSS, SQLi) ; BaaS via config manuelle | Motifs de code qui peuvent ou non être déployés |
| Inspection du bundle JavaScript | Every shipped chunk, with provider-aware key detection | Limitée — grep basé sur des chaînes uniquement | Oui, mais uniquement côté repo, pas déployé |
| Scan continu | Mensuel / au déploiement via API + MCP | Manuel ; configurez le planning vous-même | Par commit (bon pour le code, aveugle au runtime) |
| Prix pour solo / petite équipe | 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.
Questions fréquentes
Le scan parapluie fonctionne-t-il si mon application utilise deux fournisseurs BaaS (p. ex., Supabase + Clerk) ?
Oui — l'identification du fournisseur et les sondages par fournisseur sont indépendants. Le scanner détecte les deux, lance les deux suites de checks et signale les corrélations inter-fournisseurs (p. ex., un template JWT Supabase depuis Clerk qui livre email comme claim aux côtés d'un RLS manquant).
En quoi cela diffère-t-il de lancer Burp Suite Pro contre mon application ?
Burp est un établi DAST général. Tel quel, Burp ne sait pas ce qu'est PostgREST, Firestore ou le chemin de callback Auth0 — vous devez configurer manuellement le scope, écrire des extensions et interpréter les réponses. FixVibe est livré avec des sondages BaaS intégrés et un formatage de preuve à la forme BaaS. Burp gagne sur la couverture générale d'applications web (XSS, SQLi, logique métier) ; FixVibe gagne sur les résultats spécifiques au BaaS.
Qu'en est-il d'App Check (Firebase) ou de l'attestation (Apple / Google) ?
App Check fait que les scans externes opportunistes retournent 403 à chaque sondage — le résultat correct pour un bot malveillant. Un scan FixVibe depuis un client non attesté se comporte de la même façon. Si vous avez App Check activé et que FixVibe signale toujours des résultats, cela signifie que vos règles sont ouvertes aux clients attestés aussi, ce qui est le risque réel. App Check + règles correctes est le motif de défense en profondeur.
Le scanner peut-il vérifier ma correction ?
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.
Étapes suivantes
Lancez un scan FixVibe gratuit contre votre URL de production — les checks de phase BaaS sont dans tous les plans, y compris le gratuit. Pour des plongées approfondies par fournisseur, les articles individuels de cette section couvrent chaque fournisseur en détail : RLS Supabase, Exposition de clé de service Supabase, Storage Supabase, Règles Firebase, Firebase if-true, Clerk, et Auth0.