फ़्रंटएंड इंटरव्यू: आप CORS प्रीफ़्लाइट और क्रेडेंशियल वाले अनुरोधों को कैसे डीबग करते हैं?

प्रश्न और यह कब लागू होता है

पेज https://app.example.com पर चलता है, जबकि API https://api.example.com पर है। फ़्रंटएंड एक उपयोगकर्ता प्राथमिकता सबमिट करता है:

await fetch("https://api.example.com/profile/preferences", {
  method: "POST",
  credentials: "include",
  headers: {
    "Content-Type": "application/json",
    "X-CSRF-Token": csrfToken,
  },
  body: JSON.stringify({ compactMode: true }),
})

सर्वर वर्तमान में OPTIONS के लिए यह रिस्पॉन्स लौटाता है:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST

curl के माध्यम से एक सीधा POST सफल होता है, लेकिन ब्राउज़र कंसोल केवल एक क्रॉस-ऑरिजिन त्रुटि की रिपोर्ट करता है। समझाएं:

1. दोनों सबडोमेन अभी भी क्रॉस-ऑरिजिन क्यों हैं;
2. ब्राउज़र पहले OPTIONS क्यों भेजता है और यह कब POST के साथ आगे बढ़ेगा;
3. वर्तमान रिस्पॉन्स हेडर में क्या खराबी है और न्यूनतम-अधिकार समाधान कैसे लागू किया जाए;
4. CORS, कुकीज़, प्रमाणीकरण (authentication), प्राधिकरण (authorization) और CSRF की अलग-अलग ज़िम्मेदारियाँ;
5. डेवलपर टूल्स और स्वचालित परीक्षणों में समाधान को कैसे साबित करें।

यह फ़्रंटएंड और फुल-स्टैक इंटरव्यू के लिए उपयोगी है। यह परीक्षा इस बात की नहीं है कि कोई हेडर के सेट को याद करके सुना सकता है या नहीं। यह इस बारे में है कि क्या वे ब्राउज़र के नेटवर्क चरणों से पीछे की ओर काम कर सकते हैं और चार प्रश्नों को अलग कर सकते हैं: क्या अनुरोध भेजा गया था, क्या क्रेडेंशियल संलग्न थे, क्या JavaScript रिस्पॉन्स पढ़ सकता है, और क्या एप्लिकेशन ने ऑपरेशन को अधिकृत किया था?

इंटरव्यूअर क्या मूल्यांकन कर रहा है

सबसे पहले, उम्मीदवार को ऑरिजिन को सटीक रूप से पहचानना चाहिए। एक ऑरिजिन में स्कीम, होस्ट और पोर्ट शामिल होते हैं। दोनों URL HTTPS का उपयोग करते हैं और सामान्यतः same-site हैं, लेकिन उनके होस्ट भिन्न हैं, इसलिए अनुरोध same-site और cross-origin है। CORS ऑरिजिन-आधारित है; कुकी SameSite विशेषता साइट-आधारित है। वे विनिमेय (interchangeable) नहीं हैं।

दूसरा, उम्मीदवार को प्रीफ़्लाइट ट्रिगर्स को समझना चाहिए। application/json एक CORS-सुरक्षित सूची (CORS-safelisted) में शामिल अनुरोध-हेडर मान नहीं है, और X-CSRF-Token सुरक्षित सूची में शामिल अनुरोध हेडर नहीं है। इसलिए ब्राउज़र यह पूछने के लिए OPTIONS भेजता है कि क्या वास्तविक मेथड और हेडर की अनुमति है। यदि प्रीफ़्लाइट विफल हो जाता है, तो POST नहीं भेजा जाता है।

तीसरा, उम्मीदवार को दो सीधे कॉन्फ़िगरेशन दोषों को पहचानना चाहिए। क्रेडेंशियल वाले रिस्पॉन्स में Access-Control-Allow-Origin: * का उपयोग नहीं किया जा सकता है, और प्रीफ़्लाइट रिस्पॉन्स Content-Type या X-CSRF-Token की अनुमति नहीं देता है। अनुमत मेथड के तहत POST को सूचीबद्ध करना पर्याप्त नहीं है।

