Scan de sécurité Base44 : ce que lui seul peut voir

Tu ouvres le Dashboard de ton app Base44, tu cliques sur Security, tu appuies sur Run Security Scan, et quelques secondes plus tard une liste revient. Ou rien. Dans les deux cas tu tiens un résultat et tu te demandes si c’était là toute la vérification.

La plupart des textes sur le sujet prennent le problème à l’envers. L’argument habituel dit qu’un scan lancé depuis l’intérieur de ton projet ne peut pas voir ce que voit internet, et que c’est donc celui de l’extérieur qu’il faut croire. Sur Base44 c’est l’inverse pour la moitié qui compte : le scan de sécurité Base44 est la seule chose capable de vérifier si un inconnu peut lire tes données, et nous pouvons te montrer que nous en sommes incapables. Nous avons essayé sur 1 466 apps Base44 et obtenu une réponse de deux d’entre elles.

C’est donc une division du travail. Un scan travaille à l’intérieur du bâtiment. L’autre se tient sur le trottoir et lit ce qu’on distribue par devant. Les deux valent la peine, et sur Base44 c’est celui de l’intérieur qui fait la moitié la plus lourde.

Que vérifie le scan de sécurité Base44 ?

Sept types de problèmes, lus depuis l’intérieur de ton projet. Il ne va jamais chercher ton adresse publiée.

Tout cela a été lu le 10 octobre 2026 dans la documentation de Base44, sur les pages Running a security scan et Base44 security: An overview. Trois choses y méritent d’être connues avant de te fier au résultat :

• Le scan n’applique jamais un correctif de lui-même. Tu appuies sur Fix, et Base44 écrit la modification dans le chat IA de ton app en posant un checkpoint avant, si bien qu’un correctif qui casse quelque chose peut être annulé depuis le chat.
• Le bouton Fix with AI sur une fonction non authentifiée rejette tout appelant sans utilisateur connecté. Base44 écrit dans la foulée que cela peut casser une page destinée aux visiteurs non connectés, un webhook ou une intégration qui appelle cette fonction. Teste ces chemins ensuite.
• Il avertit à la publication et ne t’arrête pas. Le panneau de publication affiche un statut Security, et Base44 le décrit comme un avertissement qui ne t’empêche pas de publier.

Ce que lui seul peut voir

Si les gens qui utilisent ton app peuvent atteindre des données qui ne sont pas les leurs. Sur une app Base44, rien hors de la plateforme ne peut le vérifier.

Chez la plupart des builders, ton app parle à sa base de données directement depuis le navigateur de ton visiteur. La base a donc une adresse publique, ta page transporte cette adresse, et n’importe qui peut l’en extraire et commencer à poser des questions. Obtenir des réponses dépend d’un réglage table par table que la plupart des propriétaires n’ont jamais ouvert. Une app Base44 fait passer ses requêtes par Base44, il n’y a donc aucune adresse dans la rue que quelqu’un pourrait essayer.

La mesure est assez déséquilibrée pour trancher. 1 466 des 5 442 apps Base44 que nous avons notées nomment un projet Supabase quelque part dans la page. Notre vérification Row Level Security a obtenu une réponse exploitable de 2 d’entre elles. Sur Lovable, où la base répond directement à la rue, 3 553 sur 6 535 ont répondu. Sur Bolt, 35 sur 267.

Deux apps ne font pas un taux, et nous n’en imprimerons pas. Ce que le chiffre tranche, c’est qui peut regarder : sur une app Base44, les règles d’accès à tes données se lisent depuis la page Security de ton propre tableau de bord et de nulle part ailleurs. Le relevé complet des notes de 5 442 apps Base44 contient les autres chiffres.

Pourquoi ton app publiée peut quand même transporter une clé

Parce que le scan lit ton projet et que tes visiteurs téléchargent un fichier. Quatre choses tirées de la documentation de Base44 séparent les deux :

• La version publiée peut être plus ancienne que celle que le scan a lue. Le résultat credit protection de Base44 a un état prévu exactement pour cela, et le message indique "Publish changes before protecting credits" quand ton app en ligne tourne encore sur une version antérieure.
• Le statut à la publication est un avertissement. Risks found ouvre la page Security, et tu peux publier quand même.
• Un problème que tu ignores ne revient pas. Les résultats ignorés partent dans leur propre section en bas de la liste et, selon les mots de Base44, ne réapparaissent pas au scan suivant. Une liste vide peut vouloir dire que quelqu’un a écarté le problème en juin.
• La moitié qui lit le code demande une formule payante. Code vulnerability scanning tourne à partir de Builder, tout comme l’intégration Wiz optionnelle, qui ajoute de l’analyse statique via ton propre tenant Wiz.

Vu du trottoir, cet écart a une taille. Sur les 5 442 apps Base44 que nous avons notées, 95 servaient une clé API Google dans la page, 11 avaient quelque chose ayant la forme d’un mot de passe ou d’un token, une une clé Stripe restreinte et une une clé secrète Stripe. La vérification des secrets a répondu sur les 5 442 apps, ce sont donc des comptes et non un échantillon.

