Lancer une appli Next.js avec Cursor, v0 ou Bolt est rapide, mais la vitesse cache des failles que tu ne vois pas avant que quelqu'un ne les trouve à ta place. Cette checklist couvre le strict minimum avant d'appuyer sur deploy.
Variables d'environnement : attention à NEXT_PUBLIC
Tout ce qui commence par NEXT_PUBLIC_ est intégré dans le bundle du navigateur. N'importe qui peut le lire en ouvrant les DevTools. Ne mets jamais là une clé d'API privée, un jeton de service ou le secret de ta base de données.
Réserve ce préfixe aux valeurs vraiment publiques, comme l'URL de ton API ou un ID d'analytics. Les variables sans préfixe vivent uniquement sur le serveur : utilise-les pour les clés privées et lis-les seulement depuis les Server Components, les API routes ou les Server Actions.
API routes : valide et autorise toujours
Une API route n'est pas privée juste parce qu'elle est dans ton dossier. C'est une URL publique que n'importe qui peut appeler avec curl. Vérifie la session de l'utilisateur dans chaque handler, pas seulement dans l'interface. Un bouton caché n'empêche personne d'appeler l'endpoint directement.
Valide le corps de la requête avant de toucher à la base de données, et ne fais jamais confiance au frontend pour envoyer des données propres. Un attaquant écrit son propre frontend.
En-têtes de sécurité
Par défaut, Next.js n'envoie aucun en-tête défensif. Dans next.config.js, ajoute au moins Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options et une Content-Security-Policy. Ces en-têtes réduisent le clickjacking, le sniffing de type et l'exécution de scripts injectés.
Secrets qui fuient vers le client
Il est facile qu'une clé privée finisse dans un Client Component par erreur, surtout quand l'IA réécrit des fichiers. Cherche dans ton bundle final des chaînes comme sk_, service_role ou des URL de webhooks. Si elles apparaissent dans le JavaScript servi, elles sont déjà compromises : fais-les tourner et déplace-les sur le serveur.
Fichiers qui ne devraient pas être accessibles
Assure-toi que .env, .git et les fichiers de sauvegarde ne sont pas servis en production. Un .env accessible par URL est le chemin le plus direct vers une base de données vidée. Vérifie aussi que package.json n'expose pas de chemins internes ni de dépendances qui trahissent ta stack.
Vérifie tout ça en 30 secondes
Passer cette liste à la main à chaque deploy est fastidieux et vite oublié. Scanaris fait des contrôles en lecture seule sur ton site publié : en-têtes, secrets exposés dans le JavaScript, fichiers sensibles accessibles et réglages des cookies. Chaque trouvaille vient avec un prompt prêt à coller dans ton IA pour que tu corriges sans deviner. Scanne-le avant d'annoncer ton lancement.