Sécuriser Votre Application Next.js : React2Shell
Sécuriser Votre Application Next.js en 2025 : React2Shell
Introduction
Fin 2025, la vulnérabilité React2Shell (CVE-2025-55182) a fait l’effet d’une bombe. Une faille CVSS 10.0 dans les React Server Components qui permettait une exécution de code à distance sans aucune authentification. En quelques jours, plus de 59 000 serveurs ont été compromis via des campagnes comme Operation PCPcat : vol de credentials cloud, installation de miners, le grand classique.
Même si les patches sont sortis très vite, cet incident rappelle une vérité toute simple : aucun framework, même aussi populaire que Next.js, n’est à l’abri. Plutôt que de paniquer à chaque CVE, mieux vaut adopter des habitudes solides dès le départ.
Voici ce que j’ai tiré comme leçons de cette histoire, et surtout les pratiques que j’applique systématiquement pour dormir tranquille.
1. React2Shell en deux mots : comment ça marchait
Tout partait d’une désérialisation non sécurisée dans le protocole interne des Server Components (le fameux “Flight”). Une simple requête POST bien craftée sur un endpoint RSC suffisait à exécuter du code arbitraire sur le serveur.
- Touchait Next.js 15.x et 16.x avec l’App Router
- Exploitée massivement dans le wild dès les premières heures
- Patch disponible rapidement (Next.js ≥ 16.0.7 et ≥ 15.5.7)
Première règle d’or : mettre à jour dès qu’un correctif sort. Pas dans une semaine, pas “quand j’aurai le temps”. Immédiatement.
# Un petit script qui sauve la vie
npx fix-react2shell-next
npm install next@latest2. Les réflexes de base qui changent tout
Pour tout le monde, la solution la plus simple est de mettre à jour. Mais en plus de ça, il y a d’autres pratiques à suivre pour s’assurer que votre application est toujours en sécurité. Voici une liste de pratiques qui devrait vous aider à vous procurer une application plus sécurisée.
Toujours vérifier l’auth dans les Server Actions
Les Server Actions sont pratiques, mais elles exposent des endpoints publics par défaut. Ne faites jamais confiance au client.
"use server";
import { getServerSession } from "next-auth";
export async function deletePost(id: string) {
const session = await getServerSession();
if (!session?.user) {
throw new Error("Non autorisé");
}
// logique de suppression...
}Marquer les données sensibles
Activez les Taint APIs de React pour éviter les fuites accidentelles :
// next.config.js
module.exports = {
experimental: {
taint: true,
},
};Headers de sécurité (ça prend 5 lignes)
Un middleware ou directement dans next.config.js :
// next.config.js
module.exports = {
async headers() {
return [
{
source: "/:path*",
headers: [
{ key: "X-Content-Type-Options", value: "nosniff" },
{ key: "X-Frame-Options", value: "DENY" },
{ key: "Strict-Transport-Security", value: "max-age=31536000; includeSubDomains" },
{ key: "Content-Security-Policy", value: "default-src 'self'; script-src 'self'" },
],
},
];
},
};3. Docker : là où beaucoup se font avoir
Une grande partie des compromissions React2Shell passait par des containers mal configurés. Voici le Dockerfile que j’utilise en prod (minimal, sécurisé, non-root) :
FROM node:20-alpine AS base
# Dépendances
FROM base AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
# Build
FROM base AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
# Production
FROM base AS runner
WORKDIR /app
ENV NODE_ENV=production
# User non-root
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=build --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=build --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --from=build /app/public ./public
USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]Et en bonus :
- Scannez vos images régulièrement (Trivy, Docker Scout…)
- Ne mettez jamais de secrets dans les variables d’environnement au build time
- Passez par un reverse proxy (NGINX, Traefik) avec un WAF si possible
4. Les autres pièges classiques à éviter
- Rate limiting sur les endpoints sensibles (login, API publiques)
- Validation stricte des inputs avec Zod ou Yup
- Middleware d’auth appliqué systématiquement, même si “c’est juste une petite route”
En résumé
React2Shell a été un rappel brutal, mais aussi une bonne occasion de revoir ses bases. Mises à jour rapides, authentification stricte, conteneurs durcis : ce sont des habitudes qui protègent contre 90 % des attaques du quotidien.
Depuis cet épisode, je vérifie encore plus scrupuleusement ces points à chaque nouveau projet. Et franchement, ça ne prend pas tant de temps que ça pour gagner énormément en sérénité.
Si vous avez vécu cette vulnérabilité de près ou si vous avez d’autres astuces sécurité que vous appliquez, n’hésitez pas à me le dire sur X ou LinkedIn – j’adore échanger là-dessus !
Sources :
- annonces officielles Next.js/React
