Une Server Action Next.js s'exécute comme n'importe quelle requête POST : n'importe qui peut lui envoyer la même requête, même sans passer par votre interface, d'après la documentation Next.js. Posée derrière un Drupal headless, cette route devient un point d'écriture vers votre contenu. Avant de l'activer, il faut savoir ce que Next.js protège déjà, ce qui reste à votre charge, et dans quels cas une route API Next.js (aussi appelée Route Handler) ou l'API JSON:API de Drupal conviennent mieux qu'une Server Action. Nous distinguons ces trois chemins d'écriture, cadrons le point d'entrée Drupal, puis listons ce qu'il faut vérifier avant d'activer la première Server Action.
Ce que Next.js protège nativement
Le contrat implicite : une route POST publique
Masquer un formulaire derrière une page authentifiée ne crée pas de frontière de sécurité, précise la documentation Next.js. Une requête peut atteindre l'action sans passer par l'écran qui la déclenche d'habitude. Chaque Server Action doit donc vérifier elle-même qui appelle et ce qu'elle autorise, indépendamment de ce que montre l'interface.
Quatre garde-fous natifs
Next.js compare l'en-tête Origin à l'en-tête Host (ou X-Forwarded-Host) et rejette les requêtes qui ne correspondent pas. C'est une protection CSRF, pas une authentification. Le corps d'une Server Action est plafonné à 1 Mo par défaut, ajustable via serverActions.bodySizeLimit. Les identifiants d'action sont chiffrés à la compilation ; une Server Function jamais référencée côté client disparaît du bundle et n'a donc pas d'endpoint public. Les variables capturées par une action inline sont elles aussi chiffrées avant d'atteindre le client. En environnement multi-instance, cela suppose de fixer NEXT_SERVER_ACTIONS_ENCRYPTION_KEY sur une clé stable, partagée entre les instances.
Ce qui reste à votre charge : authentification, autorisation, validation, limitation de débit
La documentation Next.js renvoie explicitement à son guide Data Security pour l'accès aux données et la limitation de débit. Ce sont des responsabilités applicatives, pas des protections automatiques. Elle demande aussi de traiter les données du formulaire, les paramètres et les en-têtes comme non fiables, et de les valider dans l'action elle-même. Une validation de schéma, avec zod ou un équivalent, ne vérifie que la forme d'un objet. Un objet bien formé peut désigner un enregistrement que l'appelant ne possède pas : vérifier la propriété de la ressource à partir de la session serveur reste une étape distincte de la validation de forme.
Server Action, route API Next.js ou JSON:API Drupal : comment trancher
L'aller-retour en une requête : le cas d'usage légitime
Quand une Server Action déclenche une revalidation immédiate, Next.js exécute l'action puis réaffiche la route courante dans la même requête HTTP. Ce séquencement garde l'arbre serveur réaffiché cohérent avec le résultat qui l'a produit. C'est le cas d'usage le plus net : un formulaire léger, lié à une page, dont le résultat doit apparaître immédiatement. Corriger un profil ou ajouter un commentaire sous le contenu affiché en sont deux exemples.
Pourquoi Next.js séquence les Server Actions
Next.js dépile les Server Actions d'un même client une par une et déconseille de les paralléliser avec Promise.all. Si votre scénario a besoin de parallélisme, mieux vaut regrouper le travail dans une seule Server Action, multiplier les appels fetch depuis un Server Component, ou passer par une route API pour tout ce qui ne mute rien.
Préférer une route API ou l'API Drupal : lectures, clients tiers
Les routes API Next.js restent la bonne réponse dès que la requête ne touche à aucune mutation. L'API JSON:API de Drupal reste pertinente quand un client tiers, hors de votre propre front Next.js, doit lire ou écrire du contenu. Une Server Action n'est pas une URL stable pour ce cas : son identifiant provient des artefacts de build, change généralement à chaque déploiement, et tourne au moins tous les 14 jours même sans changement de code. Ce découplage entre routes API, Server Actions et JSON:API Drupal conditionne directement les contrats que vous maintenez ; nous détaillons ces arbitrages dans notre article sur les contrats d'API Next.js/Drupal.
Sécuriser le point d'entrée Drupal
JSON:API hérite des contrôles de Drupal
Le module JSON:API ne contourne aucun des mécanismes de sécurité existants et n'ajoute pas de couche propre. Il réutilise les fondations de Drupal, selon la documentation officielle du module. Un bug d'accès dans votre configuration Drupal se répercute donc tel quel sur l'API que consomme votre front Next.js.
Le mode lecture seule, actif par défaut
Le mode lecture seule de JSON:API est activé par défaut, aussi bien dans Drupal core que dans les versions 2.4 et supérieures du module contribué. L'exemple officiel de création de ressource passe par une authentification Basic, et l'écriture doit être explicitement activée dans l'administration, en cochant l'option correspondante. Vérifiez ce réglage site par site : l'écriture peut avoir été ouverte en amont, parfois sans que l'équipe front en soit informée.
Authentifier les écritures, réduire la surface exposée
Drupal documente un abonné d'événement qui retire toutes les routes DELETE de JSON:API et restreint POST et PATCH aux seuls types de contenu explicitement listés comme mutables. Ce mécanisme n'est pas actif par défaut : il doit être porté par un module personnalisé. Il donne tout de même un modèle clair, une liste blanche de types mutables, sans suppression possible par l'API. Drupal recommande aussi de déplacer la base /jsonapi vers un chemin non devinable. Activer l'écriture JSON:API sans cette liste blanche explicite est une erreur : cela transforme une API pensée pour la lecture en surface d'écriture ouverte à tous les types de contenu, par défaut.
Déni de service via Server Actions : périmètre et correctif
L'avis GHSA-p3m5-59mp-jv5r décrit des requêtes forgées qui provoquent une charge CPU excessive sur une application Next.js utilisant l'App Router avec au moins une Server Action, bloquant le traitement d'autres requêtes dans le même processus. Il concerne les versions npm next comprises entre 13.0.0 et 15.5.27, et entre 16.0.0 et 16.4.0, corrigées en 15.5.28 et 16.4.1. Classé High (8,2 sur 10 en CVSS v4), il n'a pas reçu de CVE à ce jour. Un point mérite d'être clair : la faille touche l'App Router de Next.js, pas Drupal ni l'API qu'il expose. Aucun contournement n'existe hors mise à jour ; les applications en Pages Router, ou qui n'utilisent aucune Server Action, ne sont pas concernées.
Checklist avant d'activer une Server Action
- Authentification et autorisation vérifiées dans l'action elle-même, jamais seulement par le rendu de l'interface qui la déclenche.
- Entrées traitées comme non fiables (données du formulaire, paramètres, en-têtes), et propriété de la ressource revérifiée côté serveur, pas seulement la forme du schéma.
- Limitation de débit mise en place. Ni Next.js ni Drupal ne publient de doctrine sur ce point : traitez-la dans votre propre couche applicative.
- Version de Next.js à jour face à l'avis GHSA-p3m5-59mp-jv5r, si vous êtes sur App Router avec des Server Actions.
- Côté Drupal : mode lecture seule vérifié, écriture limitée à une liste blanche de types mutables, chemin
/jsonapidéplacé, authentification exigée pour toute écriture. - Journalisation des écritures prévue dans votre propre couche applicative, pour la même raison : ni Next.js ni Drupal n'imposent de doctrine sur ce point.
Pour aller plus loin : authentifier l'edge Next.js face à Drupal
Une fois le point d'entrée Drupal cadré, la question suivante porte sur l'authentification côté edge et middleware Next.js : nous la traitons dans notre article sur l'edge et le middleware Next.js face à Drupal. Pour tracer ce qui se passe une fois l'écriture acceptée, côté logs et budgets d'erreur, nous en parlons dans notre article sur l'observabilité Next.js/Drupal.
Si vous avez un Drupal headless derrière un front Next.js et que vous ne savez pas exactement quelles routes sont ouvertes en écriture aujourd'hui, demandez un diagnostic.