Next.js : les erreurs de sécurité courantes dans les applications Server Components

Next.js App Router : puissant mais piégeux

Depuis l'adoption massive de Next.js App Router et des Server Components en 2025-2026, nous observons une nouvelle catégorie de vulnérabilités spécifiques à cette architecture. Le mélange serveur/client dans un même fichier crée une surface d'attaque que beaucoup de développeurs sous-estiment.

Erreur 1 : Server Actions exposées sans validation

Les Server Actions sont des fonctions serveur appelables directement depuis le client. Le problème : elles sont exposées comme des endpoints POST automatiquement. Si vous ne validez pas les entrées et les permissions côté serveur, n'importe quel utilisateur peut appeler l'action avec des paramètres arbitraires.

Nous trouvons régulièrement des Server Actions qui modifient des données sensibles sans vérifier que l'utilisateur connecté a le droit d'effectuer cette opération. Le fait que l'action soit dans un composant protégé côté UI ne change rien : l'endpoint est public.

Erreur 2 : Data fetching non sécurisé dans les Server Components

Les Server Components récupèrent des données directement côté serveur. L'erreur courante : faire confiance aux paramètres de l'URL sans validation. Un composant qui fait fetch(/api/users/${params.id}) sans vérifier que l'utilisateur connecté a le droit d'accéder à cet ID est vulnérable à l'IDOR (Insecure Direct Object Reference).

Pire encore : certains développeurs passent des données sensibles dans les props des Client Components, pensant que le Server Component les filtre. En réalité, ces props sont sérialisées dans le HTML et visibles dans le code source de la page.

Erreur 3 : Failles dans les API Routes

Les API Routes de Next.js (fichiers route.ts) sont souvent créées sans middleware d'authentification. Contrairement à Express où un middleware global est courant, chaque API Route Next.js est indépendante. Résultat : des endpoints oubliés sans aucune protection.

Nous trouvons des routes GET qui retournent des listes complètes d'utilisateurs, des routes PUT qui modifient des configurations sans vérifier le rôle, et des routes DELETE accessibles à tout utilisateur authentifié.

Erreur 4 : Contournement du middleware

Le middleware Next.js (middleware.ts) est censé protéger des routes. Mais il s'exécute au niveau Edge et ne peut pas accéder à la base de données directement. Beaucoup de développeurs y mettent une vérification de token JWT mais oublient de re-vérifier les permissions dans les Server Components ou API Routes.

De plus, le middleware ne s'applique pas aux Server Actions par défaut. Un middleware qui protège /admin/* ne bloque pas une Server Action définie dans un fichier sous /admin/.

Erreur 5 : Variables d'environnement exposées

Next.js distingue les variables serveur (process.env.SECRET) des variables client (NEXT_PUBLIC_*). Mais des erreurs de nommage exposent des secrets. Nous trouvons des clés API, des tokens de service, et des secrets de session dans le bundle JavaScript client parce que le développeur a préfixé par erreur avec NEXT_PUBLIC_.

Comment nous détectons ces failles

Notre revue externe analyse le bundle JavaScript client, les headers de réponse, et les endpoints exposés. Nous identifions les Server Actions non protégées, les API Routes sans authentification, et les variables d'environnement mal configurées. Rapport complet sous 48h.