Checklist sécurité Next.js pour la production (2026)

Une checklist sécurité Next.js pour 2026 : correctifs, Server Actions, accès aux données, secrets, proxy, en-têtes, CSP, images, dépendances et supervision.

Points clés

Next.js a connu deux failles critiques en 2025 : un contournement des autorisations via le middleware (CVE-2025-29927) et React2Shell (CVE-2025-55182, CVSS 10,0). Appliquer les correctifs en quelques jours, et non en quelques semaines, est le premier contrôle.

Chaque Server Action est un endpoint POST public. Validez les entrées et vérifiez l'authentification et les autorisations dans chacune d'elles, pas seulement dans l'interface.

Faites passer tous les accès aux données par une Data Access Layer exécutée uniquement côté serveur, qui autorise chaque lecture et ne renvoie que les champs dont la page a besoin.

Ne comptez jamais sur le seul middleware (désormais proxy) pour les autorisations. Utilisez-le pour des redirections rapides ; contrôlez l'accès là où les données sont lues.

Tout ce qui est préfixé par NEXT_PUBLIC_ est intégré au bundle envoyé au navigateur. Gardez les secrets sans préfixe et côté serveur.

Ajoutez des en-têtes de sécurité et une Content Security Policy à base de nonce, limitez les sources distantes de next/image et, en auto-hébergement, exécutez l'application avec un utilisateur non root et des accès sortants restreints.

Une checklist sécurité Next.js est une liste de contrôles qui permettent de sécuriser une application Next.js en production : application des correctifs du framework, autorisations côté serveur, gestion des secrets, en-têtes HTTP et hygiène de l'hébergement. Next.js estompe la frontière entre code serveur et code client dans une même base de code, ce qui est productif et facile à mal faire. Cette checklist correspond à ce que nous examinons en premier quand nous auditons une application Next.js, classée selon la fréquence à laquelle chaque point ressort comme un constat grave.

La checklist en un coup d'œil

#	Contrôle	Pourquoi c'est important
1	Framework et React à jour, sur la dernière version de votre branche	Deux failles critiques Next.js/React ont été exploitées en 2025 en quelques heures ou quelques jours
2	Chaque Server Action valide ses entrées et vérifie elle-même l'authentification	Les Server Actions sont accessibles par une requête POST directe, quoi qu'affiche l'interface
3	Les accès aux données passent par une couche serveur qui autorise chaque lecture	Empêche la fuite d'enregistrements par n'importe quel composant ou action
4	Les autorisations ne sont pas appliquées uniquement dans le middleware/proxy	Un contrôle dans le proxy peut être contourné ; c'est exactement ce qu'a permis CVE-2025-29927
5	Aucun secret dans des variables `NEXT_PUBLIC_` ni dans les bundles client	Ces valeurs sont intégrées à du JavaScript que tout le monde peut télécharger
6	En-têtes de sécurité et CSP à base de nonce	Limite les dégâts des scripts injectés et du clickjacking
7	`next/image` limité à des hôtes distants précis	Un joker transforme votre serveur en proxy d'images ouvert
8	Aucun rendu de HTML non assaini	`dangerouslySetInnerHTML` sur du contenu utilisateur, c'est une XSS directe
9	Limitation de débit (rate limiting) et protection anti-bots sur les formulaires, les actions et l'authentification	Bloque le credential stuffing, le spam et les attaques sur les coûts
10	Hébergement durci : utilisateur non root, système de fichiers en lecture seule, trafic sortant restreint	Circonscrit une compromission quand une faille du framework passe entre les mailles
11	Journaux, alertes et plan de réponse aux incidents écrit	Vous l'apprenez par la supervision, pas par vos clients

Dans les applications Next.js que nous avons auditées en 2026, 7 sur 10 comptaient au moins une Server Action sans contrôle d'autorisation, et la moitié exposait au client plus de données que la page n'en affichait. C'est par ces deux points qu'il faut commencer.

1. Appliquez rapidement les correctifs du framework

Deux failles critiques de 2025 montrent pourquoi la vitesse d'application des correctifs est le premier contrôle :

Faille	Ce qu'elle permettait	Premières versions corrigées
CVE-2025-29927, contournement du middleware (mars 2025)	Un en-tête `x-middleware-subrequest` forgé permettait aux requêtes d'échapper entièrement au middleware, y compris aux autorisations qui y étaient faites	12.3.5, 13.5.9, 14.2.25, 15.2.3
CVE-2025-55182, React2Shell (décembre 2025)	Exécution de code à distance sans authentification via les React Server Components	React 19.0.1, 19.1.2, 19.2.1 ; Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

D'après le post-mortem de Vercel, les applications hébergées sur Vercel n'étaient pas concernées par le contournement du middleware, contrairement aux applications auto-hébergées lancées avec next start ou output: 'standalone'. React2Shell touchait toutes les applications utilisant les React Server Components ; nos notes de terrain décrivent à quoi ressemblait son exploitation.

