flawopen.com/Référence/Next.js Server Actions CSRF

CSRF des Server Actions Next.js : vérification Origin et configuration sûre

Origin

Origine de la page initiatrice envoyée par le navigateur ; Next.js compare son hôte à celui de l’application.

Host / X-Forwarded-Host

Valeur d’hôte utilisée dans la comparaison. Le proxy doit définir ou valider les informations transférées.

allowedOrigins

Liste explicite d’hôtes Origin supplémentaires acceptés par les Server Actions. Next.js accepte les hôtes exacts et les motifs génériques.

Authorization

Décision propre à l’action : l’utilisateur authentifié peut-il effectuer cette opération sur cet objet précis ?

Fonctionnement du contrôle CSRF intégré aux Server Actions

Limites importantes : Origin absent et allowedOrigins

Configurez le proxy inverse comme partie de la frontière de sécurité

Next.js utilise x-forwarded-host ou host pour la comparaison. Le proxy en périphérie doit supprimer les en-têtes transférés par le client et définir la valeur à partir d’un nom public validé ; l’application ne doit être accessible que via ce proxy fiable. Si le proxy transmet son nom interne, configurez seulement l’origine publique nécessaire dans allowedOrigins. Ne corrigez pas l’écart en faisant confiance à des hôtes arbitraires.

// Every subdomain, including delegated or tenant-controlled names, is trusted.
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['**.example.com'],
    },
  },
};

// Add only the public host that this deployment requires.
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['admin.example.com'],
    },
  },
};

// Configure the edge to overwrite X-Forwarded-Host
// with the validated public hostname.

Avis concernant Host : risque connexe, distinct du CSRF

La confiance accordée à Host a causé des vulnérabilités SSRF documentées dans les Server Actions. CVE-2024-34351 touchait les versions auto-hébergées antérieures à 14.1.1 lorsqu’une action effectuait une redirection relative commençant par / et que Host pouvait être modifié. Un avis Vercel de juillet 2026 décrit une SSRF et l’exposition possible de valeurs internes si un serveur personnalisé laisse le client contrôler les en-têtes liés à l’hôte ; il indique les versions corrigées 15.5.21 et 16.2.11. Ce sont des problèmes de confiance de l’hôte, pas la preuve que le contrôle Origin contre le CSRF est contourné.

Pour l’avis de 2026, passez à une version corrigée. Dans l’intervalle, fixez ou validez Host et X-Forwarded-Host à la périphérie ou sur le proxy. L’avis documente aussi __NEXT_PRIVATE_ORIGIN comme mesure supplémentaire à partir de la version 14.2.0. Vérifiez les branches affectées et prises en charge dans l’avis avant de l’utiliser.

Autorisez et validez chaque Server Action

La documentation Next.js indique de traiter les arguments comme hostiles et de vérifier si l’utilisateur peut invoquer chaque action. L’exemple vulnérable fait confiance à l’identifiant d’objet fourni par l’appelant. Le modèle corrigé authentifie, valide l’identifiant et applique la condition de propriété dans la mutation de base de données.

"use server";

export async function deleteInvoice(invoiceId: string) {
  await db.invoice.delete({ where: { id: invoiceId } });
}

"use server";

import { z } from "zod";
import { requireUser } from "@/auth";

const invoiceIdSchema = z.string().uuid();

export async function deleteInvoice(rawId: unknown) {
  const user = await requireUser();
  const invoiceId = invoiceIdSchema.parse(rawId);
  const result = await db.invoice.deleteMany({
    where: { id: invoiceId, ownerId: user.id },
  });
  if (result.count !== 1) throw new Error("Forbidden");
}

Liste de contrôle CSRF et autorisation pour Server Actions

• ✓Au proxy, rejetez les noms d’hôte publics inconnus et remplacez Host/X-Forwarded-Host du client par des valeurs validées.
• ✓Laissez allowedOrigins vide sauf besoin réel d’un proxy ou de plusieurs origines ; autorisez uniquement des hôtes maîtrisés avec le motif le plus étroit.
• ✓Dans chaque Server Action, authentifiez l’utilisateur, validez les arguments à l’exécution et autorisez l’objet ou l’opération précise.
• ✓Traitez l’absence de Origin comme une anomalie journalisée à étudier ; l’avertissement du framework ne décide pas des autorisations.
• ✓Auditez séparément les Route Handlers personnalisés : ils n’héritent pas du contrôle Origin des Server Actions. Implémentez et testez une protection CSRF adaptée aux mutations authentifiées par cookie.
• ✓Suivez les avis de sécurité Next.js et mettez à jour les déploiements affectés, surtout les serveurs personnalisés qui acceptent les en-têtes d’hôte fournis par les clients.

Références

• Next.js Docs — serverActions et allowedOrigins
• Next.js — Réfléchir à la sécurité dans Next.js
• Avis Vercel — CVE-2024-34351 : SSRF dans Server Actions
• Avis Vercel — GHSA-89xv-2m56-2m9x : SSRF sur serveurs personnalisés (juillet 2026)
• CWE-352 — Falsification de requête intersite (CSRF)
• CWE-918 — Falsification de requête côté serveur (SSRF)