Livrer vite, c'est très bien, mais il y a une courte liste qui mérite un coup d'oeil avant d'ouvrir ton app au monde entier. Rien de tout cela n'exige d'être un expert en sécurité, et tout est vérifiable de l'extérieur en quelques minutes. Voici ce qui compte vraiment, pourquoi chaque point fait mal, et comment y remédier.
Comment les attaquants trouvent ces failles en quelques minutes
La plupart des piratages d'apps créées avec l'IA ne sont pas des attaques sophistiquées. Quelqu'un ouvre ton site, appuie sur F12, lit le JavaScript que ton app a déjà envoyé à son navigateur, et copie une URL que ton app appelle déjà. Les scanners automatisés font la même chose à grande échelle, en frappant des chemins courants comme /.env ou /.git sur des milliers de sites par jour. Tout ce qui suit est quelque chose qu'ils peuvent vérifier sans le moindre accès à ton code, et c'est précisément pour ça que tu devrais le vérifier en premier.
1. Aucun secret dans le frontend
Les clés d'API et les tokens ne doivent se trouver que sur le serveur. Quand un assistant IA « connecte » un service, il glisse souvent la clé directement dans le code côté client, où n'importe qui peut la lire dans les DevTools. Une clé Stripe sk_live_ divulguée peut déplacer de l'argent bien réel ; une clé Supabase service_role livre l'intégralité de ta base de données. Garde les clés secrètes dans les variables d'environnement du serveur et n'expose que les clés publiques conçues pour le navigateur. Voir les secrets que ton app divulgue dans le navigateur.
2. HTTPS et en-têtes de sécurité
Sers tout en HTTPS et redirige le HTTP vers celui-ci, pour que personne ne puisse lire ni altérer le trafic. Ajoute ensuite les en-têtes que les navigateurs utilisent pour défendre tes utilisateurs : Content-Security-Policy pour contenir les injections, Strict-Transport-Security pour verrouiller le HTTPS, et X-Frame-Options pour bloquer le clickjacking. La plupart des apps générées n'en embarquent aucun par défaut. Voir les en-têtes de sécurité HTTP expliqués.
3. Des règles de base de données (RLS) sur chaque table
Si tu utilises Supabase ou Firebase, ton app dialogue avec la base de données directement depuis le navigateur, de sorte que les règles de la base sont la seule chose qui se dresse entre un visiteur et tes données. Active le Row-Level Security sur chaque table (pas seulement les plus importantes) avec une politique de refus par défaut, et ne compte jamais sur le fait de cacher un bouton dans l'interface. Sans cela, n'importe qui disposant de la clé publique lit et écrit dans tes tables sans même se connecter, exactement la faille à l'origine de la vulnérabilité RLS de Lovable.
4. Aucun fichier sensible exposé
Assure-toi que .env, .git, les sauvegardes de base de données et les source maps ne sont pas accessibles depuis un navigateur. C'est étonnamment fréquent : une seule requête vers /.env peut livrer tous les secrets que ton app utilise, et des source maps publiées permettent à n'importe qui de reconstituer ton code d'origine. Bloque tout cela dans la configuration de ton hébergeur ou de ton framework.
5. CORS bien verrouillé
Une politique CORS permissive qui renvoie n'importe quelle origine avec les identifiants permet à un site malveillant de lire les données de tes utilisateurs en se servant de leur session. Limite les origines autorisées aux domaines que tu contrôles réellement, et ne combine jamais Access-Control-Allow-Origin: * avec les identifiants.
6. Cookies et sessions bien configurés
Les cookies de session doivent porter Secure (HTTPS uniquement), HttpOnly (illisibles depuis JavaScript, pour qu'une XSS ne puisse pas les voler) et SameSite (défense contre le CSRF). Ces trois attributs tiennent en une ligne de configuration et referment toute une catégorie de bugs de détournement de compte.
Ta checklist de 2 minutes avant le lancement
- Aucune clé
sk_live_,service_roleni clé privée dans ton JavaScript. - HTTPS imposé, avec CSP, HSTS et X-Frame-Options en place.
- Row-Level Security sur chaque table de la base de données.
.env,.git, sauvegardes et source maps non accessibles.- CORS limité à tes propres origines, sans joker combiné aux identifiants.
- Cookies avec Secure, HttpOnly et SameSite.
Juste régler ça
Au lieu de vérifier tout cela à la main, lance Scanaris : il contrôle ces points et une quarantaine d'autres sur ton site en ligne en 30 secondes, classe les résultats par impact, et te fournit un prompt prêt à coller pour corriger chacun d'eux avec ton IA, avant que quelqu'un d'autre ne les trouve.