Headless में जाने से attack surface हटा नहीं। यह सिर्फ move हुआ। 2025-26 का record दिखाता है कि कहाँ: React Server Components (CVE-2025-55182, unauthenticated remote code execution, 3 दिसंबर 2025 को published), Astro के server islands और image endpoint, Nuxt payload caching CDN के पीछे, npm packages, और एक WordPress backend जो अभी भी PHP चलाता है। बिना server runtime के एक पूरी तरह static export ज्यादातर framework-level risk को हटा देता है। लेकिन बहुत सारी "static" sites असल में static नहीं होती। नीचे आपको incidents मिलेंगे framework by framework, फिर secrets, CSP, supply chain, WordPress origin और edge controls, और अंत में एक hardening table जिसे आप अपने अपने stack के लिए adapt कर सकते हैं।
क्यों "static का मतलब unhackable" अब सच नहीं रहा
पहले साफ़ कहें: अगर आपका build output plain HTML, CSS और JS files है, और एक CDN उन्हें serve करता है, तो कोई framework server नहीं है जिसे attack किया जा सके। कोई React Server Components endpoint नहीं। कोई server action नहीं। कोई middleware नहीं जिसे bypass किया जा सके। यह एक genuinely छोटा attack surface है, और यही कारण है कि पुरानी Jamstack pitch का वजन था।
लेकिन देखें कि ज्यादातर Next.js, Astro और Nuxt projects 2026 में actually क्या deploy करते हैं। Contact form के लिए एक server action। Middleware जो एक cookie check करता है। एक image optimisation endpoint। Server islands एक personalised header के लिए। ISR या on-demand revalidation। इनमें से हर एक का मतलब है एक process requests को listen कर रहा है, input को parse कर रहा है, और environment variables को hold कर रहा है। वह एक server है। बस आपके repo में ऐसा नहीं दिख रहा है।
तो सवाल यह नहीं है कि "क्या यह site headless है?" यह है कि "request time पर क्या चलता है?" तीन honest answers मौजूद हैं:
- कुछ नहीं। Pure static output। आपका risk build pipeline और CMS में है, framework में नहीं।
- एक छोटा, known endpoints का set। Image optimisation, एक form handler। उन्हें patch करें, restrict करें, rate-limit करें।
- एक पूरा application runtime। SSR, server actions, auth, database access। इसे किसी भी web app की तरह treat करें, क्योंकि यह एक ही है।
मैंने WordPress के साथ architectural comparison कहीं और की है (headless vs WordPress security देखें), इसलिए मैं इसे दोहाऊँगा नहीं। यह post incident record है और इसके बारे में क्या करना है।
Next.js: React2Shell, server actions और proxy trap
React2Shell
CVE-2025-55182 (React) और CVE-2025-66478 (Next.js) 3 दिसंबर 2025 को published किए गए। Critical। React Server Components को crafted requests के माध्यम से unauthenticated remote code execution। Vercel के changelog के अनुसार, affected Next.js versions हैं >=14.3.0-canary.77, 15.x और 16.x जो App Router use करते हैं। Patched Next.js releases हैं 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 और 16.0.7, React को 19.0.1, 19.1.2 और 19.2.1 में fixed किया गया।
Speed यहाँ matter करती है। Datadog Security Labs ने public exploit code और 5 दिसंबर 2025 तक active exploitation attempts की report की। दो दिन। अगर आपकी patch process monthly rhythm पर चलती है, तो वह gap exposure है।
Vercel npx fix-react2shell-next ship करता है affected versions को bump करने के लिए। चाहे आप कौन सा route लें, अपनी release line के लिए linked advisory में current fixed version को confirm करें, क्योंकि follow-ups ने targets को बदल दिया।
11 दिसंबर के follow-ups
11 दिसंबर 2025 को Next.js टीम ने दो और समस्याओं को कवर करते हुए एक और सुरक्षा अपडेट प्रकाशित किया:
- CVE-2025-55184, सेवा से इनकार (उच्च)। एक App Router अनुरोध सर्वर को हैंग कर सकता है। पहली फिक्स अधूरी थी; संपूर्ण फिक्स CVE-2025-67779 के रूप में ट्रैक की जा रही है।
- CVE-2025-55183, स्रोत कोड एक्सपोजर (माध्यम)। एक तैयार किया गया अनुरोध एक Server Function को अन्य Server Functions का संकलित स्रोत वापस करने के लिए बना सकता है। उनमें कोड किया गया कुछ भी लीक हो जाता है। रनटाइम पर पर्यावरण से पढ़े गए रहस्य नहीं करते हैं।
Pages Router प्रभावित नहीं था, और कोई वर्कअराउंड नहीं है। अपग्रेड करें। फिक्स किए गए रिलीज़ में 14.2.35, 15.5.9 और 16.0.10 शामिल हैं (अपनी लाइन के लिए सलाह जांचें)।
server-actions पाठ सीधा है: एक server action एक सार्वजनिक HTTP एंडपॉइंट है जिसमें एक अच्छा कॉलिंग कन्वेंशन है। इसके तर्कों को शत्रुतापूर्ण इनपुट के रूप में मानें। इसके अंदर अधिकृत करें। और कभी भी एक फ़ाइल में एक रहस्य को स्ट्रिंग लिटरल के रूप में न लिखें जिसे एक server function तक पहुंच सकता है।
Middleware एक प्राधिकरण सीमा नहीं है
CVE-2025-29927, 21 मार्च 2025 को प्रकाशित (CVSS 9.1), एक तैयार किए गए x-middleware-subrequest हेडर को middleware को पूरी तरह से छोड़ने दे सकता है। यदि आपकी केवल auth जांच middleware में रहती थी, तो इसे बाईपास कर दिया गया था। Datadog का विश्लेषण 12.3.5, 13.5.9, 14.2.25 और 15.2.3 में फिक्स को सूचीबद्ध करता है। Vercel-होस्ट किए गए ऐप्स को बुनियादी ढांचे के स्तर पर सुरक्षा मिली थी। Self-hosted ऐप्स को पैच किए जाने तक जोखिम में रखा गया था।
Next.js 16 middleware.ts का नाम proxy.ts में बदलता है और इसे डिफ़ॉल्ट रूप से Node.js रनटाइम पर चलाता है; middleware.ts हटा दिया गया है। यह नाम परिवर्तन ईमानदार है, मुझे लगता है। एक proxy ऐप के सामने बैठता है। यह रीडायरेक्ट, रीराइट, हेडर जोड़ सकता है। यह एक अजनबी और आपके डेटा के बीच एकमात्र चीज़ नहीं होनी चाहिए।
असली जांच कहां रखें:
- डेटा लेयर में, उस क्वेरी के बगल में जो पंक्तियां वापस करती है।
- हर server action में जो कुछ बदलता है।
- Route handlers में, प्रति route।
- Proxy में केवल logged-out उपयोगकर्ताओं के लिए सुविधा रीडायरेक्ट के रूप में, कभी लॉक के रूप में नहीं।
यदि proxy.ts को हटाना डेटा को एक्सपोज़ करेगा, तो आपकी प्राधिकरण गलत जगह पर है।
Astro: server islands, image endpoints और middleware paths
Astro की डिफ़ॉल्ट static है, जो एक ताकत है। लेकिन 2025 के तीन सलाहकार उन टुकड़ों को हिट करते हैं जो एक runtime जोड़ते हैं।
Server islands XSS। CVE-2025-64764, 19 नवंबर 2025 को प्रकाशित, उच्च (CVSS 7.1)। server islands endpoint के slots पैरामीटर के माध्यम से एक reflected XSS। यह किसी भी ऐप को प्रभावित करता था जो server islands का उपयोग करता था, भले ही island component कोई slots न हो। संस्करण 5.15.6 और पहले प्रभावित थे; 5.15.8 ने इसे पैच किया। विवरण GitHub advisory में हैं।
Image endpoint SSRF। CVE-2025-58179 ने @astrojs/cloudflare adapter को प्रभावित किया (11.0.3 से 12.6.5)। output 'server' और default compile image service के साथ, image endpoint ने URLs को वैलिडेट नहीं किया, जिसने server-side request forgery को सक्षम किया। SSRF दुष्ट है क्योंकि सर्वर अपने नेटवर्क के अंदर से अनुरोध करता है, जहां यह metadata services या internal APIs तक पहुंच सकता है।
Middleware path bypass। Astro 5.15.8 ने double-encoded URLs का उपयोग करके एक path-normalisation bypass को भी ठीक किया (CVE-2025-64765)। Next.js header ट्रिक के समान गलतियों का परिवार: प्राधिकरण जो URL के एक निश्चित तरीके से दिखने पर निर्भर करता है।
निर्णय लेने से पहले withastro/astro security advisories में सटीक संस्करण श्रेणियां जांचें कि क्या आप प्रभावित हैं। मैं ऐसी सीमाओं पर अनुमान लगाने वाला नहीं हूं जिन्हें मैं इंगित नहीं कर सकता।
Astro 6 और built-in CSP
Astro 6 security.csp के तहत एक CSP API शिप करता है। Astro 6 beta announcement के अनुसार, यह bundled scripts और styles को हैश करता है (डिफ़ॉल्ट रूप से SHA-256), और यह build और preview में काम करता है लेकिन dev में नहीं। वह अंतिम बिंदु लोगों को पकड़ता है: एक पृष्ठ जो astro dev के तहत ठीक दिखता है जब नीति एक production build में लागू होती है तो टूट सकता है। हमेशा निर्मित आउटपुट का परीक्षण करें।
अगर आप क्लाइंट्स के लिए Astro साइट्स बना रहे हैं और शुरुआत से ही सुरक्षा चाहते हैं, तो हमारा Astro development पेज बताता है कि हम प्रोजेक्ट्स को कैसे सेट करते हैं।
Nuxt: payload कैश पॉइज़निंग और `runtimeConfig.public` क्या expose करता है
CVE-2025-27415
19 मार्च 2025 को प्रकाशित। उच्च, CVSS 7.5, और प्रभाव उपलब्धता है। स्थिति: आप Nuxt को एक CDN के पीछे चलाते हैं जो अपनी कैश कुंजी में query string को नज़रअंदाज़ करता है। एक हमलावर /?/_payload.json जैसा कुछ मांगता है। Nuxt उस अनुरोध के लिए JSON render करता है। CDN इसे / के लिए कुंजी के तहत कैश करता है और हर विज़िटर को वह JSON परोसता है। हर कैश expiry पर दोहराया जा सकता है। प्रभावित: 3.0.0 से 3.16.0 से पहले; 3.16.0 में पैच किया गया (advisory)।
ध्यान दें कि यह कौन सी तरह की बग है। Nuxt का कोड और CDN का कॉन्फ़िग अकेले तो ठीक काम कर रहे थे। साथ में, वे आपका होमपेज तोड़ गए। तो सीख "Nuxt अपग्रेड करें" से परे जाती है: CDN कैश-की कॉन्फ़िगरेशन एप्लिकेशन सुरक्षा का हिस्सा है। आपकी टीम के किसी को इसका मालिक होना चाहिए, और यह लिखा हुआ होना चाहिए, डैशबोर्ड डिफ़ॉल्ट पर छोड़ा हुआ नहीं।
एक त्वरित staging जांच, केवल आपके अपने staging डोमेन का उपयोग करके: पेज को एक अजीब query string के साथ अनुरोध करें, देखें कि क्या वापस आता है, फिर clean URL का अनुरोध करें और पुष्टि करें कि यह अभी भी HTML है। अगर आपकी कैश लेयर performance के लिए query strings को नज़रअंदाज़ करने की अनुमति देती है, तो सुनिश्चित करें कि framework के आंतरिक routes उस नियम से बाहर हैं।
`runtimeConfig.public` क्या expose करता है
Nuxt runtimeConfig को निजी कुंजियों (सर्वर केवल) और runtimeConfig.public (ब्राउज़र को भेजा गया) में विभाजित करता है। नाम ही चेतावनी है। public के तहत कुछ भी पेज payload में है जो कोई भी पढ़ सकता है। एक Stripe publishable key वहां रखें, ठीक है। एक CMS admin token वहां रखें और आपने इसे publish कर दिया है।
तीनों में Secrets और env vars
हर framework का एक prefix नियम है, और prefix का मतलब है "ब्राउज़र को भेजें":
| Framework | डिज़ाइन से public | डिफ़ॉल्ट से सर्वर-केवल |
|---|---|---|
| Next.js | NEXT_PUBLIC_* (build time पर inlined) | process.env में बाकी सब कुछ |
| Astro / Vite | PUBLIC_* | अन्य env vars, सर्वर-पक्ष से पढ़ें |
| Nuxt | runtimeConfig.public | शीर्ष-स्तर की runtimeConfig कुंजियां |
प्रत्येक framework के डॉक्स को इसके बारे में पढ़ें, क्योंकि विवरण भिन्न हैं (Next.js NEXT_PUBLIC_ values को build time पर bundle में inline करता है, जिसका मतलब यह भी है कि एक को बदलने के लिए rebuild की आवश्यकता है)। सिद्धांत भिन्न नहीं है। अगर किसी variable के पास एक public prefix है, तो इसे होमपेज पर मुद्रित मानें।
तीन आदतें ज्यादातर गलतियों को पकड़ती हैं:
- एक public prefix के पीछे कभी भी write-capable token न रखें, भले ही "अस्थायी रूप से"।
- deploy करने से पहले अपने built output (.next/static,
dist/,.output/public) में token के fragments की खोज करें। - अपने front end को CMS के लिए एक read-only, सीमित दायरे वाली credential दें, किसी और चीज़ से अलग जो एक editor उपयोग करता है।
CVE-2025-55183 पाठ
That Next.js source-exposure bug is a neat illustration. It could return compiled source of Server Functions. Secrets read from the environment at runtime weren't in that source. Secrets pasted into the code as literals were. The framework bug was the framework's fault; the leaked API key was ours. After patching, if a literal secret ever lived in a server function on an affected version, assume it was readable and rotate it. Moving it to an env var is the fix for next time, not for the past.
Jamstack साइटों के लिए सुरक्षा हेडर और CSP
स्टेटिक होस्टिंग हेडर भूलना आसान बनाती है क्योंकि रिपॉजिटरी में कोई सर्वर कॉन्फ़िग फ़ाइल नहीं होती। लेकिन हेडर वह जगह है जहाँ आपको XSS फ़ॉलआउट से (जैसे ऊपर Astro सर्वर आइलैंड्स समस्या) सस्ते, असली संरक्षण मिलते हैं।
हर साइट पर शिप करने के लिए बेसलाइन सेट: Content-Security-Policy , Strict-Transport-Security , X-Content-Type-Options: nosniff , एक Referrer-Policy , और frame-ancestors (CSP के अंदर) या X-Frame-Options।
Nonce या हैश, `unsafe-inline` नहीं
एक CSP जो स्क्रिप्ट्स के लिए 'unsafe-inline' की अनुमति देता है वह XSS के खिलाफ मुश्किल से मदद करता है। आपके पास दो असली विकल्प हैं:
- हैशेस। बिल्ड-टाइम SHA-256 हैशेस प्रत्येक इनलाइन स्क्रिप्ट और स्टाइल का। स्टेटिक आउटपुट के लिए अच्छी तरह काम करता है क्योंकि कंटेंट प्रति अनुरोध नहीं बदलता। यह वह है जो Astro 6 का
security.cspऑटोमेट करता है। - Nonces। प्रति अनुरोध जेनरेट किया गया एक यादृच्छिक मान, हेडर में और प्रत्येक स्क्रिप्ट टैग में जोड़ा गया। इसे जेनरेट करने के लिए एक सर्वर या एज फ़ंक्शन चाहिए, इसलिए यह स्टेटिक फ़ाइलों की तुलना में SSR के लिए बेहतर फ़िट है। Next.js अपनी प्रॉक्सी लेयर का उपयोग करके एक nonce पैटर्न दस्तावेज़ करता है।
रेंडरिंग मॉडल के अनुसार चुनें। शुद्ध स्टेटिक: हैशेस। डायनामिक: nonces।
हर तीसरे पक्ष की उत्पत्ति, प्रति निर्देश की सूची बनाएँ
यह उबाऊ हिस्सा है और यह वह जगह है जहाँ नीतियां विफल होती हैं। एनालिटिक्स, टैग मैनेजर, फॉन्ट्स, वीडियो एम्बेड, चैट विजेट्स, फॉर्म प्रदाता, आपका CMS इमेज होस्ट। प्रत्येक को सही निर्देश के तहत सूचीबद्ध करने की आवश्यकता है: script-src , connect-src , img-src , font-src , frame-src। एक विजेट जो एक उत्पत्ति से स्क्रिप्ट लोड करता है और दूसरी पर API कॉल करता है उसे दोनों की आवश्यकता है।
एक उदाहरण हेडर, केवल आकार दिखाने के लिए (अपनी असली उत्पत्ति में स्वैप करें, और nonce को प्रति अनुरोध जेनरेट करना चाहिए):
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM' https://analytics.example.com; connect-src 'self' https://api.example.com; img-src 'self' data: https://cms.example.com; frame-ancestors 'none'; base-uri 'self'
Content-Security-Policy-Report-Only से शुरू करें, एक या दो सप्ताह के लिए उल्लंघन संग्रह करें, सूची ठीक करें, फिर लागू करें। और तीसरे पक्ष की उत्पत्ति और किसने हर एक को अनुरोध किया इसका एक छोटा इन्वेंटरी फ़ाइल रखें। छह महीने बाद, कोई याद नहीं रखता कि एक चैट विजेट script-src में क्यों है।
npm आपूर्ति श्रृंखला: chalk, debug और Shai-Hulud
आपका फ्रेमवर्क पैच हो सकता है और आपका सर्वर लॉक किया जा सकता है, फिर भी एक डिपेंडेंसी आपका सप्ताह खराब कर सकती है। 2025 की दो घटनाएं दिखाती हैं कि कैसे।
chalk और debug, 8 सितंबर 2025। एक मेंटेनर को npmjs.help से एक नकली 2FA-रीसेट ईमेल के साथ फ़िशिंग की गई। हमलावरों ने chalk और debug सहित लगभग 18 पैकेज के दुर्भावनापूर्ण रिलीज़ प्रकाशित किए। पेलोड ब्राउज़र बंडल से क्रिप्टो-वॉलेट गतिविधि चोरी करने का लक्ष्य रखता था। पैकेज को Upwind के विश्लेषण के अनुसार लगभग 2 से 2.5 घंटे में हटाया गया। दो घंटे कम है। लेकिन एक CI जॉब जो उस विंडो में ताजा संस्करण को हल करता है पेलोड को प्रोडक्शन में शिप कर सकता है।
Shai-Hulud, सितंबर 2025। CISA का 23 सितंबर 2025 का अलर्ट एक स्व-प्रतिकारी वर्म का वर्णन करता है जिसने 500 से अधिक npm पैकेज को समझौता किया। इसने GitHub टोकन और क्लाउड कुंजियाँ (AWS, GCP, Azure) एकत्र कीं, उन्हें Shai-Hulud नाम की सार्वजनिक GitHub रिपॉजिटरीज़ में प्रकाशित किया, और पीड़ितों के स्वयं के npm क्रेडेंशियल्स का उपयोग करके अन्य पैकेज में खुद को पुनः प्रकाशित किया। नवंबर 2025 में एक दूसरी लहर ने कथित रूप से लगभग 796 पैकेज को प्रभावित किया (माध्यमिक रिपोर्टिंग, तो आंकड़े को रिपोर्ट किए गए के रूप में मानें)।
नियंत्रण जो उन्हें कंटेन किए होते
किसी भी घटना को एक चतुर शोषण की जरूरत नहीं थी। दोनों ने "latest" में स्वचालित विश्वास पर निर्भर किए। तो:
- अपनी लॉकफ़ाइल कमिट करें और `npm ci ` के साथ इंस्टॉल करें। यह लॉकफ़ाइल जो कहती है वह बिल्कुल इंस्टॉल करता है और अगर
package.jsonअसहमत हो तो विफल हो जाता है। विषाक्त रिलीज़ में कोई मूक ड्रिफ्ट नहीं। - एक कूलडाउन जोड़ें। प्रकाशित होने के घंटे वर्जन को अपनाएँ नहीं। pnpm इसके लिए एक न्यूनतम रिलीज़ आयु सेटिंग दस्तावेज़ करता है। एक दिन का भी विलंब chalk/debug विंडो को पूरी तरह बैठा देता।
- जहाँ संभव हो इंस्टॉल स्क्रिप्ट्स को अक्षम करें। Shai-Hulud जैसे वर्म लाइफसाइकल स्क्रिप्ट्स के माध्यम से चलते हैं। एक उदाहरण
.npmrcलाइन:ignore-scripts=true। फिर उन कुछ पैकेजों को अनुमति-सूची दें जिन्हें सच में एक बिल्ड स्टेप की आवश्यकता है। - CI टोकन को स्कोप करें। एक बिल्ड जॉब को शायद ही कभी पब्लिश राइट्स या व्यापक क्लाउड कीज़ की ज़रूरत होती है। अल्पकालीन, न्यूनतम-सुविधा क्रेडेंशियल्स का मतलब है कि चोरी किया गया टोकन बहुत कम हासिल कर सकता है।
- CISA की सलाह का पालन करें। लॉकफाइलें देखें, नेस्टेड डिपेंडेंसी सहित; आर्टिफैक्ट कैश जांचें; ज्ञात-सुरक्षित संस्करणों पर पिन करें; डेवलपर क्रेडेंशियल्स रोटेट करें; npm और GitHub पर फिशिंग-प्रतिरोधी MFA की मांग करें; और सीक्रेट स्कैनिंग, Dependabot और ब्रांच प्रोटेक्शन चालू करें।
यही संदेह dev एनवायरनमेंट में अब बैठी AI टूलिंग पर भी लागू होता है। मैंने Claude Code स्किल्स, प्लगइन्स और MCP सर्वर्स को वेट करने का तरीका लिखा क्योंकि वे तीसरे पक्ष के कोड को आपके टोकन के पास लाने का एक और तरीका हैं।
Headless WordPress: थीम को छिपाना, PHP को नहीं
यह वह हिस्सा है जो टीमों को चौंकाता है। Headless जाना पब्लिक थीम लेयर को हटाता है। यह WordPress को नहीं हटाता। PHP एप्लिकेशन, डेटाबेस, REST API और wp-admin सभी अभी भी वहां हैं, आमतौर पर एक पब्लिक होस्टनेम पर, क्योंकि फ्रंट एंड को उन तक पहुंचने की ज़रूरत है।
wp2shell
2026 का उदाहरण सीधा है। CVE-2026-63030 (REST API batch-route भ्रम, CVSS 9.8) को CVE-2026-60137 (WP_Query author__not_in में SQL इंजेक्शन, CVSS 5.9) के साथ जोड़ा जाता है, जो WordPress 6.9.0 से 7.0.1 पर अनप्रमाणित रिमोट कोड एक्सीक्यूशन देता है। डिफ़ॉल्ट इंस्टॉल। कोई प्लगइन नहीं चाहिए। एंट्री पॉइंट है /wp-json/batch/v1। 17 जुलाई 2026 को 7.0.2, 6.9.5 और 6.8.6 में फिक्सेस आए, जैसा कि Tenable के FAQ में बताया गया है।
हमलावर तेज़ थे। Patchstack ने 7.0.2 रिलीज़ के लगभग 90 मिनट बाद पहली एक्सप्लॉइटेशन का प्रयास देखा, 1,500 से अधिक IPs से 65,000 से अधिक प्रयासों को ब्लॉक किया, और पाया कि 97% batch एंडपॉइंट को लक्षित करते थे। फायरवॉल पर निर्भर करने वाले किसी के लिए एक और विवरण मायने रखता है: URL-केवल WAF नियम पर्याप्त नहीं हैं, क्योंकि WordPress POST बॉडी में rest_route स्वीकार करता है। एक नियम जो पथ में /wp-json/batch/v1 से मेल खाता है, इसे मिस करता है।
बैकएंड को लॉक करना
लक्ष्य: WordPress origin को ऐसा कुछ बनाना जो अजनबी तक नहीं पहुंच सकते, बजाय इसके कि जो केवल समय पर पैच होने की उम्मीद करता है।
- जहां संभव हो, origin को पब्लिक इंटरनेट से दूर रखें। IP allowlist, एक प्रमाणीकरण प्रॉक्सी, या फ्रंट एंड और CMS के बीच एक निजी नेटवर्क। अगर आप एक स्टैटिक साइट के लिए बिल्ड समय पर कंटेंट पुल करते हैं, तो origin को केवल आपके बिल्ड रनर से बात करनी चाहिए।
- केवल वह फील्ड्स expose करें जो फ्रंट एंड उपयोग करता है। REST रेस्पांसेज़ और GraphQL स्किमा को ट्रिम करें। कम डेटा बाहर, दुरुपयोग के लिए कम।
- अप्रयुक्त रूट्स को डिसेबल करें, batch एंडपॉइंट सहित, अगर आपके स्टैक में कुछ भी इसे कॉल नहीं करता।
- WPGraphQL को प्रतिबंधित करें। पब्लिक इंट्रोस्पेक्शन और अनप्रमाणित क्वेरीज़ को बंद करें जब तक आप वाकई उन्हें चाहते नहीं हों।
- एप्लिकेशन पासवर्ड और प्रीव्यू टोकन को स्कोप करें। प्रति इंटीग्रेशन एक, न्यूनतम सुविधा, इंटीग्रेशन समाप्त होने पर रिवोक किया गया।
- कोर ऑटो-अपडेट्स चालू रखें। 90-मिनट की एक्सप्लॉइटेशन विंडो के साथ, एक मैनुअल साप्ताहिक पैच दिन गलत cadence है।
अगर आप इस हिस्से को विशेषज्ञों को सौंपना पसंद करते हैं, तो हमकी WordPress security service बैकएंड को लॉक करना और निगरानी रखना कवर करती है। इसके चारों ओर की आर्किटेक्चर के लिए, headless WordPress 2026 guide और हमारा headless WordPress development पेज देखें।
होस्टिंग और edge कंट्रोल्स
प्लेटफॉर्म इस बात में भिन्न होते हैं कि वे क्या सुरक्षा देते हैं, और यह जानने लायक है कि विशिष्ट बातें क्या हैं, बजाय यह मान लिए कि यह ऐसा ही है। CVE-2025-29927 लें: Vercel-होस्टेड ऐप्स इंफ्रास्ट्रक्चर स्तर पर सुरक्षित थे जबकि self-होस्टेड वाले नहीं थे। यह एक वास्तविक, दस्तावेज़ किया गया लाभ है एक प्रबंधित प्लेटफॉर्म का। Netlify और Cloudflare भी उनके edge पर सुरक्षात्मक लेयर्स चलाते हैं (WAF फीचर्स, DDoS शमन, प्रबंधित नियम, योजना के आधार पर)। Self-होस्टिंग आपको नियंत्रण देता है और वह लेयर्स आपकी to-do सूची पर रखता है।
ईमानदार फ्रेमिंग: edge सुरक्षाएं आपको समय खरीदती हैं। वे पैचिंग की जगह नहीं लेते। एक प्लेटफॉर्म नियम जो आज एक एक्सप्लॉइट पैटर्न को ब्लॉक करता है, अगली सलाह के बारे में कुछ नहीं कहता, और एक अच्छी तरह से चलाई गई पैच पाइपलाइन वाली self-होस्टेड सेटअप बिल्कुल ध्वनि हो सकती है।
जहाँ भी आप होस्ट करें, वहाँ ये कॉन्फ़िगर करें:
- WAF rules जो सिर्फ पाथ नहीं, बॉडी को भी इंस्पेक्ट करें। wp2shell
rest_routeडिटेल एक उदाहरण है जो याद रखने लायक है। - Form हैंडलर, सर्वर actions, लॉगिन रूट्स और किसी भी ऐसे endpoint पर rate limits लगाएँ जो महँगे काम को ट्रिगर करता है। यह CVE-2025-55184 जैसे denial-of-service bugs को भी कम करता है।
- Image `remotePatterns`। Next.js में,
images.remotePatternsयह तय करते हैं कि इमेज optimiser कौन से remote hosts से fetch करेगा। Astro के पास equivalent image domain और pattern settings हैं। सिर्फ अपने CMS host को allow करें, बाकी कुछ नहीं। एक खुला image proxy SSRF का निमंत्रण है। - Cache-key review। Nuxt incident के अनुसार, जानें कि आपका CDN क्या ignore करता है।
- Origin protection। ऐप origin को सेट करें ताकि वह सिर्फ आपके CDN या प्लेटफॉर्म से ट्रैफिक स्वीकार करे (जहाँ सेटअप इसे allow करता हो), ताकि attackers edge को skip न कर सकें।
अगर आप Next.js पर बना रहे हैं और उसके पीछे database है, तो Next.js और Supabase development page दिखाता है कि हम server-side access को कैसे scope करते हैं।
हार्डनिंग checklist
इसे अपने stack के हिसाब से adapt करें। नीचे दिए गए हर incident का स्रोत पहले के citations में है; version numbers के लिए हर linked advisory में current fixed versions की पुष्टि करें, न कि किसी table (इसे भी शामिल) पर भरोसा करें।
| परत | रिस्क | Real 2025-26 उदाहरण | Control | कैसे check करें |
|---|---|---|---|---|
| Next.js | RSC remote code execution; DoS; source exposure; middleware-only auth | CVE-2025-55182 / CVE-2025-66478 (3 Dec 2025); CVE-2025-55184, CVE-2025-55183 (11 Dec 2025); CVE-2025-29927 (21 Mar 2025) | अपनी line के लिए patched release में upgrade करें; data layer, actions और route handlers में authorise करें; server functions में कोई hard-coded secrets न रखें; images.remotePatterns को restrict करें | Advisory के विरुद्ध npm ls next react चलाएँ; code में secret literals के लिए search करें; test करें कि protected data proxy.ts disabled होने पर भी protected रहता है |
| Astro | Server islands XSS; image endpoint SSRF; middleware path bypass | CVE-2025-64764 (19 Nov 2025); CVE-2025-58179; CVE-2025-64765 | Astro और @astrojs/cloudflare को upgrade करें; Astro 6 पर security.csp enable करें; image sources को allow-list करें; auth के लिए URL matching पर निर्भर न रहें | Advisories के विरुद्ध npm ls astro @astrojs/cloudflare चलाएँ; response headers को build या preview पर inspect करें, dev पर नहीं |
| Nuxt | CDN payload cache poisoning; public config में secrets | CVE-2025-27415 (19 Mar 2025) | 3.16.0 या उसके बाद का version चलाएँ; cache key में query string शामिल करें या internal routes को caching से exclude करें; runtimeConfig.public में सिर्फ non-secret values रखें | Staging पर, /?/_payload.json request करें फिर clean URL करें और HTML की पुष्टि करें; built output में token fragments के लिए grep करें |
| Headless WordPress बैकेंड | REST batch route के माध्यम से अप्रमाणित RCE; सार्वजनिक admin और API सतह | wp2shell: CVE-2026-63030 + CVE-2026-60137 (17 जुलाई 2026 को ठीक किया गया) | कोर को auto-updates के साथ पैच किया गया; मूल allowlist या proxy के पीछे; अप्रयुक्त routes अक्षम; WPGraphQL introspection प्रतिबंधित; scoped app passwords | डैशबोर्ड में कोर संस्करण जाँचें; अपनी allowlist के बाहर से /wp-json/batch/v1 को अनुरोध करें; पुष्टि करें कि WAF POST bodies की जाँच करता है |
| Build pipeline | Poisoned dependency; चोरी किए गए CI और developer tokens | chalk/debug (8 सितंबर 2025); Shai-Hulud (CISA, 23 सितंबर 2025) | Committed lockfile और npm ci; install scripts बंद; release-age cooldown; scoped, short-lived CI tokens; phishing-resistant MFA; secret scanning | Pull requests में lockfile diffs की समीक्षा करें; CI token scopes को audit करें; पुष्टि करें कि Dependabot, secret scanning और branch protection सक्षम हैं |
FAQ
क्या Pages Router दिसंबर 2025 की Next.js समस्याओं से प्रभावित है?
CVE-2025-55183 (source code exposure) और CVE-2025-55184 (denial of service) के लिए, Next.js advisory प्रभावित path को App Router with Server Functions के रूप में बताता है, और कहता है कि Pages Router source exposure से प्रभावित नहीं है। इसे "हमेशा के लिए सुरक्षित" के रूप में न पढ़ें। React2Shell ने App Router में React Server Components को भी लक्षित किया था, और आप अभी भी एक patched release पर होने की जरूरत है। दिसंबर 2025 advisory में अपनी सटीक version line के लिए जाँचें।
क्या मुझे patching के बाद secrets को rotate करना चाहिए?
अगर कोई secret कभी एक affected Next.js version पर एक server function में hard-coded था, तो हाँ। मान लें कि इसे पढ़ा जा सकता था, क्योंकि बग ने compiled source को return किया था। इसे rotate करें, फिर replacement को एक runtime env var में ले जाएँ। Secrets जो केवल environment से पढ़े गए थे, उस source में नहीं थे, इसलिए उनके लिए exposure argument बहुत कमजोर है।
हर changelog को पढ़े बिना advisories के साथ अपडेट कैसे रहूँ?
उन repos के लिए GitHub security advisories को देखें जिन पर आप निर्भर करते हैं (Next.js, withastro/astro, Nuxt), और अपने repositories के लिए Dependabot alerts चालू करें। जो कोई patching का मालिक है, उन feeds को इसके लिए subscribe करें, एक shared inbox के लिए नहीं जिसे कोई नहीं पढ़ता। WordPress core के लिए, auto-updates को चालू रखें और Patchstack जैसे एक vulnerability feed जोड़ें।
क्या मैं wp-admin को सार्वजनिक रख सकता हूँ अगर front end केवल build time पर content pull करता है?
आप कर सकते हैं, लेकिन आपको नहीं करना चाहिए। अगर front end को builds के दौरान origin की जरूरत है, तो इसे सभी के लिए expose करने का कोई कारण नहीं है। अपने build runner और अपने editors के IPs को allowlist करें, या एक authenticating proxy सामने रखें। Changing IPs पर editors आमतौर पर शिकायत होता है, और single sign-on के साथ एक proxy इसे हल करता है।
Patch speed और cache-key config वे दो चीजें हैं जो teams अक्सर गलत करते हैं: Next.js और WordPress exploits disclosure के दिनों या घंटों के भीतर आए, और Nuxt बग केवल इसलिए मौजूद था क्योंकि एक CDN ने query string को ignore किया। जाँचें कि request time पर वास्तव में क्या चलता है, proxy के बजाय data layer में authorize करें, और WordPress origin को open internet से दूर रखें।