अंत में, उम्मीदवार को सुरक्षा सीमा को बनाए रखना चाहिए। CORS नियंत्रित करता है कि क्या ब्राउज़र स्क्रिप्ट के साथ एक क्रॉस-ऑरिजिन रिस्पॉन्स साझा करता है। यह प्रमाणीकरण, प्राधिकरण या CSRF सुरक्षा की जगह नहीं लेता है। सर्वर को केवल कंसोल त्रुटि को शांत करने के लिए या प्रत्येक मेथड और हेडर की अनुमति देने के लिए मनमाने ऑरिजिन को प्रतिबिंबित (reflect) नहीं करना चाहिए।

पहले स्पष्ट करने योग्य प्रश्न

• यह किस नेटवर्क चरण में विफल होता है? कोई अनुरोध नहीं, केवल OPTIONS, या एक पूर्ण POST जिसका रिस्पॉन्स

JavaScript के लिए अनुपलब्ध है, अलग-अलग विफलताओं की ओर इशारा करते हैं।

• क्या अनुरोध में कुकी होना आवश्यक है? एक बियरर टोकन (bearer token) या अनाम सार्वजनिक संसाधन क्रेडेंशियल और

अनुमत-ऑरिजिन नीति को बदल देता है।

• सटीक रूप से कौन से फ़्रंटएंड ऑरिजिन अनुमत हैं? प्रोडक्शन, स्टेजिंग और स्थानीय डेवलपमेंट के लिए स्पष्ट ऑरिजिन की

आवश्यकता होती है, जिसमें स्कीम और पोर्ट शामिल हैं। "कंपनी का डोमेन" पर्याप्त सटीक नहीं है।

• क्या कोई गेटवे, प्रमाणीकरण मिडलवेयर, या रीडायरेक्ट OPTIONS को रोकता है? एक प्रीफ़्लाइट में सामान्यतः कोई

उपयोगकर्ता क्रेडेंशियल नहीं होते हैं, इसलिए इसे पहले लॉगिन प्रमाणीकरण पास करने की आवश्यकता नहीं हो सकती है।

• कुकी की Domain, Path, Secure और SameSite विशेषताएँ क्या हैं? CORS पास करने से यह गारंटी नहीं मिलती है

कि ब्राउज़र कुकी भेजेगा।

• क्या वास्तविक और त्रुटि रिस्पॉन्स सभी में CORS हेडर होते हैं? यदि 401, 403, या 500 रिस्पॉन्स अनुमत-ऑरिजिन

हेडर खो देते हैं, तो ब्राउज़र वास्तविक स्थिति को एक सामान्य CORS त्रुटि के पीछे छिपा सकता है।

• क्या कोई CDN या साझा कैश है? यदि कोई रिस्पॉन्स Origin के अनुसार बदलता है, तो Vary: Origin भेजें ताकि

एक ऑरिजिन का रिस्पॉन्स दूसरे के लिए पुन: उपयोग न किया जाए।

30-सेकंड का उत्तर ढांचा

"मैं इसे चार फाटकों में विभाजित करूँगा: ऑरिजिन, प्रीफ़्लाइट अनुमति, क्रेडेंशियल परिवहन और रिस्पॉन्स साझाकरण। होस्ट अलग हैं, इसलिए अनुरोध क्रॉस-ऑरिजिन है। JSON Content-Type और X-CSRF-Token एक OPTIONS प्रीफ़्लाइट को ट्रिगर करते हैं। ब्राउज़र POST तभी भेजता है जब रिस्पॉन्स सटीक ऑरिजिन, POST और दोनों हेडर की अनुमति देता है। चूंकि fetch credentials: include का उपयोग करता है, Allow-Origin वाइल्डकार्ड नहीं हो सकता है। एक सटीक अनुमति सूची मिलान के बाद, सर्वर को https://app.example.com, Allow-Credentials और Vary: Origin लौटाना चाहिए। OPTIONS स्वयं लॉगिन कुकी पर निर्भर नहीं करता है; POST को अभी भी प्रमाणीकरण, प्राधिकरण और CSRF सत्यापन की आवश्यकता है। मैं Network पैनल में OPTIONS, POST, कुकीज़, रिस्पॉन्स हेडर और एप्लिकेशन स्थिति को सत्यापित करूँगा, फिर एक सकारात्मक और शत्रुतापूर्ण-ऑरिजिन परीक्षण मैट्रिक्स चलाऊँगा।"

