Next.js sécurité : le sujet ne se limite pas à “mettre à jour le framework”. Avant une mise en production, il faut vérifier la version exacte, l’usage du middleware, l’hébergement choisi, les en-têtes HTTP et les dépendances React. Depuis 2024, plusieurs failles Next.js ont touché l’authentification, le cache, les Server Components et le self-hosting. Pour un dirigeant, l’enjeu est simple : éviter qu’un choix technique accélère le projet aujourd’hui mais augmente fortement le risque demain.
Next.js sécurité : ce qui change vraiment pour un projet web
Next.js est un framework JavaScript basé sur React, utilisé pour créer des sites rapides, des plateformes SaaS, des espaces clients ou des sites éditoriaux avec rendu côté serveur. Le rendu côté serveur signifie qu’une partie de la page est préparée par le serveur avant d’arriver dans le navigateur. C’est excellent pour la performance et le SEO, mais cela crée aussi des points d’entrée supplémentaires.
Le risque n’est pas théorique. En mars 2025, la faille CVE-2025-29927 a été publiée avec un score CVSS 9.1, donc critique. Elle permettait de contourner certains contrôles d’autorisation via un en-tête interne, x-middleware-subrequest, dans des versions de Next.js antérieures à 12.3.5, 13.5.9, 14.2.25 et 15.2.3.
Pour une PME, la conséquence possible est très concrète : un espace normalement protégé, par exemple un back-office, un extranet ou une page de validation de commande, peut devenir accessible si l’architecture s’appuie mal sur le middleware. Le middleware est une couche de traitement exécutée avant la page, souvent utilisée pour filtrer les accès.
Ce point mérite un arbitrage dès le cadrage. Next.js peut être un très bon choix pour un projet ambitieux, mais seulement si l’équipe prévoit un budget de maintenance. À ce budget, mieux vaut parfois un socle plus simple, bien maintenu, qu’une architecture moderne mais laissée sans suivi après la livraison.
Les failles récentes à connaître avant de déployer
Les vulnérabilités publiées par Vercel, GitHub, le NVD ou l’équipe React montrent un schéma clair : les zones sensibles sont l’authentification, le cache, les Server Components, les réécritures d’URL et certaines configurations self-hosted. Les Server Components sont des composants React exécutés côté serveur pour réduire le JavaScript envoyé au navigateur.
Voici les repères utiles pour discuter avec un prestataire, sans entrer dans le détail du code :
| Faille ou avis | Année | Risque principal | Versions ou correctifs connus |
|---|---|---|---|
| CVE-2025-29927 | 2025 | Contournement d’autorisation via middleware | Correctifs : 12.3.5, 13.5.9, 14.2.25, 15.2.3 |
| GHSA-gp8f-8m3g-qvj9 | 2024 | Cache poisoning, score CVSS 7.5 | Affecte >=13.5.1 <14.2.10, correctifs 13.5.7 et 14.2.10 |
| CVE-2025-55182 / CVE-2025-66478 | 2025 | Exécution de code à distance liée aux React Server Components | React CVSS 10.0, Next.js 15.x et 16.x à mettre à jour immédiatement |
| CVE-2025-55183 | 2025 | Exposition de code source via Server Actions | Correctifs en 16.0.9, 15.5.8, 15.4.9, 15.3.7, 15.2.7, 15.1.10, 15.0.6 |
| GHSA-c4j6-fc7j-m34r | 2026 | SSRF en self-hosting avec serveur Node.js intégré et WebSocket upgrades | Correctifs 15.5.16 et 16.2.5, déploiements Vercel indiqués non affectés |
Le cache poisoning consiste à faire stocker une mauvaise réponse par le cache, puis à la servir à d’autres visiteurs. C’est discret, parfois difficile à diagnostiquer, et particulièrement gênant sur un site à fort trafic. Les failles SSRF, elles, permettent à un attaquant de pousser le serveur à appeler des ressources internes ou externes non prévues.
Sur les projets que nous menons, nous voyons souvent une confusion entre “le site fonctionne” et “le site est prêt pour la production”. Ce sont deux états différents. La production suppose un niveau de contrôle supplémentaire : journalisation, mises à jour, sauvegardes, tests de sécurité et plan de retour arrière.
Vercel, OVH, serveur dédié : l’hébergement change le niveau de risque
Next.js est historiquement très associé à Vercel, la plateforme créée par l’éditeur du framework. Ce n’est pas anodin. Plusieurs avis de sécurité précisent que certains déploiements Vercel ne sont pas affectés par des failles touchant le self-hosting, notamment des cas liés aux rewrites, au cache ou aux WebSocket upgrades.
Le self-hosting, c’est l’hébergement sur votre propre infrastructure ou chez un fournisseur comme OVHcloud, Scaleway, AWS, Google Cloud ou un serveur managé par un infogéreur. Il peut être pertinent pour des raisons de coût, de souveraineté, de conformité ou d’intégration métier. Mais il transfère davantage de responsabilité technique à l’équipe qui exploite le site.
Le piège que les non-techniciens ignorent : “Next.js fonctionne sur Node.js” ne veut pas dire que toutes les fonctionnalités se comportent pareil partout. Les CDN (réseaux de diffusion), les proxies, les rewrites, les fonctions serveur et les adapters peuvent modifier le comportement réel. Next.js 16.2, annoncé en 2026 avec un travail sur les plateformes et adapters, va justement dans ce sens : le contexte de déploiement compte.
Si vous comparez les options, intégrez aussi le choix du runtime JavaScript, c’est-à-dire l’environnement qui exécute le code serveur. Pour comprendre les différences entre Node.js, Bun et Deno, ce guide sur le choix d’un runtime JavaScript en 2026 complète utilement la réflexion.
Checklist de sécurité avant mise en production
Une revue de Next.js sécurité n’a pas besoin d’être interminable pour être utile. Elle doit surtout être systématique. L’objectif est de détecter les erreurs coûteuses avant que le site soit exposé publiquement.
- Vérifier la version exacte de Next.js, React et React DOM, puis comparer avec les avis GitHub/Vercel publiés.
- Contrôler que le middleware ne porte pas seul l’autorisation d’accès aux zones sensibles.
- Filtrer les en-têtes entrants dangereux au niveau CDN ou reverse proxy, en particulier les en-têtes internes.
- Configurer une CSP, Content Security Policy, qui limite les scripts autorisés pour réduire les risques XSS.
- Tester le cache : pages privées jamais mises en cache, pages publiques correctement invalidées.
- Prévoir un processus de mise à jour avec environnement de préproduction et sauvegarde.
- Surveiller les logs et alertes d’erreurs après chaque déploiement.
La CSP mérite une attention particulière. La documentation officielle Next.js indique qu’elle sert à réduire les risques de XSS, clickjacking et injection de code. Elle recommande aussi Next.js v13.4.20 ou plus récent pour une bonne gestion des nonces, ces jetons temporaires qui autorisent certains scripts de manière contrôlée.
Attention tout de même : une CSP mal conçue donne une fausse impression de sécurité. Si elle autorise trop de domaines, ou si des données non fiables sont injectées dans des scripts beforeInteractive, elle perd une grande partie de son intérêt. En mai 2026, des avis Vercel/GitHub ont justement listé des sujets XSS liés à l’App Router, aux nonces CSP et aux scripts précoces.
Budget et délais : ce qu’il faut prévoir honnêtement
Sur le marché français, une revue de sécurité légère avant mise en ligne d’un site Next.js coûte souvent autour de 1 500 à 4 000 € HT selon le périmètre. Elle couvre généralement versions, configuration, en-têtes HTTP, routes sensibles, dépendances et recommandations de correction. Pour une application métier avec authentification, paiements ou données personnelles, un audit plus poussé peut dépasser 6 000 à 12 000 € HT.
Les délais sont raisonnables si le sujet est anticipé. Comptez deux à cinq jours ouvrés pour une revue ciblée, puis quelques jours supplémentaires pour corriger proprement. Si l’audit arrive la veille du lancement, le coût augmente rarement sur la facture initiale, mais il explose dans les arbitrages : report de campagne, stress des équipes, corrections rapides et dette technique.
Honnêtement, cette techno ne se justifie que si vous acceptez son rythme de maintenance. Next.js évolue vite. C’est une force pour la performance, le SEO et l’expérience utilisateur, mais cela impose une veille régulière, surtout avec l’App Router, les Server Actions et les Server Components.
Un site vitrine simple peut parfois être mieux servi par WordPress bien sécurisé, un générateur statique ou une architecture plus classique. À l’inverse, pour un espace client, un produit SaaS ou un site éditorial connecté à un CMS headless, Next.js reste très pertinent si la sécurité est prévue dans le budget de run.
Les erreurs fréquentes qui coûtent cher après le lancement
La première erreur consiste à mettre l’authentification “au bord” du site, puis à supposer que tout est protégé. Le middleware peut filtrer, mais les vérifications d’accès doivent aussi exister côté serveur, au plus près des données. Sinon, une faille de contournement devient beaucoup plus grave.
Autre erreur : confondre mise à jour mineure et risque mineur. Les correctifs de sécurité arrivent parfois dans des versions qui semblent banales. Reporter une montée de version pendant six mois peut laisser le site exposé à des attaques documentées, donc plus faciles à reproduire.
Le choix des prestataires compte également. Une équipe capable de livrer une interface soignée n’a pas toujours l’habitude de l’exploitation, de la supervision et des correctifs d’urgence. Si vous hésitez entre ressources internes, freelance et agence, ce point sur l’organisation du développement pour une petite entreprise aide à poser les bons critères.
Enfin, la sécurité doit être reliée au cycle projet. Les erreurs classiques de cadrage, de recette ou de responsabilités mal définies fragilisent aussi la partie technique. Les risques listés dans les erreurs à éviter lors de la création d’un site se retrouvent souvent dans les projets Next.js, avec un impact plus fort lorsque l’application manipule des données clients.
Côté agence, le réflexe est de traiter la sécurité comme un lot de production, pas comme une option de fin de projet. Cadrer ce type de déploiement en amont évite la plupart des mauvaises surprises : version cible, hébergement, responsabilités de maintenance, budget de correction et plan d’urgence en cas d’avis critique.
FAQ sur Next.js sécurité
Next.js est-il sécurisé pour un site professionnel ?
Oui, Next.js peut être sécurisé pour un site professionnel, à condition d’être maintenu et configuré correctement. Le risque vient surtout des versions non patchées, du self-hosting mal maîtrisé et des contrôles d’accès trop centralisés dans le middleware.
Quelle version de Next.js faut-il utiliser en production ?
Il faut utiliser une version supportée et corrigée selon les derniers avis Vercel/GitHub. En pratique, vérifiez toujours la branche exacte du projet, car les correctifs publiés en 2025 et 2026 varient selon Next.js 13, 14, 15 ou 16.
Vercel est-il plus sûr qu’un hébergement OVH ou AWS ?
Vercel réduit certains risques spécifiques à Next.js, car la plateforme est conçue pour ce framework et certains avis indiquent des déploiements Vercel non affectés. OVHcloud, AWS ou Scaleway restent possibles, mais demandent plus de maîtrise sur Node.js, CDN, proxy, logs et mises à jour.
Combien coûte un audit sécurité Next.js ?
Pour une revue ciblée avant lancement, prévoyez souvent autour de 1 500 à 4 000 € HT en France. Une application avec comptes utilisateurs, données personnelles ou paiement nécessite généralement un budget plus élevé.