Ce qu'il faut mettre en place :

Des mises à jour automatiques des dépendances avec Dependabot ou Renovate, les mises à jour de sécurité étant fusionnées et déployées le jour même.
Une veille sur les avis de sécurité : les avis de sécurité Next.js et le blog de React.
Un pipeline de déploiement fiable, pour que livrer un correctif au pied levé soit une routine et non un risque.
Une mise à niveau vers le dernier correctif de votre branche, pas vers la première version corrigée : les correctifs suivants règlent souvent des problèmes découverts ensuite.

2. Traitez chaque Server Action comme un endpoint public

Le guide Next.js sur la sécurité des données est explicite : une Server Action exportée est accessible par une requête POST directe, même si aucun composant de votre interface ne l'appelle. Masquer un bouton n'est pas un contrôle d'accès.

Chaque Server Action doit :

Valider ses entrées avec un schéma (par exemple Zod), sans jamais se fier aux types fournis par le client.
Authentifier l'appelant à partir de la session.
Autoriser l'action précise sur la ressource précise.
Ne renvoyer que ce dont l'appelant a besoin.

"use server";

import { z } from "zod";
import { getSession } from "@/lib/auth";
import { canEditInvoice, updateInvoice } from "@/lib/dal/invoices";

const Input = z.object({ invoiceId: z.string().uuid(), note: z.string().max(500) });

export async function addInvoiceNote(raw: unknown) {
    const input = Input.parse(raw);
    const session = await getSession();
    if (!session) throw new Error("Unauthenticated");
    if (!(await canEditInvoice(session.user, input.invoiceId))) throw new Error("Forbidden");
    await updateInvoice(input.invoiceId, { note: input.note });
}

Le contrôle d'autorisation appartient à l'action et aux données, pas à la page qui affiche le formulaire. Notre article sur la structuration des autorisations explique comment garder ces contrôles cohérents dans une base de code importante.

3. Placez l'accès aux données derrière une couche serveur

Le même guide recommande une Data Access Layer pour les nouveaux projets : un ensemble de fonctions exécutées uniquement côté serveur, seules autorisées à lire la base de données, qui vérifient les autorisations à chaque appel et renvoient de petits objets de transfert de données (DTO) plutôt que des enregistrements complets.

Commencez chaque module par import "server-only", pour que son import depuis un composant client fasse échouer le build.
Renvoyez des DTO qui ne contiennent que les champs dont l'interface a besoin. Un objet utilisateur transmis à un composant client est sérialisé en entier vers le navigateur, y compris les champs que vous n'affichez jamais.
Les API expérimentales de taint de React permettent de marquer les objets qui ne doivent jamais atteindre le client, comme filet de sécurité supplémentaire, et non comme substitut au filtrage.

4. Ne comptez pas sur le middleware (proxy) pour les autorisations

Next.js 16 a renommé le middleware en proxy. C'est un bon endroit pour des contrôles rapides et optimistes, comme rediriger les utilisateurs déconnectés vers la page de connexion. Ce n'est pas le bon endroit pour votre unique contrôle d'autorisation : CVE-2025-29927 a montré que le middleware pouvait être contourné, et le guide Next.js sur l'authentification recommande de vérifier de nouveau la session au plus près des données. Contrôlez l'accès dans la Data Access Layer, ainsi que dans chaque Server Action et chaque Route Handler.

5. Gardez les secrets hors du navigateur

Selon la documentation Next.js sur les variables d'environnement, les variables préfixées par NEXT_PUBLIC_ sont intégrées au moment du build dans le JavaScript envoyé au navigateur. Tout ce qui porte ce préfixe est public.

Seuls les identifiants d'analytics, les clés publiques et les valeurs du même ordre doivent utiliser ce préfixe.
Recherchez les secrets dans vos bundles compilés avant chaque mise en production : grep -r "sk_live\|BEGIN PRIVATE KEY" .next/static.
Gardez les fichiers .env* hors de Git, et renouvelez tout secret qui a déjà été commité ou exposé.
Après un incident de sécurité, renouvelez tout ce que l'application pouvait lire, comme Vercel l'a recommandé après React2Shell.

6. Configurez les en-têtes de sécurité et une Content Security Policy

Configurez les en-têtes dans next.config avec headers() :

En-tête	Valeur recommandée
`Strict-Transport-Security`	`max-age=31536000; includeSubDomains`
`X-Content-Type-Options`	`nosniff`
`Referrer-Policy`	`strict-origin-when-cross-origin`
`Permissions-Policy`	Désactivez ce que vous n'utilisez pas, par exemple `camera=(), microphone=(), geolocation=()`
`Content-Security-Policy`	Au minimum `default-src 'self'`, `frame-ancestors 'self'`, `object-src 'none'`, `base-uri 'self'`

Définissez aussi poweredByHeader: false pour ne plus annoncer le framework utilisé.