चरण-दर-चरण गहन विश्लेषण

चरण एक: ब्राउज़र द्वारा वास्तव में चलाए जाने वाले स्टेट मशीन को मॉडल करें।

प्रीफ़्लाइट लगभग इस प्रकार है:

OPTIONS /profile/preferences HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type,x-csrf-token

ब्राउज़र यह नहीं पूछता कि क्या फ़्रंटएंड और बैकएंड एक ही कंपनी से संबंधित हैं। यह पूछता है कि क्या रिस्पॉन्स स्पष्ट रूप से इस Origin, मेथड और हेडर सेट की अनुमति देता है। निम्नलिखित साक्ष्य प्रत्येक चरण को अलग करते हैं:

चरण दो: अनुरोध से न्यूनतम अनुमति सेट प्राप्त करें।

प्रश्न में दिए गए एकल प्रोडक्शन फ़्रंटएंड के लिए, लौटाएं:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, X-CSRF-Token
Vary: Origin

सर्वर को Origin की तुलना एक सटीक अनुमति सूची से करनी चाहिए और मिलान के बाद ही इसे वापस लिखना चाहिए। क्लाइंट द्वारा आपूर्ति किए गए Origin को बिना शर्त कॉपी न करें। यदि स्टेजिंग और स्थानीय परिवेश भी अनुमत हैं, तो प्रत्येक पूर्ण ऑरिजिन को उसके संबंधित परिवेश में सूचीबद्ध करें। एक प्रत्यय (suffix) मिलान एक मिलते-जुलते हमलावर डोमेन को स्वीकार कर सकता है।

वाइल्डकार्ड एक सार्वजनिक, अनाम, गैर-क्रेडेंशियल वाले संसाधन के लिए उपयुक्त हो सकता है। यह उपयोगकर्ता-प्राथमिकता एंडपॉइंट एक कुकी रखता है और एक संवेदनशील ऑपरेशन करता है, इसलिए इसे एक विशिष्ट ऑरिजिन की आवश्यकता होती है। प्रीफ़्लाइट OPTIONS में कोई कुकी नहीं होती है। एक गेटवे Origin, मेथड और अनुरोध हेडर को सख्ती से सत्यापित करते हुए प्रमाणीकरण से पहले इसे संभाल सकता है।

चरण तीन: वास्तविक अनुरोध और क्रेडेंशियल का अलग-अलग निरीक्षण करें।

ब्राउज़र एक सफल प्रीफ़्लाइट के बाद ही POST भेजता है। credentials: "include" एक क्रॉस-ऑरिजिन अनुरोध को क्रेडेंशियल प्रोसेसिंग में प्रवेश करने देता है, लेकिन Domain, Path, Secure, SameSite और ब्राउज़र गोपनीयता नीतियां अभी भी यह तय करती हैं कि कुकी संलग्न है या नहीं।

ये दो HTTPS सबडोमेन सामान्यतः same-site और cross-origin हैं। SameSite कुकी की अनुमति दे सकता है जबकि CORS अभी भी लागू होता है। "CORS पास हो गया" का अर्थ यह नहीं है कि "कुकी भेजी गई थी", और "कुकी भेजी गई थी" का अर्थ यह नहीं है कि "स्क्रिप्ट रिस्पॉन्स पढ़ सकती है।" Network पैनल में अलग-अलग तथ्यों के रूप में Request Cookies, रिस्पॉन्स स्थिति और CORS रिस्पॉन्स हेडर का निरीक्षण करें।

चरण चार: CORS को एप्लिकेशन सुरक्षा से अलग करें।

