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

Principaux répertoires et fichiers

• 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 de votre application, layouts, components et routes API. Adopte le paradigme App Router, permettant des fonctionnalités avancées de routing et la ségrégation 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 le 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 style scoped aux composants.
• app/utils/: Inclut des fonctions utilitaires, modules d’aide et autre logique non-UI qui peut ê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 au contrôle de version.
• next.config.js: Personnalise le comportement de Next.js, incluant les configurations webpack, les variables d’environnement et les paramètres de sécurité.
• tsconfig.json: Configure les options TypeScript du projet, activant le typage 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, y compris les instructions d’installation, les directives d’utilisation et autres détails pertinents.
• yarn.lock / package-lock.json: Verrouillent les dépendances du projet à des versions spécifiques, garantissant 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 é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>
)
}

Côté serveur dans Next.js

Server-Side Rendering (SSR)

Les pages sont rendues côté 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 crawler 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

Static Site Generation (SSG)

Les pages sont pré-rendues lors de la phase de 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 API sous forme de fonctions serverless. Ces fonctions s’exécutent à la demande sans nécessiter de serveur dédié.

Cas d’utilisation :

• Traitement des soumissions de formulaires.
• Interaction avec des bases de données.
• Traitement de données ou intégration avec des API 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 des composants serveur et 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 :

• Emplacement : Les routes API sont placées dans le répertoire app/api/.
• Nom des fichiers : Chaque endpoint API réside dans son propre dossier contenant un fichier route.js ou route.ts.
• Fonctions exportées : Plutôt qu’un export par défaut unique, des fonctions pour des méthodes HTTP spécifiques (p. 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 d’état.

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 afin d’atténuer les vulnérabilités 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é dans toutes les API routes 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 web d’accéder à l’API, ce qui peut permettre à des sites malveillants d’interagir avec votre API sans restrictions.
• Autorisation large des méthodes : Autoriser toutes les méthodes peut permettre à des attaquants d’effectuer des actions non désirées.

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 destiné au 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: À la racine du projet ou dans src/.

Objectif: Exécute du code dans la fonction serverless côté serveur 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: Exécute des opérations en fonction de la requête (par ex., vérifier l’authentification).
3. Modification de la réponse: Peut modifier la réponse ou transférer le contrôle au handler 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*"],
}

next.config.js

Emplacement : Racine du projet.

But : Configure le comportement de Next.js, permet d’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, // 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’état global, les styles et les composants de layout.

Cas d’utilisation :

• Injection de CSS global.
• Ajout de wrappers de layout.
• 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 de personnaliser les 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 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, en particulier sur des plateformes comme Vercel qui optimisent pour 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 :

• Utilisez les fichiers .env : Stockez des variables comme des clés API dans .env.local (exclu du contrôle de version).
• Accédez aux variables en toute sécurité : Utilisez process.env.VARIABLE_NAME pour accéder aux variables d’environnement.
• N’exposez jamais de secrets côté client : Assurez-vous 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
},
}

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

Authentification et autorisation

Approche :

• Authentification basée sur les sessions : Utilisez des cookies pour gérer les sessions utilisateur.
• Authentification par tokens : Implémentez des JWTs pour une authentification sans état.
• Fournisseurs tiers : Intégrez des providers OAuth (p. ex. Google, GitHub) en utilisant des bibliothèques comme next-auth.

Bonnes pratiques de sécurité :

• Cookies sécurisés : Définissez les attributs HttpOnly, Secure et SameSite.
• Hachage des mots de passe : Hachez 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.
• Découpage du code (Code Splitting) : Exploitez les dynamic imports pour scinder le code et réduire le temps de chargement initial.
• Mise en cache : Mettez en place des stratégies de caching pour les réponses d’API et les assets statiques.
• Chargement différé (Lazy Loading) : Chargez les composants ou les assets 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 to function name via source maps)

Les versions récentes de Next.js utilisent les « Server Actions » qui s’exécutent côté 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 provoquent un leak suffisant (ainsi que les source maps associées) pour reconstituer 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 sur minified JS + source maps optionnels)

Recherchez dans les JS chunks téléchargés createServerReference et extrayez le hash ainsi que le symbole 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 : action côté serveur hash (40+ caractères hexadécimaux)
• Groupe 2 : symbole ou chemin qui peut être résolu vers la fonction originale via la source map lorsqu’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.

Practical workflow

• 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).
• Run the regex above to build a hash↔name dictionary.
• Use the dictionary to target testing:
• Name-driven triage (e.g., transferFunds, exportFinancialData).
• Track coverage across builds by function name (hashes rotate across builds).

Exercising hidden actions (template-based request)

Take a valid POST observed in-proxy as a template and swap the Next-Action value to target another discovered action:

# 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 :
• Explore l’historique du proxy pour les JS chunks, extrait les entrées createServerReference(...) et analyse les source maps quand elles sont disponibles.
• Maintient un dictionnaire searchable 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 à l’envoi avec le hash de l’action cible remplacé.
• 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 function-name n’est pas une vulnérabilité en soi ; utilisez-la pour guider la découverte et tester l’autorisation de chaque action.

React Server Components Flight protocol deserialization RCE (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) contain a critical server-side prototype pollution during Flight chunk deserialization. By crafting $ references inside a Flight payload an attacker can pivot from polluted prototypes to arbitrary JavaScript execution and then to OS command execution inside the Node.js process.

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.

Squelette du 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

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

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

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

• App Router defaults: create-next-app active l’App Router et le répertoire app/ par défaut, ce qui transforme silencieusement chaque route en un endpoint compatible RSC. Les assets de l’App Router tels que /_next/static/chunks/app/ ou les réponses qui streament des chunks Flight via text/x-component constituent des empreintes visibles sur Internet.
• Implicitly vulnerable RSC deployments: L’avis de React indique que les apps incluant 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 patchés.

Version coverage (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 dépendances corrigées, donc tout build inférieur à ces versions est une cible de grande valeur.
• Next.js canary: 14.3.0-canary.77+ embarque aussi le runtime buggy et ne dispose actuellement pas de canary corrigés, faisant de ces empreintes des candidats sérieux à l’exploitation.

Remote detection oracle

Assetnote’s react2shell-scanner envoie une requête Flight multipartite créée sur mesure vers des chemins candidats et observe le comportement côté serveur :

• Default mode exécute un 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 sorte que les serveurs patchés retournent 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 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 remplacent les commandes OS afin que vous puissiez sonder des assets réels sur Internet.

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

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
• assetnote/react2shell-scanner

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.