Une CSP stricte nécessite un nonce par requête, afin que seuls vos propres scripts s'exécutent. Le guide Next.js sur la CSP montre comment le générer dans proxy et le transmettre à l'application. Les nonces imposent le rendu dynamique ; pour des sites essentiellement statiques, une politique qui autorise 'self' et une liste explicite d'origines tierces constitue une première étape raisonnable.

7. Limitez les sources distantes de `next/image`

L'optimiseur d'images télécharge et redimensionne les images distantes sur votre serveur. Listez des hôtes précis dans images.remotePatterns plutôt qu'un joker ; sinon, n'importe qui peut utiliser votre serveur, et votre facture de bande passante, comme proxy d'images.

8. N'affichez jamais de HTML non assaini

React échappe le texte par défaut. dangerouslySetInnerHTML désactive ce mécanisme. Si vous affichez sous forme de HTML du contenu utilisateur, du texte enrichi issu d'un CMS ou du Markdown, assainissez-le d'abord (par exemple avec rehype-sanitize ou DOMPurify), et n'y injectez jamais directement des données issues de la requête.

9. Limitez le débit des formulaires, des actions et de l'authentification

La connexion, l'inscription, la réinitialisation du mot de passe, les formulaires de contact et les Server Actions coûteuses ont besoin d'une limitation de débit (rate limiting) et d'une protection anti-bots. Appliquez-les en bordure de réseau (une règle de CDN ou de WAF) ou dans le handler, et ajoutez un challenge comme Cloudflare Turnstile sur les formulaires publics. Sans ces protections, le credential stuffing et le spam de formulaires ne sont pas une hypothèse, mais une question de temps.

10. Durcissez les déploiements auto-hébergés

Si vous hébergez vous-même Next.js dans Docker ou sur un VPS :

Exécutez le processus Node.js avec un utilisateur non root, et un système de fichiers en lecture seule quand c'est possible.
Ne montez jamais le socket Docker dans le conteneur de l'application.
Restreignez les accès réseau sortants à ce dont l'application a besoin. Dans les incidents React2Shell que nous avons traités, c'est l'absence de restriction du trafic sortant qui a permis aux attaquants de télécharger des mineurs et des outils de second niveau.
Placez l'application derrière un reverse proxy ou un CDN, et supprimez en bordure les en-têtes internes comme x-middleware-subrequest.

11. Supervisez, et sachez quoi faire en cas d'incident

Des journaux centralisés pour l'application et le proxy, conservés assez longtemps pour mener une enquête.
Des alertes sur une consommation CPU inhabituelle, des connexions sortantes inattendues et des pics de réponses 4xx/5xx.
Un inventaire des secrets et de l'endroit où chacun est utilisé, pour qu'un renouvellement prenne des heures et non des jours.
Un plan de réponse aux incidents court et écrit : qui décide, qui corrige, qui parle aux clients.

Questions fréquentes

Next.js est-il sécurisé ? Le framework est activement maintenu et corrige rapidement les failles critiques, mais la plupart des problèmes réels viennent du code applicatif : des Server Actions sans contrôle d'autorisation, des données surexposées au client et des secrets dans des variables publiques. Une application Next.js sécurisée a besoin des contrôles ci-dessus, quel que soit l'historique du framework lui-même.

Le middleware suffit-il à protéger mes pages ? Non. Utilisez-le pour les redirections et les contrôles rapides, et appliquez les autorisations là où les données sont lues et modifiées. CVE-2025-29927 permettait de contourner entièrement le middleware sur les applications auto-hébergées.

Ai-je besoin d'une Content Security Policy ? Pour toute application qui gère des comptes, des paiements ou des données personnelles, oui. C'est la principale défense qui fonctionne encore quand une faille d'injection passe entre les mailles.

À quelle fréquence faut-il revoir la sécurité d'une application Next.js ? À chaque mise à niveau majeure du framework, avant le lancement de fonctionnalités importantes, et au moins une fois par an. Les systèmes critiques gagnent à bénéficier d'une surveillance continue des dépendances.

Nous appliquons cette checklist dans chaque audit technique d'une application Next.js, et notre équipe de réponse aux incidents de sécurité prend en charge les cas où le problème est déjà survenu. Si vous souhaitez faire examiner votre application Next.js, ou la maintenir à jour dans le cadre d'un contrat de maintenance, parlons-en. Pour une vue d'ensemble de ce que couvre un audit, consultez ce que comprend un audit technique.

Sources

Next.js, How to think about data security in Next.js (en anglais)
Next.js, Authentication guide, Content Security Policy guide et environment variables (en anglais)
Vercel, Postmortem on Next.js middleware bypass et GHSA-f82v-jwr5-mffw (CVE-2025-29927) (en anglais)
Équipe React, Critical Security Vulnerability in React Server Components (CVE-2025-55182) (en anglais)
OWASP, Next.js Security Cheat Sheet (en anglais)

Tous les articles →