Sécurité pour ton appli Replit

« Sécurité Replit », ce sont deux choses qu'il vaut mieux séparer. La première, c'est le Repl et son déploiement : où vivent les secrets, qui voit tes fichiers, quelle URL est publique et quel port est exposé. La seconde, c'est le code que Replit Agent génère, généralement un serveur Express avec React et une base Postgres, qui embarque les failles classiques d'un backend écrit à la hâte. Ce guide couvre les deux, avec un bloc pour le fichier que l'Agent lit à chaque requête, un prompt de revue avant de déployer et les vérifications de l'extérieur.

Partie 1 : protéger ton Repl et ton déploiement

Secrets : l'onglet Secrets, pas le code

Replit a un gestionnaire de secrets qui stocke les variables chiffrées et les expose au processus comme variables d'environnement, sans qu'elles apparaissent dans aucun fichier. C'est le seul bon endroit pour les clés d'API, la chaîne de connexion de la base et le secret de session. L'erreur habituelle, c'est que l'Agent, ou toi pressé, les écrive dans un .env, un config.json ou directement dans le code. Ces fichiers font partie du Repl : ils sont visibles dans un Repl public, copiés au fork et déployés.

Repls publics et URL de développement

Un Repl public montre tous ses fichiers à n'importe qui, y compris ceux que tu as oubliés : sauvegardes, un vieux .env, des exports de données. Avant de le rendre public, vérifie l'arborescence complète. Et tant que le Repl tourne, l'URL de développement .replit.dev répond à qui l'a ; ce n'est pas un environnement privé, c'est un serveur sur internet avec tes données de test.

Déploiements

Le déploiement publie l'appli sur un sous-domaine .replit.app ou ton domaine, avec TLS automatique. Les variables d'environnement du déploiement se configurent à part de celles du développement, donc vérifie que la production ne pointe pas vers la base de test. Seul le port que tu déclares est exposé, mais tout ce que ce port sert est public : routes d'API, fichiers statiques et ce que le serveur renvoie par erreur. Replit n'ajoute pas d'en-têtes de sécurité ; c'est ton serveur qui les pose.

Base de données et authentification intégrées

La base Postgres intégrée te remet sa chaîne de connexion comme secret ; ne la copie jamais dans un fichier. Si tu utilises Replit Auth, la session est gérée par Replit et ton code reçoit l'utilisateur déjà identifié, mais chaque route doit toujours vérifier qu'il y a une session et que cet utilisateur peut faire ce qu'il demande.

Partie 2 : les failles que l'Agent met dans ton code

• Des secrets dans des fichiers. La clé OpenAI ou la chaîne Postgres dans .env, dans une constante ou dans un config.json servi en statique.
• Des routes d'API sans authentification. Le tableau de bord vérifie la session dans React ; /api/users répond à n'importe qui.
• Des dossiers statiques trop larges. express.static pointant vers la racine du projet sert package.json, .replit, le code du serveur et tout fichier oublié. Et sans index.html, certains serveurs listent le répertoire.
• Des routes de débogage et de seed. /api/debug, /api/seed, /api/reset créées pour tester et déployées.
• CORS ouvert avec identifiants. cors() sans options plus des cookies de session : n'importe quel site agit au nom de tes utilisateurs.
• Des requêtes SQL par concaténation. Une chaîne construite avec ce qui arrive du formulaire au lieu de paramètres.
• Des envois de fichiers sur disque servis tels quels. N'importe quel utilisateur envoie un fichier et n'importe quel visiteur le télécharge par son nom.
• Ni limite de requêtes ni en-têtes. Un endpoint qui appelle un modèle payant sans plafond, et pas un seul en-tête de sécurité.

Un bloc pour que l'Agent l'applique toujours

Replit Agent lit le fichier replit.md de ton projet comme contexte permanent. Ajoute cette section :

## Règles de sécurité
- Les clés, la chaîne de la base de données et le secret de session se lisent depuis process.env et vivent dans l'onglet Secrets. Jamais dans .env, config.json ni dans le code.
- Toute route d'API qui lit ou écrit des données vérifie la session et les permissions de l'utilisateur sur le serveur. Les vérifications dans React ne comptent pas.
- express.static ne sert que le dossier de build du frontend ou public/, jamais la racine du projet.
- Pas de routes de débogage, de seed ou de reset en production.
- CORS avec une liste explicite d'origines ; jamais le joker avec des identifiants.
- Toutes les requêtes SQL utilisent des paramètres. Toute entrée de formulaire est validée sur le serveur.
- Les fichiers envoyés sont stockés hors du dossier public et servis seulement après vérification des permissions.
- En-têtes de sécurité avec helmet et limite de requêtes sur les routes qui coûtent.

Et les en-têtes dans Express, en deux lignes :

import helmet from 'helmet';
app.use(helmet());
app.use(helmet.hsts({ maxAge: 63072000, includeSubDomains: true, preload: true }));

Un prompt de revue avant de déployer

Passe en revue la sécurité de ce projet et ne change rien pour l'instant. Réponds avec une liste :
1. Clés, chaînes de connexion ou secrets écrits dans des fichiers ou dans le code, avec fichier et ligne.
2. Routes d'API qui lisent ou écrivent des données sans vérifier la session, et routes de débogage, de seed ou de reset.
3. Dossiers servis en statique et quels fichiers ils exposent.
4. Configuration de CORS et des cookies de session.
5. Requêtes SQL construites par concaténation et entrées non validées.
6. Où sont stockés les fichiers envoyés et comment ils sont servis.
7. S'il existe des en-têtes de sécurité et une limite de requêtes.
Pour chaque point, propose le changement exact et attends ma confirmation.

Vérifie le résultat de l'extérieur

curl -sI https://tondomaine.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
for p in .env .replit package.json config.json .git/config server.js uploads/; do printf "%-14s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tondomaine.com/$p"; done
curl -s -o /dev/null -w "%{http_code}\n" https://tondomaine.com/api/users

Attendu : en-têtes présents, 404 sur toute la liste de fichiers et un 401 ou 403 sur la route d'API sans session. Un 200 sur package.json ou .replit signifie que tu sers la racine du projet. Scanaris fait ces vérifications et une quarantaine d'autres en 30 secondes : il cherche les fichiers exposés et les listages de répertoire, les endpoints qui répondent sans session, les secrets dans le JavaScript, les en-têtes, CORS, cookies et TLS, et te donne un fix prompt pour chaque échec à coller dans le chat de l'Agent. Et il peut rescanner chaque jour, parce qu'une régénération peut ramener une faille que tu avais déjà corrigée.

Questions fréquentes

Les valeurs de l'onglet Secrets sont-elles visibles dans un Repl public ?

Non, les secrets ne sont pas affichés et ne sont pas copiés au fork. Ce qui est visible, c'est tout le reste : fichiers, code et toute clé écrite dedans au lieu de dans Secrets.

L'URL de développement est-elle privée ?

Non. Tant que le Repl tourne, elle répond à quiconque a le lien. Ne l'utilise pas avec de vraies données et ne la partage pas en pensant que tu es le seul à la voir.

Replit pose-t-il des en-têtes de sécurité sur les déploiements ?

Non. Il fournit le TLS et le domaine, mais les en-têtes sont envoyés par ton serveur. Avec Express, helmet les ajoute en deux lignes ; avec d'autres frameworks, leur équivalent.