Ces 95 sont une part plus faible que chez les voisins, et cela mérite d’être dit clairement : dans le même relevé, 727 apps Lovable sur 18 563 et 200 apps Replit sur 3 050 transportaient une clé API Google. Sur cette mesure, les apps Base44 sont plus calmes que celles construites à côté.

C’est aussi le résultat de cette liste qui a le plus de chances d’être normal. Google délivre un seul type de clé API et s’attend à la voir dans le navigateur ; ce qui décide si un inconnu peut faire grimper une facture avec, c’est de savoir si tu l’as restreinte à ton propre domaine, et cette restriction vit dans la console Google, pas dans ton app. Ce qu’il faut vérifier sur une clé Google trouvée dans ta propre page, ce sont les deux réglages à lire.

Si tu préfères voir la liste complète de ce que ton app Base44 publiée distribue, notre scan gratuit lit ton adresse en ligne et rapporte ce qu’il voit depuis l’extérieur. Il prend une vingtaine de secondes et ne demande aucun compte : scanner ton app gratuitement.

La vérification de la liste à laquelle personne ne pense

Quelqu’un qui appelle les fonctions payantes de ton app directement, sans passer par ton app du tout.

Base44 appelle cela credit protection, et le résultat apparaît quand une fonction à toi qui utilise l’IA, la génération d’images ou l’e-mail est joignable depuis l’extérieur de ton app. Leur documentation est nette sur la conséquence : celui qui la trouve peut la lancer et dépenser tes crédits d’intégration. C’est classé High, et selon ton app le correctif est soit un simple bouton Fix qui restreint ces fonctions en laissant ton propre accès intact, soit un Resolve with AI qui déplace les appels dans ton backend.

C’est le genre de chose qu’un scan intérieur fait bien et qu’un scan extérieur n’a aucun moyen honnête de tester. Savoir si quelqu’un peut lancer ta fonction e-mail gratuitement supposerait de la lancer, donc notre scan laisse celle-là à Base44 et rapporte ce qu’il peut lire sans rien dépenser de ce qui est à toi.

Ce qu’aucun des deux scans ne vérifie

Trois choses, et la dernière est la seule de cette page qui ne se répare pas après coup.

Ton certificat et ton domaine, si l’app tourne sur ta propre adresse. Une app Base44 sur une adresse base44.app hérite de ceux de Base44. Déplace-la vers un domaine que tu as acheté et les dates de renouvellement deviennent les tiennes, ce qui est la façon la plus silencieuse dont une app qui marche s’éteint.

Les fichiers d’un bucket Supabase Storage que tu as branché. Sur les 1 466 apps Base44 qui nomment un projet Supabase, notre vérification des buckets a pu répondre sur 5. Le mur qui cache la base cache aussi le bucket, et la vérification des accès de Base44 couvre les tables qu’elle gère, pas un bucket dans un projet que tu as branché toi-même.

S’il existe une copie de tes données. Aucun scan, d’aucun côté du mur, ne le vérifie, parce que ce n’est pas une propriété de ton app. C’est une propriété de ce que tu as mis en place ailleurs, et cela décide si une migration partie de travers ou un agent ayant accès à la base se termine par une restauration ou par un e-mail à tes utilisateurs. Le jour où un agent IA a supprimé une base de données de production montre à quoi ressemble la seconde.

Garder les deux moitiés couvertes après la publication

Relance les deux après chaque modification. Un résultat de la semaine dernière décrit l’app de la semaine dernière, et sur Base44 publier tient en un bouton : une table ajoutée ce matin ou une clé collée à minuit est en ligne dès que tu appuies dessus.

Reeve Monitor relance les neuf vérifications extérieures pour toi :

• les neuf vérifications toutes les heures, sur jusqu’à trois apps
• si l’app répond, toutes les 60 secondes
• un message quand un résultat change, pour qu’un nouveau problème n’attende pas que tu regardes
• un rapport mensuel de ce qui a été vu

Si ton app Base44 garde ses données dans ton propre projet Supabase, Reeve Care en conserve une copie :

• une copie chiffrée de ta base Supabase chaque nuit, rangée là où ton projet ne peut pas l’atteindre
• chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
• une restauration en un clic quand tu en as besoin
• tes fichiers téléversés aussi, dès que tu renseignes un accès Storage
• tout ce que fait Monitor

Les deux sont sur la page des tarifs, qui est parfois en dessous du tarif affiché ici et jamais au-dessus.

Ce qu’il faut faire aujourd’hui

Commence par la section Ignored, cela prend quelques secondes et c’est le seul endroit où un rapport propre peut cacher un vrai problème. Si tu veux la version en langage clair de tout ce qui se vérifie de l’extérieur sur une app Base44, nous avons un guide pour les apps Base44.