Reeve Votre appli Replit est-elle sûre ?
Replit convient-il à une vraie appli ? Construire et publier n'y font qu'un, ce qui est pratique, et c'est aussi ce qui rend les vérifications utiles.
Les logos sont la propriété de leurs détenteurs respectifs et servent uniquement à indiquer la compatibilité.
En bref
- Une appli Replit est sûre à héberger, mais construire et publier ne font qu'un geste : il n'y a pas d'étape de déploiement où rattraper une erreur.
- Replit Secrets garde une clé hors de vos fichiers. Il ne peut pas la garder hors du navigateur si c'est votre code navigateur qui la lit.
- Si vos données sont dans Supabase, le réglage qui décide qui peut les lire est Row Level Security, et il se pose table par table.
Replit exécute votre appli et la publie depuis l'endroit même où vous la construisez. C'est l'essentiel de son attrait, et cela veut aussi dire que l'écart entre « j'ai changé quelque chose » et « internet peut le voir » est à peu près nul. Il n'y a pas d'étape de déploiement distincte où s'arrêter et réfléchir.
Voici ce que guide après guide raconte de travers : ranger une clé dans un gestionnaire de secrets ne la rend pas privée. Le gestionnaire décide où la valeur repose. Votre code décide où elle voyage, et s'il l'emmène dans un navigateur, c'est là qu'elle finit.
Ce qu'une appli Replit publiée remet à un visiteur
Toute sa façade, à chaque fois.
Voyez cela comme une boutique. Les pages, formulaires et boutons de votre appli sont la devanture, remise en entier à chaque visiteur qui charge votre site : un navigateur ne peut pas afficher une page qu'on ne lui a pas envoyée. Vos données vivent dans la réserve, un bâtiment séparé sur internet avec sa propre adresse et sa propre serrure.
La nuance que l'on rate sur Replit, c'est où tombe la frontière. Le code qui tourne sur le serveur et celui qui tourne dans le navigateur du visiteur sont dans le même projet, souvent dans des fichiers voisins. Une valeur lue sur le serveur reste sur le serveur. La même valeur lue par du code navigateur est compilée dans ce que vous publiez. Replit Secrets garde une clé hors de vos fichiers sources, ce qui est réellement utile, mais il ne peut pas décider quelle moitié de votre appli la lit.
Est-ce grave que mon appli Replit contienne une clé ?
En général non. Cela dépend de laquelle, et il y en a deux qui se ressemblent presque en tout.
Une clé publiable identifie votre projet et rien de plus. Supabase la nomme
sb_publishable_… dans les projets récents et anon dans les anciens, et elle
est faite pour vivre dans un navigateur. Une clé secrète (sb_secret_…, ou
service_role avant le renommage) ignore toutes les règles que vous avez posées
et lit et écrit chaque ligne de chaque table.
Si un scanner vous annonce qu'une clé est exposée, c'est la première chose à établir, parce que l'une des deux est un mardi ordinaire et l'autre mérite qu'on s'arrête. La vérification prend environ une minute.
Et « personne ne connaît mon URL » n'est pas une défense. Des robots lisent les sites publics à la recherche exactement de ces chaînes, en continu, sans la moindre idée de qui vous êtes.
Ce qui décide si des inconnus peuvent lire vos données
Les règles posées sur votre base de données, qui ne font pas partie du tout de votre projet Replit.
Si vos données sont dans Supabase, le réglage s'appelle Row Level Security : un interrupteur par table qui décide ligne par ligne qui peut lire quoi. Désactivé, votre clé publiable renvoie la table entière à n'importe qui. Activé, avec une politique écrite, elle ne renvoie que ce que cette politique autorise.
Deux choses décident si vous l'avez, et aucune n'est visible depuis l'intérieur de votre appli. Supabase active Row Level Security 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 un fichier de migration, ou un assistant qui écrit votre schéma, les crée. Et une table peut porter le réglage pendant que sa politique laisse toujours passer tout le monde, si bien que l'interrupteur seul ne restreint personne.
Retirer une page de votre appli Replit ne change rien à tout cela. La réserve ignore que votre devanture existe.
Comment vérifier votre appli Replit en une dizaine de minutes
Déterminez quelle moitié lit chaque secret. Pour chaque clé du projet, trouvez le code qui l'utilise et décidez si ce code tourne sur le serveur ou dans le navigateur. Tout ce que le navigateur lit est publié, où que ce soit rangé.
Chargez votre propre appli publiée et ouvrez les DevTools. L'onglet Réseau montre exactement ce qu'un visiteur reçoit. C'est la vue qu'a une personne extérieure, et elle tranche la question plus vite que la lecture des fichiers.
Ouvrez Authentication → Policies dans Supabase. Tout ce qui affiche Row Level Security comme désactivé est lisible par quiconque connaît l'adresse de votre projet.
Puis regardez vraiment depuis l'extérieur. C'est à cela que sert notre scan gratuit : il lit votre site en ligne comme le ferait n'importe quel visiteur et vous donne une note en une vingtaine de secondes, sans compte : scanner votre appli.
Que faire
- Sur Replit, construire et publier ne font qu'un geste. Il n'y a pas d'étape de déploiement où rattraper une erreur.
- Un gestionnaire de secrets protège une valeur au repos. Le code navigateur publie ce qu'il lit, d'où que vienne la valeur.
- Une clé publiable dans votre appli est correcte.
sb_secret_…etservice_rolesont celles à renouveler aujourd'hui. - Les tables créées en exécutant du SQL démarrent sans Row Level Security, et l'activer laisse toujours chaque ligne lisible tant qu'une politique ne dit pas le contraire.
- Une URL inconnue n'est pas une protection. Les robots n'ont pas besoin de savoir qui vous êtes pour trouver votre site.
Prenez la clé que votre appli utilise le plus et retracez quelle moitié de votre projet la lit : serveur ou navigateur. Cette seule réponse vous en dira plus que n'importe quelle quantité de lecture, et la checklist sécurité en 10 minutes couvre le reste de la surface une fois que vous l'avez.
Ce qui peut réellement mal tourner avec une appli Replit
Rien de tout cela ne signifie que vous avez fait quelque chose de mal : ce sont les effets secondaires normaux d'une création rapide. Voici ce qui vaut la peine d'être vérifié :
Une clé secrète dans votre code au lieu de Replit Secrets
Replit vous offre un gestionnaire de Secrets pour que les clés restent hors de votre code. Mais il est tentant de coller une clé directement dans un fichier pour que ça marche, et si ce fichier s'exécute dans le navigateur, ou si votre Repl est public, n'importe qui peut la lire. Reeve trouve les clés dans le code chargé de votre appli et vous dit lesquelles sont sûres à exposer et lesquelles doivent être déplacées.
Un Repl public qui expose votre source (et vos clés)
Sur de nombreux forfaits, les Repls sont publics par défaut, ce qui signifie que votre code, et tout ce qui y est codé en dur, peut être lu par quiconque a le lien. Reeve vérifie ce que votre appli déployée expose depuis l'extérieur, pour que vous sachiez si des détails privés sont visibles.
Votre base de données laissée ouverte (RLS désactivé)
Si votre appli stocke des données (dans la base de données de Replit, dans Supabase ou dans un autre Postgres), il existe généralement une règle qui détermine qui peut lire ou modifier chaque ligne. Si elle est désactivée ou mal configurée, vos tables peuvent être ouvertes à quiconque trouve l'adresse. C'est le problème sérieux le plus fréquent, et il se cache tant que vous ne vérifiez pas.
Un fichier .env ou de configuration exposé
Les clés vivent souvent dans un fichier .env qui ne devrait pas être expédié. Il finit parfois accessible sur le site déployé quand même, ce qui est un raccourci vers tout ce qui est sensible. Reeve vérifie si le vôtre est discrètement accessible.
Source maps laissées actives
Une « source map » révèle le code d'origine de votre appli à quiconque regarde. Pratique pendant le développement, mais en production elle donne aux inconnus une copie lisible du fonctionnement de votre appli et rend d'autres failles plus faciles à trouver. Reeve vérifie si les vôtres sont exposées.
En-têtes de sécurité manquants & points d'accès ouverts
De petits réglages qui indiquent aux navigateurs comment protéger vos visiteurs, plus le fait que vos points d'accès de données répondent à n'importe qui ou à n'importe quel site. Mineurs isolément ; ensemble, ils élargissent la faille. Reeve signale ce qui manque.
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. C'est rapide et ça repère les erreurs courantes à fort impact. Ce n'est pas un audit de sécurité complet, et une note propre n'est pas une garantie. Elle signifie que les portes évidentes sont fermées.
Replit vous donne de bons outils (un gestionnaire de Secrets, et des réglages pour savoir si un Repl est public), et ils aident vraiment quand vous les utilisez. Ce que Reeve ajoute : une vérification de ce que votre appli déployée expose réellement depuis l'extérieur, au cas où une clé aurait glissé dans le code ou un Repl serait plus public que vous ne le pensiez, expliqué en mots simples et exploitables. Et si vous préférez ne pas y penser, nous pouvons la surveiller pour vous.
Vous voulez que ce soit géré, pas seulement vérifié ?
Reeve Care continue de surveiller votre appli, sauvegarde vos données et vous aide à réparer les choses quand elles cassent, pour que vous puissiez continuer à créer au lieu de vous inquiéter.
En savoir plus sur Reeve CareFAQ
Les applis Replit sont-elles sûres par défaut ?
Replit vous donne les pièces pour être sûr (Secrets, réglages de déploiement), mais « par défaut » dépend de si les clés sont restées dans les Secrets, si votre Repl est privé et si les règles de votre base de données sont activées. Le seul moyen de le savoir est de vérifier ce qui est exposé, ce que Reeve fait gratuitement en environ 20 secondes.
Est-il sûr de garder des clés d'API dans mon code Replit ?
Il est bien plus sûr de les garder dans Replit Secrets que dans votre code. Une clé écrite dans un fichier peut être lue si ce code s'exécute dans le navigateur ou si votre Repl est public. Reeve trouve les clés dans votre appli chargée et vous dit lesquelles sont sûres à exposer et lesquelles doivent être déplacées dans les Secrets.
Les gens peuvent-ils voir mon code si mon Repl est public ?
Oui. Un Repl public signifie que votre source, et tout ce qui y est codé en dur, peut être lu par quiconque a le lien. Reeve vérifie ce que votre appli déployée révèle depuis l'extérieur pour que vous puissiez voir si des détails privés apparaissent.
Analyser mon appli Replit va-t-il casser 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 si une porte est verrouillée sans entrer.
J'ai mis mes clés dans Replit Secrets plutôt que dans le code. Sont-elles privées pour autant ?
Cela les garde hors de vos fichiers, ce qui vaut la peine et règle un vrai problème. Cela ne rend pas une valeur privée une fois que votre appli l'envoie à un navigateur. Si le code qui utilise la clé tourne dans le navigateur du visiteur, la clé y voyage quel qu'ait été son rangement. Un gestionnaire de secrets protège une valeur au repos, et c'est votre appli qui la porte jusqu'au visiteur.
Mon appli Replit est petite et personne ne connaît son URL. Est-ce suffisant ?
Non, et la raison est que personne n'a besoin de vous connaître. Des robots parcourent les sites publics en continu à la recherche de chaînes en forme de clé et de points d'accès de base de données ouverts, sans la moindre idée de qui les possède. Être inconnu n'est pas la même chose qu'être injoignable.
Où regarder pour savoir si ma base de données est ouverte ?
Si vous utilisez Supabase, ouvrez le projet et allez dans Authentication, puis Policies. Chaque table du schéma public y est listée avec l'état de Row Level Security. Tout ce qui est désactivé est lisible par quiconque détient l'URL de votre projet et votre clé publiable, qui se trouvent tous deux dans votre appli publiée.