Sécuriser une app Replit avant de la mettre en ligne

Replit a un truc que les autres builders n'ont pas : c'est aussi un éditeur en ligne. Ton code, ton .env, tes fichiers, tout vit dans un espace de travail accessible depuis le web. C'est pratique pour coder à plusieurs. C'est aussi le premier endroit où ça fuit, parce qu'un repl public montre son contenu à qui a le lien.

Un finding qui m'a marqué : un fichier .env en clair sur la partie app d'un site de réservation, avec la mention « vos données sont protégées », et du trafic derrière. Un .env, c'est le fichier qui concentre tout ce qui est critique : clés de paiement, clés d'IA, secrets de chiffrement. Téléchargeable par tout le monde. Voilà comment éviter ça sur Replit, avant de mettre ton app en ligne.

Le repl public : ton code visible par défaut

Sur Replit, un repl peut être public ou privé. Un repl public, ce n'est pas juste ton app qui tourne, c'est aussi tout ton code source, ton arborescence de fichiers, et souvent ton .env si tu l'as créé là. N'importe qui avec le lien peut le lire, le forker, le télécharger.

Beaucoup de gens laissent leur repl en public sans y penser, parce que c'est comme ça qu'ils l'ont créé. Le réflexe à prendre : si ton repl contient des secrets ou du code que tu ne veux pas partager, passe-le en privé. Et surtout, ne compte jamais sur un .env dans un repl pour cacher quoi que ce soit.

Secrets Replit contre clés en dur

Replit te donne un endroit fait pour ça : les Secrets. Ce sont des variables d'environnement rangées à part, injectées dans ton app à l'exécution, qui n'apparaissent pas dans le code partagé. C'est là que doivent vivre tes clés secrètes.

Le problème arrive quand l'IA, ou toi en allant vite, colle une clé directement dans le code ou dans un fichier .env versionné. Là, elle n'est plus protégée par les Secrets, elle est dans les fichiers du repl. Et si l'app est un front qui build (React, Vite), une clé utilisée côté navigateur finit dans le bundle servi, même rangée dans les Secrets : ce qui doit être secret ne doit pas être appelé depuis le front du tout.

Comment vérifier : ouvre ton app Replit déployée (pas l'éditeur, l'URL publique de l'app), clic droit, Inspecter, onglet Sources, et cherche service_role, sk_live, sk-. Regarde aussi si ton .env est accessible directement depuis l'URL. Si une clé apparaît, régénère-la chez son fournisseur et déplace son usage côté serveur.

L'app déployée contre l'éditeur

Nuance qui compte sur Replit. Il y a l'espace de travail (l'éditeur, souvent en replit.dev) et l'app déployée (en replit.app). Ce que tes utilisateurs visitent, c'est l'app déployée. C'est elle qu'il faut scanner, pas ta page vitrine ni l'éditeur.

Une app de présentation ne charge pas ta base, donc elle ne montre presque jamais de faille grave. Tu peux te croire propre parce que tu as regardé la mauvaise page. Vérifie l'URL où tes utilisateurs se connectent réellement, là où l'app affiche des données.

Ta base de données, verrouillée ou pas

Si ton app Replit utilise Supabase, tu retombes sur le verrou n°1 : le RLS (Row Level Security). Tant qu'il est désactivé sur une table, la clé publique visible dans ton app suffit à tout lire. Le geste manquant, c'est d'activer le RLS et de poser une règle par table.

Je détaille la faille et les règles à coller dans RLS désactivé : pourquoi ta base est lisible, et tu peux le vérifier toi-même avec les DevTools. Colmate ne va jamais interroger ta base : il repère la clé publique Supabase exposée côté client et te signale l'exposition probable à vérifier, sans y toucher.

Combien de temps pour tomber sur un secret exposé ?

Trois jours. Sur une vingtaine d'apps scannées au hasard pendant les premiers jours de Colmate, j'ai déjà trouvé un .env en clair, une clé d'API Gemini et une clé administrateur Supabase. Sans chercher, juste en passant les apps que je croisais dans des pubs Facebook, sur LinkedIn ou sur X.

Ce n'est pas une question de talent ni de malveillance. C'est que ces outils te laissent déployer avant d'avoir fermé les portes, et Replit encore plus que les autres puisque ton code et ta config sont, par défaut, à portée de clic. La trame de vérification vaut aussi pour Lovable, Bolt et v0.

La version rapide

Colmate lit ce que ton app Replit expose déjà publiquement et te sort la liste en trente secondes : .env ou clés accessibles, code source visible, en-têtes manquants, exposition probable de la base. Classé par gravité, avec le correctif prêt à coller dans ton IA. En lecture seule, sans accès à ton code, sans toucher à tes données.

Scanne ton app Replit avant de la lancer. Tu sauras tout de suite ce qui est à portée de clic.

FAQ

Un fichier .env est-il vraiment accessible sur Replit ?

Sur un repl public, oui, ton .env fait partie des fichiers visibles, et il peut aussi être servi directement selon la config. C'est pour ça que les Secrets Replit existent : ranger tes clés là plutôt que dans un .env versionné. Et un secret qui doit rester secret ne doit jamais être appelé depuis le front, même via les Secrets.

Les Secrets Replit suffisent-ils à protéger mes clés ?

Ils protègent les clés utilisées côté serveur, oui. Ils ne protègent pas une clé que ton front doit lire pour fonctionner : celle-là finit dans le bundle servi au navigateur, où qu'elle soit rangée. La règle reste la même : les appels avec clé secrète se font depuis le serveur, jamais depuis le navigateur.

Dois-je passer mon repl en privé pour être en sécurité ?

Passer un repl en privé cache ton code source et ta config aux curieux, ce qui est une bonne chose. Mais ça ne verrouille pas ta base de données ni ne cache une clé déjà exposée dans l'app déployée. Le privé règle l'exposition de l'éditeur, pas celle de l'app en ligne. Il faut traiter les deux.

Le réflexe avant de lancer

Avant de mettre ton app Replit en ligne, deux gestes : vérifie que ton repl et ton .env ne sont pas à la vue de tous, et ouvre ton app déployée comme un visiteur pour chercher tes clés dans le navigateur. Passe la checklist en un scan, ou reprends la checklist complète avant déploiement pour la faire à la main.