NEXT_PUBLIC_ : quand vos variables d'environnement finissent dans le navigateur
Une convention mal comprise
Dans Next.js, la règle est simple : une variable d'environnement préfixée NEXT_PUBLIC_ est inlinée dans le bundle JavaScript au moment du build. Elle est ensuite servie à chaque visiteur de votre site, lisible en clair dans les sources du navigateur.
La règle est simple, mais ses conséquences sont systématiquement sous-estimées. Lors de nos audits de SaaS construits sur Next.js, nous retrouvons dans les bundles publics :
service_role keys Supabase — c'est-à-dire un accès total à la base, RLS contournéComment ça arrive
Personne ne met une clé secrète côté client volontairement. Les scénarios réels :
Le renommage de facilité
Un appel API échoue côté client parce que la variable n'est pas définie. Message d'erreur obscur, deadline qui approche. Quelqu'un renomme SUPABASE_SERVICE_KEY en NEXT_PUBLIC_SUPABASE_SERVICE_KEY, ça marche, on passe à autre chose. La clé est maintenant publique.
Le composant qui change de camp
Un composant serveur qui utilisait une variable privée devient composant client ("use client") lors d'un refactoring. La variable n'est plus disponible, même réflexe : on la préfixe.
L'IA qui suggère
Les assistants de code proposent régulièrement le préfixe NEXT_PUBLIC_ comme solution quand une variable est undefined côté client. C'est techniquement la bonne réponse à la mauvaise question.
Ce qu'il faut retenir
Le préfixe NEXT_PUBLIC_ n'est pas un mécanisme de configuration, c'est une déclaration de publication. Avant de l'utiliser, posez la question : « est-ce que j'accepte que cette valeur figure dans le code source public de mon site ? »
Légitime : URL publique de votre API, clé *publishable* Stripe, clé *anon* Supabase (conçue pour être publique, à condition que la RLS soit correcte), identifiant d'un outil d'analytics.
Jamais : clé service_role, clé secrète Stripe, credentials SMTP, tokens d'API tiers facturés à l'usage.
Checklist de vérification
grep -r "NEXT_PUBLIC_" .env* et justifier chaque variable une par une.next/static/chunks/)Notre audit Next.js inclut l'analyse des bundles de production : nous y trouvons des secrets exposés dans environ un tiers des applications testées. Vérifiez les vôtres avant quelqu'un d'autre.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
CVE-2026-32541 : contournement du middleware Next.js — analyse et correction
Une vulnérabilité critique dans le middleware Next.js permettait de contourner l'authentification. Analyse technique de la faille et guide de correction pour les SaaS RH.
Next.js : les erreurs de sécurité courantes dans les applications Server Components
Server Actions exposées, data fetching non sécurisé, middleware contourné. Les failles spécifiques à Next.js App Router que nous trouvons en audit.
Réinitialisation de mot de passe : les 7 erreurs qui ouvrent vos comptes
Le flow « mot de passe oublié » est la porte d'entrée préférée des attaquants sur les SaaS : tokens prévisibles, liens sans expiration, host header injection. Les 7 erreurs que nous trouvons le plus souvent en audit.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.