Sécurité Next.js, Astro, Nuxt et WordPress Headless en 2026

Le passage au headless n'a pas supprimé la surface d'attaque. Il l'a déplacée. Le bilan 2025-26 montre où : React Server Components (CVE-2025-55182, exécution de code à distance non authentifiée, publié 3 décembre 2025), les server islands et l'endpoint image d'Astro, la mise en cache de payload Nuxt derrière un CDN, les packages npm, et un backend WordPress qui exécute toujours du PHP. Une export entièrement statique sans runtime serveur supprime bien la plupart des risques au niveau du framework. Beaucoup de sites « statiques » ne le sont pas vraiment, cependant. Vous trouverez ci-dessous les incidents classés par framework, puis les secrets, la CSP, la chaîne d'approvisionnement, les contrôles d'origine et de périphérie WordPress, en finissant par un tableau de durcissement que vous pouvez adapter à votre propre stack.

Pourquoi « statique signifie invulnérable » n'est plus vrai

Disons-le clairement d'abord : si votre build produit des fichiers HTML, CSS et JS bruts, et qu'un CDN les sert, il n'y a pas de serveur framework à attaquer. Pas d'endpoint React Server Components. Pas d'action serveur. Pas de middleware à contourner. C'est une surface d'attaque réellement réduite, et c'est pour cela que l'ancien pitch Jamstack avait du poids.

Mais regardez ce que la plupart des projets Next.js, Astro et Nuxt déploient réellement en 2026. Une action serveur pour le formulaire de contact. Un middleware qui vérifie un cookie. Un endpoint d'optimisation d'image. Des server islands pour un header personnalisé. ISR ou revalidation à la demande. Chacun de ceux-ci signifie qu'un processus écoute les requêtes, analyse les entrées, et détient des variables d'environnement. C'est un serveur. Il n'en a juste pas l'air dans votre repo.

La question n'est donc pas « ce site est-il headless ? » C'est « qu'est-ce qui s'exécute au moment de la requête ? » Trois réponses honnêtes existent :

• Rien. Sortie entièrement statique. Votre risque se situe dans le pipeline de build et le CMS, pas le framework.
• Un petit ensemble connu d'endpoints. Optimisation d'image, un gestionnaire de formulaire. Patchez-les, restreignez-les, limitez leur débit.
• Un runtime d'application complet. SSR, actions serveur, authentification, accès base de données. Traitez-le comme n'importe quelle app web, car c'en est une.

J'ai fait la comparaison architecturale avec WordPress ailleurs (voir headless vs WordPress security), donc je ne vais pas le répéter. Cet article est le bilan des incidents et ce qu'il faut en faire.

Next.js : React2Shell, actions serveur et le piège du proxy

React2Shell

CVE-2025-55182 (React) et CVE-2025-66478 (Next.js) ont été publiées le 3 décembre 2025. Critique. Exécution de code à distance non authentifiée via des requêtes crafted aux React Server Components. Selon le changelog de Vercel, les versions Next.js affectées sont >=14.3.0-canary.77, 15.x et 16.x utilisant l'App Router. Les releases Next.js patchées sont 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 et 16.0.7, avec React corrigé dans 19.0.1, 19.1.2 et 19.2.1.

La rapidité compte ici. Datadog Security Labs a signalé un code d'exploit public et des tentatives d'exploitation actives d'ici le 5 décembre 2025. Deux jours. Si votre processus de patch s'exécute sur un rythme mensuel, cet écart représente l'exposition.

Vercel livre npx fix-react2shell-next pour bumper les versions affectées. Quelle que soit la route que vous prenez, confirmez la version corrigée actuelle pour votre ligne de release dans l'avis lié, car les suites ont changé les cibles.

Les suites du 11 décembre

Le 11 décembre 2025, l'équipe Next.js a publié une nouvelle mise à jour de sécurité couvrant deux problèmes supplémentaires :

• CVE-2025-55184, déni de service (critique). Une requête App Router peut bloquer le serveur. Le premier correctif était incomplet ; le correctif complet est suivi sous CVE-2025-67779.
• CVE-2025-55183, exposition du code source (moyen). Une requête malveillante peut faire en sorte qu'une Server Function retourne le code source compilé d'autres Server Functions. Tout ce qui y est en dur fuit. Les secrets lus depuis l'environnement à l'exécution ne fuient pas.