CORS एक ब्राउज़र रिस्पॉन्स-साझाकरण प्रोटोकॉल है, सर्वर-साइड एक्सेस नियंत्रण नहीं। Curl और सर्वर-साइड HTTP क्लाइंट ब्राउज़र की समान-ऑरिजिन नीति (same-origin policy) को लागू नहीं करते हैं। एक सफल curl कॉल यह साबित करती है कि API अनुरोध को संभाल सकता है, न कि यह कि ब्राउज़र पथ सही है।

POST को अभी भी:

• उपयोगकर्ता को प्रमाणित करना चाहिए;
• उस उपयोगकर्ता को लक्षित संसाधन को संशोधित करने के लिए अधिकृत करना चाहिए;
• CSRF टोकन को मान्य करना चाहिए या समान रूप से मजबूत सुरक्षा का उपयोग करना चाहिए;
• इनपुट को मान्य करना चाहिए और आइडेम्पोटेंसी या डुप्लिकेट-सबमिशन व्यवहार को परिभाषित करना चाहिए;
• अनुमत-ऑरिजिन 401, 403, और 500 रिस्पॉन्स पर सही CORS हेडर लौटाना चाहिए ताकि फ़्रंटएंड वास्तविक त्रुटि देख सके।

"शत्रुतापूर्ण पेज रिस्पॉन्स नहीं पढ़ सकता है" का अर्थ यह नहीं है कि "अनुरोध का कोई साइड इफेक्ट नहीं हुआ।" कुछ फ़ॉर्म-जैसे क्रॉस-ऑरिजिन अनुरोधों को प्रीफ़्लाइट की आवश्यकता नहीं होती है और वे सर्वर तक पहुँच सकते हैं। संवेदनशील राइट्स CSRF सुरक्षा के लिए केवल CORS पर निर्भर नहीं हो सकते हैं।

चरण पाँच: सकारात्मक और नकारात्मक परीक्षणों के साथ सीमा को साबित करें।

समाधान के बाद, कम से कम निम्नलिखित को सत्यापित करें:

इसे सर्वर लॉग के साथ सहसंबद्ध करें। एक विफल प्रीफ़्लाइट में कोई मिलान करने वाला POST और कोई प्राथमिकता अपडेट नहीं होना चाहिए। लॉग Origin, मेथड, हेडर नाम और अस्वीकृति का कारण रिकॉर्ड कर सकते हैं, लेकिन कुकी या CSRF टोकन मान नहीं।

एक मजबूत उत्तर का उदाहरण

"मैं पहले नेटवर्क चरण की पहचान करूँगा। app.example.com और api.example.com के होस्ट भिन्न हैं, इसलिए वे same-site होने के बावजूद क्रॉस-ऑरिजिन हैं। POST JSON Content-Type और X-CSRF-Token का उपयोग करता है, इसलिए ब्राउज़र पहले कुकीज़ के बिना एक OPTIONS अनुरोध भेजता है। यह Origin, POST और दो गैर-सरल हेडर घोषित करता है। ब्राउज़र POST तभी भेजता है जब प्रीफ़्लाइट रिस्पॉन्स तीनों की अनुमति देता है।

वर्तमान कॉन्फ़िगरेशन में दो प्रत्यक्ष दोष हैं। पहला, फ़्रंटएंड credentials: include सेट करता है, इसलिए क्रेडेंशियल वाला रिस्पॉन्स Access-Control-Allow-Origin के लिए वाइल्डकार्ड का उपयोग नहीं कर सकता है। दूसरा, रिस्पॉन्स में Access-Control-Allow-Headers: Content-Type, X-CSRF-Token शामिल नहीं है। मैं सर्वर की एक सटीक अनुमति सूची के विरुद्ध Origin को मान्य करूँगा। https://app.example.com के लिए, मैं उस विशिष्ट मान, Allow-Credentials, POST, दोनों अनुमत हेडर और Vary: Origin लौटाऊँगा। OPTIONS को उपयोगकर्ता-प्रमाणीकरण मिडलवेयर से पहले संभाला जा सकता है, लेकिन एक अस्वीकृत ऑरिजिन, मेथड या हेडर को अभी भी अस्वीकार कर दिया जाता है।

