Sécurité Next.js : De la Server Action au "React2Shell" (La Checklist d'Architecture 2026)

Il existe un malentendu fondamental qui persiste en 2026 autour des Server Actions de Next.js.
La magie du framework ("C'est juste une fonction asynchrone !") nous fait parfois oublier la réalité de l'infrastructure : toute Server Action est un endpoint HTTP public (POST), accessible par n'importe qui.

Certes, Next.js fait son travail : les IDs d'actions sont non-déterministes (hachés), les requêtes sont limitées aux POST, et les headers Origin sont vérifiés pour contrer le CSRF basique.

C'est solide pour la couche transport.

Mais ces protections ne comprennent rien à votre logique métier. Elles n'empêcheront pas un utilisateur authentifié de modifier un ID qu'il n'est pas censé toucher, ni un attaquant d'envoyer un payload JSON malveillant.

Si le terme "React2Shell" (RCE via React) peut sembler dramatique, il illustre une réalité technique : connecter directement une entrée utilisateur à une fonction serveur sans garde-fous est un risque inacceptable.

Voici la checklist de sécurité et d'architecture que j'applique pour durcir mes applications Next.js.

Le principe "Public API by Default"

C'est la posture mentale de base. Considérez que chaque argument passé à votre Server Action est untrusted (non fiable). L'attaquant n'a pas besoin de passer par votre UI ; il peut rejouer une requête via cURL.

La Checklist :

• Double Auth : Ne vous reposez pas uniquement sur le Middleware. Le Middleware protège la route (URL), mais une fois la page chargée, l'invocation de l'Action doit revérifier l'identité (AuthN) via auth() et les permissions (AuthZ).

• IDOR : Ne jamais utiliser un ID venant du client sans vérifier l'ownership.

Architecture : Séparation et "Inline" Actions

Bien que Next.js chiffre et signe les variables capturées dans les closures, l'utilisation excessive de Server Actions "Inline" encourage le couplage fort et les erreurs d'inattention (capture involontaire de données sensibles).

La Checklist :

• Logique Pure : Déplacez votre logique métier dans des fichiers server-only (Services). La Server Action ne doit être qu'un contrôleur (Gateway).

• Scope Propre : Évitez de définir des actions complexes à l'intérieur des composants.

La Validation d'Entrée (Zod, par exemple, est non-négociable)

Le typage TypeScript disparait au Runtime. Envoyer un objet typé depuis le client ne garantit rien une fois arrivé sur le serveur.

Exemple (Validation stricte) :

const updateSchema = z.object({
  email: z.string().email(),
  // On valide la logique métier ici (max amount)
  amount: z.number().max(1000),
}).strict(); // 👈 Rejette tout champ non déclaré (ex: isAdmin: true)

export async function updateOrder(data: unknown) {
  const result = updateSchema.safeParse(data);
  if (!result.success) throw new Error("Invalid payload");
  // ...
}

La Checklist :

• Schémas Stricts : Utilisez .strict() pour rejeter tout champ inattendu injecté dans le payload.

• Limites : Validez la longueur des inputs pour éviter les attaques DoS.

Le Pattern DTO (Data Transfer Object)

C'est l'erreur la plus fréquente : retourner directement un objet de base de données (Prisma, Drizzle) au client après une mutation.

Exemple (Fuite de données vs DTO) :

// ❌ DANGER : Fuite de données (password_hash, internal_flags...)
const user = await db.user.update({ ... });
return user;

// ✅ SECURE : Mapping DTO explicite
const user = await db.user.update({ ... });
return {
  id: user.id,
  name: user.name,
  role: user.publicRole // On expose uniquement le nécessaire
};

La Checklist :

• Pas de Leak : Ne retournez jamais un objet complet de l'ORM. Les données sensibles sont présentes dans le JSON du réseau, même si elles ne sont pas affichées.

Protection des Secrets (Taint API)

Pour les applications manipulant des tokens sensibles, React offre des mécanismes de défense en profondeur.

La Checklist :

• Server-Only : Importez server-only dans vos modules de données.

• Taint API : Utilisez experimental_taintUniqueValue sur vos clés API. Si cette valeur tente d'être envoyée au client, React fera échouer la requête instantanément.

Injection et RCE (La ligne rouge)

Le risque de RCE (Remote Code Execution) existe si vous utilisez des fonctions dangereuses avec des entrées utilisateur.

La Checklist :

• SQL Paramétré : Bannissez la concaténation de chaînes SQL. Utilisez toujours les mécanismes de paramétrage de votre ORM.

• No Eval : eval(), new Function() et child_process.exec() sont strictement interdits avec des données provenant d'une Server Action.

Conclusion

Les Server Actions sont puissantes car elles réduisent la friction. Mais cette réduction de friction ne doit pas signifier une réduction de la vigilance.

En 2026, l'expert Next.js ne se contente pas de faire fonctionner la feature. Il architecture ses Actions comme des routes d'API publiques : validées, sécurisées et nettoyées.