Le Pages Router n'a pas été affecté, et il n'y a pas de contournement. Mettez à jour. Les versions corrigées incluent 14.2.35, 15.5.9 et 16.0.10 (consultez l'avis pour votre ligne).

La leçon sur les server actions est sans détour : une server action est un endpoint HTTP public avec une convention d'appel plus pratique. Traitez ses arguments comme des entrées hostiles. Autorisez à l'intérieur. Et ne jamais écrire un secret sous forme de littéral de chaîne dans un fichier qu'une server function peut atteindre.

Le middleware n'est pas une limite d'autorisation

CVE-2025-29927, divulgué le 21 mars 2025 (CVSS 9.1), permettait à un en-tête x-middleware-subrequest malveillant de contourner entièrement le middleware. Si votre seule vérification d'authentification se trouvait dans le middleware, elle était contournée. L'article de Datadog liste les correctifs dans 12.3.5, 13.5.9, 14.2.25 et 15.2.3. Les applications hébergées par Vercel étaient protégées au niveau de l'infrastructure. Les applications auto-hébergées étaient exposées jusqu'à la correction.

Next.js 16 renomme middleware.ts en proxy.ts et l'exécute sur le runtime Node.js par défaut ; middleware.ts est déprécié. Le renommage est honnête, je pense. Un proxy se place devant l'application. Il peut rediriger, réécrire, ajouter des en-têtes. Il ne devrait pas être la seule chose qui se dresse entre un étranger et vos données.

Où placer la véritable vérification :

1. Dans la couche données, à côté de la requête qui retourne les lignes.
2. Dans chaque server action qui modifie quelque chose.
3. Dans les gestionnaires de routes, par route.
4. Dans le proxy uniquement comme redirection de commodité pour les utilisateurs déconnectés, jamais comme verrou.

Si supprimer proxy.ts exposerait des données, votre autorisation est au mauvais endroit.

Astro : îles serveur, endpoints d'images et chemins de middleware

La valeur par défaut d'Astro est statique, ce qui est une force. Mais trois avis de sécurité de 2025 ont frappé les pièces qui ajoutent un runtime.

XSS des îles serveur. CVE-2025-64764, publié le 19 novembre 2025, critique (CVSS 7.1). Une XSS réfléchie via le paramètre slots de l'endpoint des îles serveur. Elle affectait toute application utilisant des îles serveur, même lorsque le composant île n'utilise aucun slot. Les versions 5.15.6 et antérieures étaient affectées ; 5.15.8 l'a corrigée. Les détails se trouvent dans l'avis de sécurité GitHub.

SSRF de l'endpoint d'images. CVE-2025-58179 affectait l'adaptateur @astrojs/cloudflare (11.0.3 à 12.6.5). Avec output 'server' et le service d'images de compilation par défaut, l'endpoint d'images ne validait pas les URLs, ce qui permettait la falsification de requête côté serveur. SSRF est problématique car le serveur fait la requête depuis l'intérieur de votre réseau, où il peut atteindre les services de métadonnées ou les APIs internes.

Contournement du chemin du middleware. Astro 5.15.8 a aussi corrigé un contournement de normalisation de chemin utilisant des URLs doublement encodées (CVE-2025-64765). Même famille d'erreur que le tour d'en-tête Next.js : une autorisation qui dépend de l'URL ayant une certaine apparence.

Vérifiez les plages de versions exactes dans les avis de sécurité withastro/astro avant de décider si vous êtes affecté. Je ne vais pas deviner les limites que je ne peux pas pointer.

Astro 6 et CSP intégrée

Astro 6 fournit une API CSP sous security.csp. Selon l'annonce bêta d'Astro 6, elle haché les scripts et styles fournis (SHA-256 par défaut), et elle fonctionne en build et preview mais pas en dev. Ce dernier point surprend les gens : une page qui semble correcte sous astro dev peut se casser lorsque la politique s'applique dans un build de production. Testez toujours la sortie construite.

Si vous construisez des sites Astro pour vos clients et voulez cette sécurité intégrée dès le départ, notre page développement Astro explique comment nous mettons en place les projets.

Nuxt : empoisonnement du cache payload et ce que `runtimeConfig.public` expose

CVE-2025-27415

Publié le 19 mars 2025. Critique, CVSS 7.5, l'impact porte sur la disponibilité. La condition : vous exécutez Nuxt derrière un CDN qui ignore la chaîne de requête dans sa clé de cache. Un attaquant demande quelque chose comme /?/_payload.json . Nuxt rend le JSON pour cette requête. Le CDN le met en cache sous la clé pour / et sert ce JSON à tous les visiteurs. Répétable à chaque expiration du cache. Affectées : versions 3.0.0 à avant 3.16.0 ; corrigé en 3.16.0 (avis).

Remarquez quel type de bogue c'est. Le code de Nuxt et la configuration du CDN se comportaient tous deux correctement isolément. Ensemble, ils ont cassé votre page d'accueil. Donc la leçon va au-delà de « mettre à jour Nuxt » : la configuration de la clé de cache du CDN fait partie de la sécurité applicative. Quelqu'un dans votre équipe doit s'en charger, et cela doit être documenté, pas laissé par défaut sur le tableau de bord.

Une vérification rapide en staging, en utilisant votre propre domaine de staging seulement : demandez la page avec une chaîne de requête inhabituelle, voyez ce qui revient, puis demandez l'URL propre et confirmez qu'elle est toujours du HTML. Si votre couche de cache permet d'ignorer les chaînes de requête pour la performance, assurez-vous que les routes internes du framework en sont exclues.

Ce que `runtimeConfig.public` expose

Nuxt divise runtimeConfig en clés privées (serveur seulement) et runtimeConfig.public (envoyé au navigateur). Le nom est l'avertissement. N'importe quoi sous public se trouve dans le payload de la page pour que n'importe qui puisse le lire. Mettre une clé publique Stripe là, pas de problème. Mettre un token admin CMS là et vous l'avez publié.

Secrets et variables d'environnement sur les trois

Chaque framework a une règle de préfixe, et le préfixe signifie « envoyer au navigateur » :

Lisez la documentation de chaque framework sur ce point, car les détails diffèrent (Next.js inlinéise les valeurs NEXT_PUBLIC_ dans le bundle au moment de la compilation, ce qui signifie aussi qu'en modifier une nécessite une recompilation). Le principe ne diffère pas. Si une variable a un préfixe public, traitez-la comme imprimée sur la page d'accueil.

Trois habitudes attrapent la plupart des erreurs :

• Ne mettez jamais un token ayant des droits d'écriture derrière un préfixe public, même « temporairement ».
• Cherchez dans votre sortie compilée (.next/static , dist/, .output/public) des fragments de token avant de déployer.
• Donnez à votre front end une credential en lecture seule, étroitement limitée, pour le CMS, séparée de tout ce qu'un éditeur utiliserait.

La leçon de CVE-2025-55183

That Next.js source-exposure bug is a neat illustration. It could return compiled source of Server Functions. Secrets read from the environment at runtime weren't in that source. Secrets pasted into the code as literals were. The framework bug was the framework's fault; the leaked API key was ours. After patching, if a literal secret ever lived in a server function on an affected version, assume it was readable and rotate it. Moving it to an env var is the fix for next time, not for the past.

En-têtes de sécurité et CSP pour les sites Jamstack

L'hébergement statique rend facile d'oublier les en-têtes car il n'y a pas de fichier de configuration serveur dans le dépôt. Mais les en-têtes sont là où vous obtenez une protection bon marché et réelle contre les retombées XSS (comme le problème des îles serveur Astro ci-dessus).

Ensemble de base à déployer sur chaque site : Content-Security-Policy , Strict-Transport-Security , X-Content-Type-Options: nosniff , une Referrer-Policy , et frame-ancestors (dans CSP) ou X-Frame-Options.

Nonce ou hash, pas `unsafe-inline`

Une CSP qui autorise 'unsafe-inline' pour les scripts aide à peine contre les XSS. Vous avez deux vraies options :

• Les hashes. Hashes SHA-256 au moment de la compilation de chaque script et style en ligne. Fonctionne bien pour la sortie statique car le contenu ne change pas par requête. C'est ce qu'Astro 6's security.csp automatise.
• Les nonces. Une valeur aléatoire générée par requête, ajoutée à l'en-tête et à chaque balise script. Nécessite un serveur ou une fonction edge pour la générer, donc c'est plus adapté au SSR qu'aux fichiers statiques. Next.js documente un modèle de nonce utilisant sa couche proxy.

Choisissez selon le modèle de rendu. Purement statique : hashes. Dynamique : nonces.

Listez chaque origine tierce, par directive

C'est la partie fastidieuse et c'est là que les politiques échouent. Analytics, gestionnaires de balises, polices, intégrations vidéo, widgets de chat, fournisseurs de formulaires, votre hôte d'images CMS. Chacun doit être listé sous la bonne directive : script-src , connect-src , img-src , font-src , frame-src. Un widget qui charge un script depuis une origine et appelle une API sur une autre en a besoin des deux.

Un exemple d'en-tête, pour montrer la forme seulement (remplacez vos vraies origines, et le nonce doit être généré par requête) :

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM' https://analytics.example.com; connect-src 'self' https://api.example.com; img-src 'self' data: https://cms.example.com; frame-ancestors 'none'; base-uri 'self'

Commencez par Content-Security-Policy-Report-Only , collectez les violations pendant une ou deux semaines, corrigez la liste, puis appliquez-la. Et conservez un fichier d'inventaire court des origines tierces et qui a demandé chacune. Six mois plus tard, personne ne se souvient pourquoi un widget de chat est dans script-src.

La chaîne d'approvisionnement npm : chalk, debug et Shai-Hulud

Votre framework peut être corrigé et votre serveur verrouillé, et une dépendance peut quand même gâcher votre semaine. Deux événements de 2025 montrent comment.

chalk et debug, 8 septembre 2025. Un mainteneur a été victime de phishing avec un faux e-mail de réinitialisation 2FA de npmjs.help. Les attaquants ont publié des versions malveillantes d'environ 18 paquets, y compris chalk et debug. Le payload visait à voler l'activité des portefeuilles crypto depuis les bundles navigateur. Les paquets ont été supprimés en environ 2 à 2,5 heures, selon l'analyse d'Upwind. Deux heures c'est court. Mais un travail CI qui a résolu des versions fraîches dans cette fenêtre a expédié le payload en production.

Shai-Hulud, septembre 2025. L'alerte de la CISA du 23 septembre 2025 décrit un ver auto-répliquant qui a compromis plus de 500 paquets npm. Il a récolté des tokens GitHub et des clés cloud (AWS, GCP, Azure), les a publiés sur des dépôts GitHub publics nommés Shai-Hulud, et s'est republié dans d'autres paquets en utilisant les propres credentials npm des victimes. Une deuxième vague en novembre 2025 aurait touché environ 796 paquets (reportage secondaire, donc traitez le chiffre comme rapporté).

Les contrôles qui les auraient contenus

Aucun incident n'avait besoin d'un exploit astucieux. Les deux reposaient sur une confiance automatique dans « latest ». Donc :

1. Commitez votre lockfile et installez avec `npm ci `. Cela installe exactement ce que le lockfile dit et échoue si package.json ne correspond pas. Pas de dérive silencieuse vers une version empoisonnée.
2. Ajoutez un délai d'attente. N'adoptez pas les versions l'heure où elles sont publiées. pnpm documente un paramètre d'âge minimum de version pour cela. Un délai d'un jour aurait complètement évité la fenêtre chalk/debug.
3. Désactivez les scripts d'installation où vous le pouvez. Des vers comme Shai-Hulud s'exécutent via des scripts de cycle de vie. Une ligne .npmrc d'exemple : ignore-scripts=true. Puis mettez en liste blanche les quelques paquets qui ont réellement besoin d'une étape de compilation.
4. Délimitez les jetons CI. Un job de build n'a que rarement besoin de droits de publication ou de clés cloud larges. Des identifiants à courte durée de vie et avec le strict minimum de privilèges signifient qu'un jeton volé ne rapporte pas grand-chose.
5. Suivez les conseils du CISA. Examinez les fichiers de verrouillage, y compris les dépendances imbriquées, vérifiez les caches d'artefacts, épinglez les versions connues comme sûres, renouvelez les identifiants des développeurs, exigez une authentification multifacteur résistante au hameçonnage sur npm et GitHub, et activez l'analyse des secrets, Dependabot et la protection des branches.

Le même doute s'applique aux outils d'IA qui se trouvent maintenant dans les environnements de développement. J'ai expliqué comment auditer les compétences Claude Code, les plugins et les serveurs MCP parce qu'ils constituent une autre façon pour du code tiers de se rapprocher de vos jetons.

WordPress sans tête : découpler cache le thème, pas le PHP

Voici la partie qui surprend les équipes. Passer en mode sans tête supprime la couche de thème publique. Cela n'élimine pas WordPress. L'application PHP, la base de données, l'API REST et wp-admin sont tous encore là, généralement sur un nom d'hôte public, parce que le front end a besoin de les atteindre.

wp2shell

L'exemple de 2026 est brutal. CVE-2026-63030 (confusion de route batch dans l'API REST, CVSS 9.8) chaîné avec CVE-2026-60137 (injection SQL dans author__not_in de WP_Query, CVSS 5.9) donne une exécution de code à distance non authentifiée sur WordPress 6.9.0 à 7.0.1. Installations par défaut. Aucun plugin requis. Le point d'entrée est /wp-json/batch/v1. Les correctifs sont arrivés le 17 juillet 2026 dans les versions 7.0.2, 6.9.5 et 6.8.6, comme le précise la FAQ de Tenable.

Les attaquants ont été rapides. Patchstack a vu les premières tentatives d'exploitation environ 90 minutes après la publication de la version 7.0.2, a bloqué plus de 65 000 tentatives provenant de plus de 1 500 adresses IP, et a constaté que 97 % ciblaient le point de terminaison batch. Un détail de plus a de l'importance pour ceux qui s'appuient sur un pare-feu : les règles WAF sur l'URL seule ne suffisent pas, parce que WordPress accepte rest_route dans le corps de la requête POST. Une règle qui correspond à /wp-json/batch/v1 dans le chemin le rate.

Verrouiller le back-end

L'objectif : faire de l'origine WordPress quelque chose que les étrangers ne peuvent pas atteindre, plutôt que quelque chose qui espère simplement être corrigé à temps.

• Gardez l'origine hors d'Internet public si possible. Liste d'adresses IP autorisées, proxy authentifiant, ou réseau privé entre le front end et le CMS. Si vous extrayez le contenu au moment de la compilation pour un site statique, l'origine n'a besoin de communiquer qu'avec votre runner de compilation.
• Exposez uniquement les champs que le front end utilise. Réduisez les réponses REST et les schémas GraphQL. Moins de données à la sortie, moins à exploiter.
• Désactivez les routes inutilisées, y compris le point de terminaison batch, si rien dans votre stack ne l'appelle.
• Limitez WPGraphQL. Désactivez l'introspection publique et les requêtes non authentifiées sauf si vous en avez vraiment besoin.
• Délimitez les mots de passe d'application et les jetons d'aperçu. Un par intégration, privilège minimum, révoqués quand l'intégration se termine.
• Gardez les mises à jour automatiques du noyau activées. Avec une fenêtre d'exploitation de 90 minutes, un jour de patch manuel hebdomadaire est le mauvais rythme.

Si vous préférez confier cette partie à des spécialistes, notre service de sécurité WordPress couvre le verrouillage et la surveillance du back-end. Pour l'architecture autour, consultez le guide WordPress sans tête 2026 et notre page de développement WordPress sans tête.

Hébergement et contrôles de périphérie

Les plateformes diffèrent dans ce qu'elles protègent, et il vaut la peine de connaître les spécificités plutôt que de supposer. Prenez CVE-2025-29927 : les applications hébergées sur Vercel étaient protégées au niveau de l'infrastructure tandis que les solutions auto-hébergées ne l'étaient pas. C'est un avantage réel et documenté d'une plateforme gérée. Netlify et Cloudflare exécutent également des couches de protection à leur périphérie (fonctionnalités WAF, atténuation des DDoS, règles gérées, selon le plan). L'auto-hébergement vous donne le contrôle et place ces couches sur votre liste de tâches.

Le cadrage honnête : les protections de périphérie vous achètent du temps. Elles ne remplacent pas les correctifs. Une règle de plateforme qui bloque un motif d'exploit aujourd'hui ne dit rien sur le prochain avis, et une configuration auto-hébergée avec un pipeline de patch bien géré peut être parfaitement solide.

Éléments à configurer, quel que soit votre hébergeur :

• Des règles WAF qui inspectent les corps de requête, pas seulement les chemins. Le détail wp2shell rest_route est l'exemple à retenir.
• Des limites de débit sur les gestionnaires de formulaires, les actions serveur, les routes de connexion et tout point de terminaison qui déclenche du travail coûteux. Cela atténue aussi les bugs de déni de service comme CVE-2025-55184.
• Les `remotePatterns` d'image. Dans Next.js, images.remotePatterns restreint les hôtes distants à partir desquels l'optimiseur d'images effectuera une récupération. Astro dispose de paramètres équivalents pour les domaines et patterns d'image. Autorisez uniquement votre hôte CMS. Un proxy d'image ouvert est une invitation à une SSRF.
• Révision de la clé de cache. Suite à l'incident Nuxt, identifiez ce que votre CDN ignore.
• Protection de l'origine. Configurer l'origine de l'application pour n'accepter le trafic que depuis votre CDN ou la plateforme où la configuration le permet, afin que les attaquants ne puissent pas contourner la périphérie.

Si vous construisez sur Next.js avec une base de données derrière, la page de développement Next.js et Supabase montre comment nous délimitons l'accès côté serveur.

La liste de contrôle de durcissement

Adaptez ceci à votre pile. Chaque incident nommé ci-dessous provient des sources citées précédemment ; confirmez les versions corrigées actuelles dans chaque avis lié plutôt que de faire confiance à un tableau (y compris celui-ci) pour les numéros de version.

FAQ

Le Pages Router est-il affecté par les problèmes Next.js de décembre 2025 ?

Pour CVE-2025-55183 (exposition du code source) et CVE-2025-55184 (déni de service), l'avis Next.js décrit le chemin affecté comme l'App Router avec Server Functions, et dit que le Pages Router n'est pas affecté par l'exposition du code. Ne lisez pas cela comme « sûr pour toujours ». React2Shell ciblait aussi les React Server Components dans l'App Router, et vous devez quand même être sur une version patchée. Vérifiez l'avis de décembre 2025 pour votre ligne de version exacte.

Dois-je faire tourner les secrets après un correctif ?

Si un secret a été en dur dans une fonction serveur sur une version Next.js affectée, oui. Supposez qu'il aurait pu être lu, car le bug a renvoyé le code source compilé. Faites-le tourner, puis déplacez le remplacement vers une variable d'environnement d'exécution. Les secrets qui ont seulement été lus depuis l'environnement n'étaient pas dans ce code source, donc l'argument d'exposition est beaucoup plus faible pour eux.

Comment rester au courant des avis sans lire chaque journal des modifications ?

Suivez les avis de sécurité GitHub pour les dépôts dont vous dépendez (Next.js, withastro/astro, Nuxt), et activez les alertes Dependabot pour vos propres dépôts. Abonnez celui qui est responsable du patching à ces flux, pas une boîte de réception partagée que personne ne lit. Pour le core WordPress, gardez les mises à jour automatiques activées et ajoutez un flux de vulnérabilités comme celui de Patchstack.

Puis-je laisser wp-admin public si le front end ne récupère le contenu qu'au moment de la construction ?

Vous pouvez, mais vous ne devriez pas. Si le front end n'a besoin de l'origine que pendant les constructions, il n'y a aucune raison de l'exposer à tout le monde. Mettez en liste d'autorisation votre exécuteur de construction et les adresses IP de vos éditeurs, ou placez un proxy authentifiant devant. Les éditeurs avec des adresses IP changeantes sont la plainte habituelle, et un proxy avec authentification unique la résout.

La vitesse de patching et la configuration de la clé de cache sont les deux choses que les équipes se trompent le plus souvent : les exploits Next.js et WordPress sont arrivés dans les jours ou les heures suivant la divulgation, et le bug Nuxt n'existait que parce qu'un CDN ignorait la chaîne de requête. Vérifiez ce qui s'exécute réellement au moment de la requête, autorisez dans la couche de données plutôt que le proxy, et gardez l'origine WordPress hors d'Internet ouvert.