प्रीफ़्लाइट पास होने के बाद, मैं POST पर Request Cookies का निरीक्षण करूँगा। credentials: include आवश्यक है लेकिन पर्याप्त नहीं है; Domain, Path, Secure, SameSite और ब्राउज़र नीतियां अभी भी लागू होती हैं। POST को प्रमाणित, अधिकृत और CSRF को मान्य करना जारी रखना चाहिए क्योंकि CORS एक्सेस नियंत्रण को नहीं, बल्कि रिस्पॉन्स साझाकरण को नियंत्रित करता है।

सत्यापन के लिए, मैं Network पैनल में पुष्टि करूँगा कि POST केवल एक सफल OPTIONS के बाद ही दिखाई देता है, फिर कुकीज़, वास्तविक स्थिति और रिस्पॉन्स हेडर का निरीक्षण करूँगा। मैं एक अनुमत ऑरिजिन, एक अस्वीकृत ऑरिजिन, एक अस्वीकृत मेथड, एक समाप्त लॉगिन और एक 500 रिस्पॉन्स का परीक्षण करूँगा। सर्वर लॉग को यह साबित करना होगा कि विफल प्रीफ़्लाइट में कोई POST नहीं है और कोई स्थिति परिवर्तन नहीं हुआ है। Curl एक API आधार रेखा है, ब्राउज़र CORS साक्ष्य का विकल्प नहीं।"

सामान्य गलतियाँ

• same-site को same-origin मानना → विभिन्न सबडोमेन अभी भी CORS लागू करते हैं → **स्कीम, होस्ट

और पोर्ट की तुलना करें।**

• यह मान लेना कि Allow-Methods में POST पर्याप्त है → गैर-सरल हेडर अनुमत नहीं हैं → **Origin,

Method और Headers को एक साथ जांचें।**

• क्रेडेंशियल के साथ Allow-Origin: * का उपयोग करना → ब्राउज़र रिस्पॉन्स दिखाने से इंकार कर देता है → **सटीक

अनुमति सूची वाला ऑरिजिन लौटाएं।**

• प्रत्येक अनुरोधित Origin को प्रतिबिंबित करना → कोई भी साइट क्रेडेंशियल वाले रिस्पॉन्स के लिए पढ़ने की पहुंच प्राप्त कर सकती है → **पहले

एक सटीक अनुमति सूची से मिलान करें।**

• लॉग-इन उपयोगकर्ता के रूप में OPTIONS को प्रमाणित करना → प्रीफ़्लाइट में सामान्यतः कोई क्रेडेंशियल नहीं होते हैं → **उपयोगकर्ता

प्रमाणीकरण से पहले एक सीमित प्रीफ़्लाइट जाँच करें।**

• समाधान के रूप में mode: "no-cors" का उपयोग करना → फ़्रंटएंड को एक अपठनीय opaque रिस्पॉन्स प्राप्त होता है → **सर्वर के

CORS प्रोटोकॉल को ठीक करें।**

• CORS को CSRF सुरक्षा के रूप में मानना → एक अनुरोध सर्वर तक पहुँच सकता है और साइड इफेक्ट पैदा कर सकता है → **संवेदनशील

राइट्स पर CSRF और प्राधिकरण जाँच बनाए रखें।**

• केवल 2xx रिस्पॉन्स में CORS हेडर जोड़ना → एक 401 या 500 एक क्रॉस-ऑरिजिन त्रुटि के रूप में प्रच्छन्न हो जाता है → **अनुमत

ऑरिजिन के लिए त्रुटियों पर सुसंगत CORS हेडर का उपयोग करें।**

• केवल curl के साथ परीक्षण करना → Curl ब्राउज़र की समान-ऑरिजिन नीति लागू नहीं करता है → **वास्तविक ब्राउज़र

नेटवर्क साक्ष्य के साथ सत्यापित करें।**

अनुवर्ती प्रश्न

कोई अनुरोध OPTIONS को छोड़ कर भी CORS में विफल क्यों हो सकता है?

