'use server' : cette directive, apparue avec l’App Router de Next.js et stabilisée dans les versions ultérieures, place un morceau de code entier côté serveur. Une confusion s’installe alors souvent : parce que le code s’exécute côté serveur, certaines équipes en déduisent à tort qu’il hérite d’une confiance implicite, sans revalider les entrées comme elles le feraient pour un endpoint REST public classique.
Sur un projet où plusieurs Server Actions Next.js écrivent directement dans WordPress (création de commentaire, mise à jour de profil, envoi de formulaire), cette confusion a justifié la mise en place d’une checklist systématique avant chaque nouvelle Server Action touchant à l’écriture de données.
Une Server Action reste un point d’entrée public
Une Server Action est appelée depuis le navigateur exactement comme n’importe quelle requête réseau : Next.js génère en coulisses un endpoint HTTP dédié pour chaque action, appelé automatiquement lors d’une soumission de formulaire ou d’un appel explicite depuis un composant client. Rien n’empêche un tiers d’appeler directement cet endpoint avec des données arbitraires, en contournant entièrement l’interface utilisateur prévue.
La checklist retenue distingue systématiquement ce qui relève de l’authentification (qui appelle cette action) de ce qui relève de l’autorisation (que peut faire cet appelant précis) :
- Vérifier la session utilisateur côté serveur avant tout traitement, jamais en se fiant à un état côté client
- Valider et assainir chaque paramètre reçu, comme pour n’importe quel endpoint REST
- Vérifier que l’utilisateur authentifié a effectivement le droit d’agir sur la ressource ciblée, pas seulement qu’il est connecté
Un jeton par route plutôt qu’un jeton universel
La deuxième règle de la checklist concerne le mot de passe d’application WordPress utilisé côté serveur par les Server Actions pour écrire dans WordPress. Plutôt qu’un jeton unique, associé à un compte disposant de larges permissions et réutilisé par toutes les Server Actions du projet, chaque famille d’action reçoit son propre compte technique, limité aux capacités strictement nécessaires :
// lib/wp-clients.js
export const clientCommentaires = creerClientWordPress({
utilisateur: process.env.WP_API_USER_COMMENTAIRES,
motDePasse: process.env.WP_API_PASSWORD_COMMENTAIRES, // rôle limité à la création de commentaires
});
export const clientProfil = creerClientWordPress({
utilisateur: process.env.WP_API_USER_PROFIL,
motDePasse: process.env.WP_API_PASSWORD_PROFIL, // rôle limité à la mise à jour du profil utilisateur courant
});
Cette séparation limite l’impact d’une fuite : un secret compromis pour la Server Action de commentaires ne donne aucun accès à la Server Action de mise à jour de profil, contrairement à un jeton universel qui aurait exposé l’ensemble des capacités d’écriture du projet en une seule fuite.
Exemple concret d’une Server Action correctement validée
'use server';
import { auth } from '@/lib/auth';
import { clientProfil } from '@/lib/wp-clients';
export async function mettreAJourProfil(donnees) {
const session = await auth();
if (!session?.user) {
throw new Error('Non authentifié');
}
const bio = String(donnees.get('bio') ?? '').slice(0, 500);
if (bio.length === 0) {
throw new Error('La biographie ne peut pas être vide');
}
await clientProfil.patch(`/wp-json/wp/v2/users/${session.user.wpId}`, {
description: bio,
});
}
Le point critique de cet exemple : l’identifiant utilisateur ciblé (session.user.wpId) provient de la session serveur authentifiée, jamais d’un paramètre transmis par le client, ce qui empêche un utilisateur connecté de modifier le profil d’un autre en manipulant les données du formulaire.
Limiter la fréquence d’appel
Une Server Action d’écriture reste exposée aux mêmes risques d’abus par répétition qu’un endpoint REST classique. Une limitation de fréquence, appliquée par utilisateur authentifié plutôt que par adresse IP seule, complète la checklist pour les actions les plus sensibles comme l’envoi de formulaire de contact.
Ce que cette checklist ne couvre pas
Cette checklist porte exclusivement sur la sécurité des Server Actions elles-mêmes. Les questions de performance, notamment le temps de réponse perçu lors d’un enchaînement de plusieurs Server Actions successives, relèvent d’un travail d’optimisation distinct.
En résumé
Une Server Action Next.js qui écrit dans WordPress doit être traitée avec exactement la même rigueur qu’un endpoint REST public : validation des entrées, vérification des droits sur la ressource ciblée, et jetons segmentés par périmètre de responsabilité plutôt qu’un secret universel partagé entre toutes les actions du projet.
