// 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
Les webhooks Clerk, Stripe et Supabase signent tous leurs payloads. Un handler qui ne vérifie pas la signature est une primitive d'écriture en base de données pour tout attaquant qui devine l'URL. Détecté via la forme de la réponse — une requête non signée qui obtient 200 signifie que la vérification est sautée.
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 :
- <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.
- Étape 2 — sondages spécifiques au fournisseur. Pour chaque fournisseur détecté, le scanner lance le check spécifique au fournisseur :
baas.supabase-rlssonde PostgREST ;baas.firebase-rulessonde Firestore + RTDB + Storage ;baas.clerk-auth0valide le préfixe des clés intégrées ; le check secrets-de-bundle valide qu'aucun identifiant de niveau service n'a fui. Chaque sondage s'exécute indépendamment — un résultat Supabase ne bloque pas le scan Firebase. - É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 → lancer → résultats en 60 secondes | 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 | Décode les JWTs, correspond aux préfixes de secret, parcourt les chunks | 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 | Offre gratuite ; payant à partir de 19 $/mois | Burp Pro 499 $/an ; ZAP gratuit mais beaucoup de faux positifs | Snyk gratuit / Semgrep gratuit ; plans payants à partir de 25 $/dev |
Portée honnête : ce que ce scanner ne remplace pas
Un scanner DAST conscient du BaaS est un outil ciblé, pas un programme de sécurité complet. Il ne :
- Remplace pas SAST ou SCA. L'analyse statique trouve les CVE de dépendances (Snyk, Semgrep) et les vulnérabilités au niveau du code (SonarQube) qu'un scanner DAST ne peut pas. Lancez les deux.
- Remplace pas les tests de pénétration manuels. Un pentester humain trouve des failles de logique métier, des cas limites d'autorisation et des vulnérabilités chaînées qu'aucun scanner ne peut. Engagez un pentester avant un lancement majeur ou un audit de conformité.
- Audite pas votre code ou repo pour les secrets dans l'historique git. Le check secrets-de-bundle couvre ce qui est actuellement déployé, pas ce qui a été historiquement commité. Utilisez
git-secretsougitleakspour l'hygiène du repo. - Couvre pas les services backend non-BaaS. Si votre application utilise un backend personnalisé (Express, Rails, Django, FastAPI), FixVibe scanne sa surface HTTP mais ne sonde pas la base de données ou l'infrastructure derrière. C'est le territoire du DAST + SAST général.
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 ?
Oui — relancez-le après application de la correction. Les IDs de check (p. ex., baas.supabase-rls) sont stables entre les exécutions, donc vous pouvez diffuser les résultats : un résultat qui était open dans l'exécution 1 et absent dans l'exécution 2 est la preuve que la correction a pris.
É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.