FlawOpen

flawopen.com/संदर्भ/Next.js Server Actions CSRF

Next.js Server Actions CSRF: Origin जाँच और सुरक्षित कॉन्फ़िगरेशन

CWE-352: Cross-Site Request Forgery (CSRF)Framework सुरक्षा मार्गदर्शिका
संक्षिप्त उत्तर

Next.js Server Actions POST का उपयोग करते हैं और Origin के host की तुलना x-forwarded-host या host से करते हैं। यह देखना ऐसा है जैसे आगंतुक के निमंत्रण पर स्थान सर्वर की अपेक्षा से मेल खाता है या नहीं। यह cross-site submission रोकने में मदद करता है, पर अनुमति नहीं देता: हर action को उपयोगकर्ता की पहचान, इनपुट और अधिकार जाँचने होंगे।

एक अहम सीमा है: मौजूदा Next.js दस्तावेज़ कहता है कि Origin के बिना अनुरोध चेतावनी के साथ आगे बढ़ता है। Reverse proxy भी तुलना वाले host को प्रभावित करता है। इस जाँच को एक सुरक्षा परत मानें और proxy से विश्वसनीय host तय करवाएँ।

Origin
ब्राउज़र द्वारा भेजे गए आरंभिक पृष्ठ का origin; Next.js इसके host की तुलना application host से करता है।
Host / X-Forwarded-Host
तुलना के लिए Next.js द्वारा लिया गया host मान। Proxy को forwarded जानकारी सेट या सत्यापित करनी चाहिए।
allowedOrigins
Server Actions के लिए स्वीकार्य अतिरिक्त Origin host की स्पष्ट सूची। Next.js सटीक host और wildcard pattern स्वीकार करता है।
Authorization
हर action में निर्णय कि प्रमाणित उपयोगकर्ता इस विशेष object पर यह operation कर सकता है या नहीं।

Server Actions की अंतर्निहित CSRF जाँच कैसे काम करती है

1

ब्राउज़र Server Action भेजता है

Server Action HTTP POST से बुलाया जाता है। SameSite cookie व्यवहार कई cross-site अनुरोधों को रोकता है, लेकिन केवल POST पूर्ण CSRF सुरक्षा नहीं है।

2

Next.js host की तुलना करता है

Origin मौजूद हो तो Next.js उसके host की तुलना x-forwarded-host या host से करता है। अंतर होने पर अनुरोध अस्वीकार होता है, जब तक Origin host serverActions.allowedOrigins में न हो।

3

Action अपनी नीति फिर भी लागू करता है

अनुरोध जाँच के बाद action को उपयोगकर्ता प्रमाणित करना, हर argument सत्यापित करना और operation अधिकृत करना होगा। Action ID और छिपे form fields access control नहीं हैं।

महत्वपूर्ण सीमाएँ: Origin अनुपस्थित और allowedOrigins

दस्तावेज़ित default में Origin का अभाव अस्वीकार नहीं होता

मौजूदा दस्तावेज़ के अनुसार Origin रहित अनुरोध चेतावनी के साथ आगे जाता है। यह न मानें कि हर अनुरोध तुलना पास कर चुका है। कारण जाँचें और action के भीतर authentication, authorization और input validation करें।

Wildcard भरोसेमंद origins का दायरा बढ़ाते हैं

allowedOrigins सटीक host और wildcard स्वीकार करता है: * एक label और ** एक या अधिक labels से मेल खाता है। केवल संगठन-नियंत्रित और आवश्यक domain/subdomain अनुमति दें। उपयोगकर्ता-नियंत्रित subdomain वाला wildcard ऐसे origin पर भरोसा करा सकता है जिसे आप नियंत्रित नहीं करते।

Reverse proxy को सुरक्षा सीमा का हिस्सा मानकर कॉन्फ़िगर करें

Next.js तुलना में x-forwarded-host या host लेता है। Edge proxy को client से आए forwarding headers हटाकर सत्यापित public hostname से मान सेट करना चाहिए; app केवल इसी विश्वसनीय proxy से पहुँच योग्य हो। यदि proxy internal hostname भेजता है, तो allowedOrigins में केवल आवश्यक public origin रखें। मनमाने host पर भरोसा करके mismatch ठीक न करें।

बहुत व्यापक भरोसा
// Every subdomain, including delegated or tenant-controlled names, is trusted.
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['**.example.com'],
    },
  },
};
सीमित भरोसा
// Add only the public host that this deployment requires.
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['admin.example.com'],
    },
  },
};

// Configure the edge to overwrite X-Forwarded-Host
// with the validated public hostname.

Host advisories: संबंधित जोखिम, CSRF से अलग

Host पर भरोसे के कारण Server Actions में SSRF की दस्तावेज़ित खामियाँ आईं। CVE-2024-34351 ने 14.1.1 से पुराने self-hosted संस्करणों को तब प्रभावित किया जब action / से शुरू होने वाला relative redirect करता था और Host बदला जा सकता था। एक अलग जुलाई 2026 Vercel advisory custom server में client द्वारा host-संबंधित headers नियंत्रित करने पर SSRF और internal values के खुलासे का वर्णन करती है; fixed releases 15.5.21 और 16.2.11 हैं। ये host-trust समस्याएँ हैं, Origin CSRF जाँच bypass का प्रमाण नहीं।

2026 advisory के लिए fixed release पर upgrade करें। तब तक edge या proxy पर Host और X-Forwarded-Host को pin या validate करें। advisory 14.2.0+ के लिए अतिरिक्त उपाय के रूप में __NEXT_PRIVATE_ORIGIN भी बताती है। इसे अपनाने से पहले advisory में प्रभावित और समर्थित release शाखाएँ जाँचें।

हर Server Action को अधिकृत और सत्यापित करें

Next.js दस्तावेज़ action arguments को अविश्वसनीय मानने और जाँचने को कहता है कि वर्तमान उपयोगकर्ता उसे चला सकता है। असुरक्षित उदाहरण caller के object ID पर भरोसा करता है। सुरक्षित तरीका user को प्रमाणित करता है, ID जाँचता है और database mutation में ownership की शर्त लगाता है।

OBJECT AUTHORIZATION नहीं है
"use server";

export async function deleteInvoice(invoiceId: string) {
  await db.invoice.delete({ where: { id: invoiceId } });
}
AUTHENTICATE, VALIDATE, AUTHORIZE
"use server";

import { z } from "zod";
import { requireUser } from "@/auth";

const invoiceIdSchema = z.string().uuid();

export async function deleteInvoice(rawId: unknown) {
  const user = await requireUser();
  const invoiceId = invoiceIdSchema.parse(rawId);
  const result = await db.invoice.deleteMany({
    where: { id: invoiceId, ownerId: user.id },
  });
  if (result.count !== 1) throw new Error("Forbidden");
}

Server Actions CSRF और authorization checklist

संदर्भ

यह भी देखें क्रॉस-साइट रिक्वेस्ट फ़ॉर्जरी (CSRF, CWE-352): यह कैसे काम करता है और इससे कैसे बचें — flawopen.com क्या SameSite=Strict CSRF tokens की जगह लेता है? GET के लिए CSRF token कब चाहिए? localStorage में JWT बनाम HttpOnly कुकीज़: कौन ज़्यादा सुरक्षित? — flawopen.com