सुरक्षित सूची में शामिल मेथड, हेडर और Content-Type का उपयोग करने वाला अनुरोध सीधे भेजा जा सकता है। ब्राउज़र अभी भी वास्तविक रिस्पॉन्स के CORS हेडर की जाँच करता है। यदि रिस्पॉन्स साझाकरण की अनुमति नहीं है, तो JavaScript इसे नहीं पढ़ सकता है, भले ही सर्वर ने इसे संसाधित किया हो। नेटवर्क साक्ष्य को "भेजा गया लेकिन साझा नहीं किया गया" और एक विफल प्रीफ़्लाइट के बीच अंतर करना चाहिए।

Access-Control-Allow-Credentials प्रीफ़्लाइट अनुरोध में क्यों नहीं दिखना चाहिए?

यह एक सर्वर रिस्पॉन्स हेडर है जो यह दर्शाता है कि ब्राउज़र क्रेडेंशियल मोड में किए गए वास्तविक अनुरोध के रिस्पॉन्स को उजागर कर सकता है। क्लाइंट Fetch के credentials मोड के माध्यम से अपना इरादा व्यक्त करता है; प्रीफ़्लाइट में स्वयं कोई उपयोगकर्ता क्रेडेंशियल नहीं होते हैं। वास्तविक रिस्पॉन्स को विशिष्ट-ऑरिजिन और Allow-Credentials शर्तों को भी पूरा करना होगा।

Vary: Origin किस समस्या का समाधान करता है?

जब कोई सर्वर अनुरोध Origin के आधार पर Access-Control-Allow-Origin चुनता है, तो एक साझा कैश को अपनी कैश कुंजी में Origin को शामिल करना होगा। अन्यथा, एक अनुमत ऑरिजिन के रिस्पॉन्स को दूसरे के लिए पुन: उपयोग किया जा सकता है, जिससे गलत अस्वीकृति या प्रकटीकरण (disclosure) हो सकता है।

CORS ठीक होने के बाद भी कुकी क्यों गायब है?

credentials: "include" की जाँच करें, फिर कुकी के Domain, Path, Secure, SameSite, समाप्ति और ब्राउज़र गोपनीयता प्रतिबंधों का निरीक्षण करें। CORS अनुमति और कुकी परिवहन निकटवर्ती लेकिन स्वतंत्र फाटक हैं।

कई वैध फ़्रंटएंड डोमेन का समर्थन कैसे किया जाना चाहिए?

एक सटीक अनुमति सूची बनाए रखें, पूर्ण अनुरोध Origin को मान्य करें, मिलान किए गए मान को वापस लिखें, और Vary: Origin भेजें। एकाधिक Allow-Origin मान न लौटाएं या अनुमेय रेगुलर एक्सप्रेशन, प्रत्यय मिलान, या बिना शर्त प्रतिबिंब का उपयोग न करें।

क्या फ़्रंटएंड अकेले सर्वर की CORS विफलता को ठीक कर सकता है?

नहीं। फ़्रंटएंड अनावश्यक गैर-सरल हेडर को हटा सकता है या इच्छित credentials मोड का चयन कर सकता है, लेकिन API, रिवर्स प्रॉक्सी या गेटवे को उन रिस्पॉन्स हेडर को लौटाना होगा जो क्रॉस-ऑरिजिन साझाकरण की अनुमति देते हैं। प्रोडक्शन कोड को ब्राउज़र एक्सटेंशन या सुरक्षा नियंत्रणों को अक्षम करने पर निर्भर नहीं होना चाहिए।

प्रीफ़्लाइट को कितने समय तक कैश किया जाना चाहिए?

कॉन्फ़िगरेशन परिवर्तनशीलता, निरसन आवश्यकताओं और ब्राउज़र सीमाओं के आधार पर अवधि चुनें। CORS परिवर्तन जारी करते समय, कोल्ड कैश और मौजूदा कैश्ड पथ दोनों का परीक्षण करें। कैशिंग OPTIONS ट्रैफ़िक को कम करती है लेकिन एक खराब अनुमति को लम्बा खींच सकती है, इसलिए इसे कॉन्फ़िगरेशन दोषों को छिपाना नहीं चाहिए।