Sécuriser son app Bolt.new avant de la mettre en prod

Les variables d'environnement mal préfixées

Bolt.new s'appuie sur Vite. Sous Vite, toute variable d'environnement préfixée VITE_ est délibérément embarquée dans le bundle JavaScript envoyé au navigateur — c'est le comportement documenté, pas un bug. Le problème arrive quand l'IA (ou toi, en copiant un exemple trouvé ailleurs) préfixe une clé qui ne devrait jamais quitter le serveur :

# .env — ne devrait jamais être préfixé VITE_
VITE_SUPABASE_SERVICE_ROLE_KEY=eyJhbGci...   # ❌ contourne RLS, finit dans le JS public
VITE_STRIPE_SECRET_KEY=sk_live_...            # ❌ clé secrète, finit dans le JS public

SUPABASE_SERVICE_ROLE_KEY=eyJhbGci...         # ✅ reste côté serveur
STRIPE_SECRET_KEY=sk_live_...                 # ✅ reste côté serveur

Une fois le préfixe posé, il n'y a plus de distinction entre une clé publique et une clé secrète du point de vue du bundler : les deux sont traitées comme "destinées au client" et embarquées telles quelles.

Aucun header de sécurité par défaut

Une app générée et déployée en quelques minutes n'a, par défaut, aucun des headers HTTP qui durcissent un site contre le détournement de clics, l'injection de script ou le vol de données via un sous-domaine tiers : Content-Security-Policy, Strict-Transport-Security, X-Frame-Options. Ce n'est spécifique à aucun outil de génération en particulier — c'est juste qu'un prompt qui décrit une fonctionnalité ne mentionne quasiment jamais ces headers, et l'IA ne les ajoute pas d'initiative.

Le correctif

Revérifie chaque variable d'environnement avant le déploiement : si elle contient un mot de passe, une clé secrète ou un token d'API tiers, elle ne doit jamais porter le préfixe VITE_. Pour les headers, ajoute-les explicitement selon l'hébergeur cible (exemple Vercel) :

// next.config.js / vercel.json — headers ajoutés explicitement
{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" }
      ]
    }
  ]
}

Détail des headers manquants les plus fréquents et pourquoi chacun compte : Headers de sécurité manquants.

App construite avec Bolt.new et déjà en ligne ? Scanne-la pour vérifier qu'aucune clé secrète n'a été embarquée côté client et que les headers de base sont en place.