Reeve Votre appli Base44 est-elle sûre ?
Base44 garde votre base de données hors d'internet, ce qui supprime le plus gros risque des applis codées vite. Il reste une liste courte, et presque toujours la même.
Les logos sont la propriété de leurs détenteurs respectifs et servent uniquement à indiquer la compatibilité.
En bref
- Base44 n'expose pas votre base de données à internet. L'erreur qui fait fuiter la plupart des applis codées vite ne vous est pas accessible, et c'est un vrai avantage.
- Le risque se déplace vers ce que voit le navigateur : une API qui répond à tous les sites, et votre code source publié à côté de l'appli. Ces deux-là sont sur presque toutes les applis Base44 que nous analysons.
- Personne ne peut vérifier une base Base44 depuis l'extérieur, nous compris. Si vous avez rattaché votre propre projet Supabase, cette partie-là se vérifie et mérite un coup d'œil.
Base44 fait quelque chose que les autres outils ne font pas, et cela vaut la peine de le savoir avant de partir à la chasse aux problèmes : vos données ne répondent jamais directement à internet.
Votre appli demande quelque chose à Base44, Base44 le demande à la base de données, et la réponse revient par le même chemin. Il n'existe aucune adresse qu'un inconnu puisse taper. Sur la plupart des applis codées vite, la première cause de fuite de données est une table lisible par quiconque détient l'adresse du projet, et sur Base44 cette erreur ne vous est même pas accessible.
Et voici la partie que guide après guide raconte de travers : cela ne rend pas votre appli sûre, cela la rend sûre sur un point précis. Le risque se déplace, et l'endroit où il se déplace est prévisible au point qu'on peut vous le dire tout de suite, avant que vous analysiez quoi que ce soit.
Ce que Base44 garde hors d'internet pour vous
La réserve, pour rester sur la comparaison évidente.
Voyez votre appli comme une boutique. Tout ce que le navigateur d'un visiteur télécharge, c'est la vitrine, et elle est remise en entier à quiconque charge la page : un navigateur ne peut pas afficher ce qu'on ne lui a pas envoyé. Derrière se trouve la réserve, vos données. Chez la plupart des outils, la réserve est un bâtiment à part avec sa propre adresse dans la même rue, et le fait que des inconnus puissent y entrer dépend d'un réglage que vous n'avez peut-être jamais vu. Chez Base44, il n'y a pas de porte sur la rue.
Concrètement, cela veut dire qu'il n'y a rien à coller dans un navigateur. Sur une appli adossée à Supabase, n'importe qui peut extraire l'adresse du projet de votre paquet, ajouter un nom de table et regarder ce qui revient. Faites la même chose sur une appli Base44 et la seule adresse que vous trouvez est la vôtre, sur votre propre domaine, qui répond ce que votre appli a été écrite pour répondre.
Cela se voit dans les notes. Parmi les applis Base44 de notre analyse d'applis en ligne, presque toutes décrochent un A ou un B, et les défaillances qui tirent d'autres outils jusqu'au D n'apparaissent presque pas.
Il y a aussi une conséquence honnête : personne ne peut le vérifier de l'extérieur, nous compris. Une vérification depuis internet ne peut essayer que des portes qui existent. Ici il n'y en a pas, donc il n'y a rien à rapporter, et un scanner qui imprimerait « base de données : sûre » sur cette base inventerait un résultat.
Une clé dans votre appli Base44, est-ce un problème ?
En général non, et les deux sortes se ressemblent énormément.
Une clé publiable nomme un projet et ne fait rien d'autre. Elle est faite
pour être lue, et la trouver n'est pas une trouvaille. Une clé secrète, du
genre sb_secret_…, service_role ou sk_live_…, contourne toutes les règles
que vous avez écrites et peut tout lire et tout modifier.
Base44 garde ses propres identifiants sur le serveur : une clé posée dans votre appli n'est donc en général pas celle de Base44. Elle vient de quelque chose que vous avez branché vous-même, une clé de cartes, d'analytique ou de paiement collée pour faire marcher une fonctionnalité. La plus fréquente que nous trouvons sur les applis Base44 est une clé d'API Google, qu'il vaut mieux comprendre que craindre, car une clé sans restriction peut être dépensée par des inconnus. Lire quelle clé vous avez prend environ une minute.
Si vous trouvez un vrai secret, l'ordre compte. Renouvelez-le là où il a été émis, dans Google Cloud ou Stripe ou d'où qu'il vienne, et retirez-le de votre code ensuite. Supprimer la ligne d'abord ne ferme rien : l'ancienne valeur est déjà dans chaque copie en cache de votre site et dans ce qu'un robot a emporté la semaine dernière.
Le réglage qui est mauvais sur presque toutes les applis Base44
Pas une clé, et pas la base de données. Il s'agit de savoir à qui votre API accepte de parler.
Un navigateur refuse normalement qu'un site lise les données d'un autre. C'est
cette règle qui empêche une page que vous ouvrez d'appeler discrètement votre
banque et d'afficher votre solde. Un en-tête de réponse appelé CORS la lève, et
réglé sur * il la lève pour tout le monde : un site dont vous n'avez jamais
entendu parler peut appeler l'API de votre appli depuis le navigateur de votre
visiteur et lire ce qui revient.
Sur les applis Base44 que nous avons analysées, c'est de loin la trouvaille la plus fréquente. C'est aussi celle qu'on nous conteste le plus, et la contestation est légitime, alors voici la version honnête. Un joker devant une adresse qui exige une connexion est une trouvaille faible, car l'autre site n'a toujours aucun identifiant à envoyer. Un joker devant une adresse qui répond à n'importe qui est la vraie affaire, et environ la moitié des applis Base44 que nous avons analysées ont au moins une adresse qui renvoie des données à une requête simple, sans personne de connecté. Ce sont deux problèmes différents sous une seule étiquette, et c'est le second qu'il faut aller chercher.
Ni l'un ni l'autre n'est une faute de votre part. Un joker, c'est ce qu'un outil de build livre quand personne ne lui a dit autre chose, en général pour qu'un domaine de préversion et le domaine en ligne fonctionnent tous les deux pendant que vous construisez. Le court article donne le correctif, qui consiste à nommer votre propre domaine à la place de l'astérisque.
Votre code d'origine, publié à côté de l'appli
La deuxième trouvaille la plus fréquente, et celle que vous pouvez vérifier sans le moindre outil.
Une source map est un fichier qui retransforme le JavaScript compressé qu'exécute le navigateur en ce que vous avez écrit, avec les noms de fichiers d'origine, les commentaires et l'arborescence intacts. Les outils de build les génèrent pour qu'une erreur en production pointe vers une vraie ligne plutôt que vers la colonne 4 812 d'un unique fichier énorme. Cette partie est vraiment utile. Les publier à côté de l'appli est la partie qui vous coûte quelque chose.
Environ trois applis Base44 sur cinq que nous avons analysées livrent les leurs. Aucune donnée ne fuit à cause de cela, et votre appli ne se comporte différemment en rien, ce qui explique très bien que cela passe inaperçu pendant des mois. Ce qui change, c'est l'effort pour tout le reste : dénicher un point d'accès dans un paquet minifié est un travail lent et laborieux, alors que lire votre propre code n'est pas un travail du tout. Toute autre trouvaille de cette page devient moins chère à faire dès que votre code est lisible.
La vérification prend moins d'une minute. Ouvrez votre appli en ligne, appuyez sur F12 et regardez le panneau Sources. Si l'arborescence ressemble à votre projet, avec les noms que vous avez donnés, les maps sont parties avec la mise en ligne, et l'article long explique quoi changer.
Si vous avez branché votre propre base de données
Alors l'avantage du haut de cette page ne vaut pas pour cette partie, et les règles habituelles reviennent.
Environ un quart des applis Base44 que nous analysons nomment un projet Supabase à elles. Ce projet répond directement à internet, exactement comme chez tous les autres outils : Row Level Security est donc désormais votre affaire, un interrupteur par table qui décide ligne par ligne qui peut lire quoi.
Deux choses déterminent si vous l'avez. Supabase l'active par défaut pour les tables créées dans le Table Editor du tableau de bord, et pas pour celles créées en exécutant du SQL, ce qui est la façon dont la plupart des configurations générées les créent. Et l'interrupteur n'est que la moitié du sujet, car une règle qui autorise tout le monde laisse la table ouverte pendant que le tableau de bord la déclare sécurisée.
Le stockage suit la même logique et s'oublie facilement, parce qu'il vit dans une autre partie du tableau de bord que les règles de tables. Un bucket marqué public peut être listé et téléchargé par quiconque sait qu'il existe, que votre appli pointe ou non vers un fichier dedans, et les réglages qui en décident méritent une lecture posée.
Comment vérifier votre appli Base44 en une dizaine de minutes
Demandez ce que votre API raconte aux autres sites. C'est le point le plus souvent mal réglé et celui que personne ne regarde, parce que rien ne se comporte bizarrement dans votre appli quand il est réglé trop largement.
Ouvrez votre appli en ligne avec F12 et lisez le panneau Sources. Si vos propres fichiers y figurent sous leurs propres noms, tout le monde peut les lister aussi.
Lisez chaque clé présente dans l'appli. Pour chacune, demandez-vous si vous la mettriez sur votre page d'accueil. Si la réponse est non, sa place est sur un serveur, et elle doit être renouvelée à la source avant de sortir du code.
Ouvrez Authentication → Policies, si vous avez branché votre propre projet Supabase. Toute table listée avec Row Level Security désactivée répond à quiconque détient l'adresse du projet, et cette adresse est dans votre appli.
Puis regardez de l'extérieur. Les étapes ci-dessus vous disent ce qui est configuré. Ce qu'un inconnu peut réellement atteindre est une autre question, et c'est celle à laquelle répond notre analyse gratuite. Elle lit votre site en ligne comme un visiteur et vous donne une note en une vingtaine de secondes, sans compte : analysez votre appli.
Que faire
- Base44 garde votre base de données hors d'internet. La première cause de fuite de données dans les applis codées vite ne vous est pas accessible.
- Personne ne peut le vérifier de l'extérieur, nous compris. Pas de porte veut dire pas de résultat, et pas de résultat n'est pas une coche verte.
- Le risque se déplace vers le navigateur : une API qui répond à tous les sites, et votre code source publié à côté de l'appli.
- Un joker devant une adresse qui n'exige aucune connexion est la version qui compte, et environ la moitié de ces applis en ont une.
- Une clé dans votre paquet vient en général d'un service que vous avez branché. Renouvelez-la à la source, puis retirez-la du code.
- Branchez votre propre projet Supabase et les règles habituelles de Row Level Security et de stockage s'y appliquent intégralement.
Commencez par les deux qui valent presque toujours le coup : ce que votre API raconte aux autres sites, et si votre code d'origine est parti avec l'appli. Ensuite, la checklist sécurité de 10 minutes couvre le reste.
Ce qui peut vraiment mal tourner sur une appli Base44
Classé selon ce que nous voyons réellement sur les applis Base44, et ce n'est pas l'ordre auquel on s'attend. Rien ici ne veut dire que vous avez mal fait.
Votre API répond à n'importe quel site
C'est le cas courant sur Base44, et de loin. Normalement un navigateur refuse qu'un site lise les données d'un autre, et un réglage appelé CORS est ce qui lève cette règle. Réglé sur "*", il la lève pour tout le monde : une page dont vous n'avez jamais entendu parler peut appeler l'API de votre appli depuis le navigateur d'un visiteur. Reeve vérifie ce que votre appli dit aux navigateurs à ce sujet.
Votre code source est parti avec l'appli
Une source map est une copie lisible du code que vous avez écrit, publiée à côté de la version qu'exécute le navigateur. Pratique pendant la construction, cadeau pour un inconnu une fois en ligne : cela transforme « fouiller un paquet minifié » en « lire l'appli ». Elle ne fait fuiter aucune donnée à elle seule. Elle rend tout le reste plus facile à trouver.
Des en-têtes de sécurité manquants
Une poignée d'en-têtes disent au navigateur comment protéger vos visiteurs : ne pas deviner les types de fichiers, ne pas laisser un autre site encadrer cette page, ne pas divulguer l'adresse complète en sortant. Pris un par un, ils sont petits. Ensemble, ils décident de ce que quelqu'un peut faire avec ce qu'il trouve par ailleurs.
Une clé venant de quelque chose que vous avez branché
Base44 garde ses propres identifiants côté serveur : les clés qui apparaissent viennent donc en général d'un service que vous avez branché vous-même, une clé de cartes, d'analytique ou de paiement collée pour faire marcher une fonctionnalité. Certaines clés ont leur place dans un navigateur et ne posent aucun problème. Reeve lit le code chargé de votre appli, trouve les clés et vous dit laquelle est laquelle, sans jamais stocker les vraies valeurs.
Une base de données que vous avez branchée
Si vous avez rattaché votre propre projet Supabase au lieu d'utiliser les données intégrées de Base44, vous en avez aussi repris les règles. Row Level Security décide qui peut lire chaque ligne, et elle est désactivée par défaut pour les tables créées en exécutant du SQL. C'est le seul chemin par lequel le problème classique de la base ouverte atteint quand même une appli Base44. Reeve vérifie en comptant les lignes, jamais en les lisant.
Des fichiers que n'importe qui peut lister
Les envois atterrissent dans des « buckets » de stockage, et un bucket public laisse n'importe qui lister et télécharger ce qu'il contient : factures, pièces d'identité, photos privées. Reeve vérifie si vos buckets sont listables. Il ne télécharge jamais les fichiers de personne.
Ce que Reeve est, et ce qu'il n'est pas
Reeve est une vérification gratuite, en lecture seule, depuis l'extérieur, comme un inspecteur qui essaie les portes sans entrer. Il repère vite les erreurs courantes et lourdes de conséquences. Ce n'est pas un audit de sécurité complet, et une bonne note n'est pas une garantie ; elle veut dire que les portes évidentes sont fermées.
Les applis Base44 obtiennent de meilleures notes que la plupart, et c'est un résultat réel plutôt qu'un compliment : la plateforme prend en charge la partie qui tourne habituellement mal. Ce qui reste est une liste courte et assez uniforme, et c'est une bonne nouvelle, parce qu'une liste courte, on peut la terminer. Et si vous préférez que la surveillance ne soit pas votre travail, faites-en le nôtre.
Vous voulez que ce soit pris en charge, pas juste vérifié ?
Reeve Care surveille votre appli, sauvegarde vos données et vous aide à réparer ce qui casse, pour que vous puissiez continuer à construire au lieu de vous inquiéter.
Découvrir Reeve CareFAQ
Une appli Base44 est-elle plus sûre qu'une appli faite ailleurs ?
Sur un point précis, oui. Votre base de données n'est pas joignable depuis internet, vous ne pouvez donc pas commettre l'erreur qui expose la plupart des applis codées vite : une table lisible par quiconque en connaît l'adresse. C'est la première cause de fuite de données dans les applis comme la vôtre, et Base44 vous l'enlève des mains. Tout ce qu'un navigateur voit reste votre affaire.
Reeve peut-il vérifier ma base de données Base44 ?
Non, et personne ne le peut depuis l'extérieur. Vos données passent par le backend de Base44 au lieu de répondre directement à internet : il n'y a donc pas de porte à essayer. Nous le disons aussi sur notre page de recherche, et nous préférons vous le dire plutôt qu'imprimer une coche verte que nous n'avons pas méritée. Si vous avez branché votre propre projet Supabase, cette partie-là, nous pouvons la vérifier.
Mon appli contient une clé API. Est-ce un problème ?
Cela dépend entièrement de laquelle. Certaines sont conçues pour être publiques et votre appli ne fonctionne pas sans elles ; d'autres livrent un compte entier. Base44 garde ses identifiants sur le serveur, donc une clé dans votre paquet vient en général d'un service que vous avez branché. Reeve lit le type de clé et vous dit en mots laquelle vous avez, sans stocker la valeur.
Analyser mon appli Base44 va-t-il changer quelque chose ?
Non. Reeve regarde seulement ce qui est déjà public depuis l'extérieur. Il ne se connecte jamais, ne modifie jamais rien et ne télécharge jamais vos fichiers. En lecture seule, comme vérifier qu'une porte est fermée sans entrer.
Si ma base de données n'est pas joignable, reste-t-il quelque chose à surveiller ?
Oui, mais une liste plus courte que la plupart. Votre appli tourne toujours dans un navigateur, et tout ce que le navigateur reçoit est public : le code, les clés qui y sont intégrées et les adresses qu'il appelle. Deux choses valent la vérification : savoir si ces adresses répondent aux requêtes venues d'autres sites, et si une copie lisible de votre code source est partie avec la mise en ligne.
Si personne ne peut le vérifier de l'extérieur, comment savoir que mes données vont bien ?
De l'intérieur, seul endroit où cette réponse existe. Comme les requêtes passent par Base44 au lieu d'aller à une adresse publique, tout ce qui décide qui peut lire quoi vit dans votre appli et dans la plateforme, là où un inconnu ne peut pas venir tâter le terrain. Les questions utiles sont donc : qui peut créer un compte, que voit une personne inscrite, et un écran a-t-il été construit en supposant que personne ne regarderait. Une vérification externe ne répond à aucune de ces questions. Elle répond à l'autre moitié : ce que quelqu'un atteint sans même s'inscrire.
Mon analyse dit que mon API répond à tous les sites. Est-ce moi qui ai fait ça ?
Presque certainement pas exprès. Un joker, c'est ce qu'un outil de build livre quand personne ne lui a dit autre chose, en général pour qu'une adresse de préversion et l'adresse en ligne fonctionnent toutes les deux pendant que vous construisez, et il survit jusqu'en production parce que rien ne casse dans votre appli quand il est trop large. Ce qui décide de son importance, c'est l'adresse derrière : si elle exige une connexion, la trouvaille est faible. Si elle répond à n'importe qui, c'est la version à corriger cette semaine.
J'ai branché mon propre projet Supabase sur mon appli Base44. Est-ce que cela change quelque chose ?
Cela change le plus important. Votre projet répond directement à internet : le réglage Row Level Security, table par table, est désormais votre affaire, et il est désactivé par défaut sur toute table créée en exécutant du SQL. C'est le seul chemin par lequel le problème classique de la base ouverte atteint une appli Base44, et il vaut dix minutes de votre temps.