प्रश्न और संदर्भ
Gateway API v1.5 ने HTTPRoute CORS फ़िल्टर को Standard चैनल में स्थानांतरित कर दिया है। यह एक रूट नियम को अनुमत ऑरिजिन, मेथड, रिक्वेस्ट हेडर, एक्सपोज़्ड हेडर और प्रीफ़्लाइट कैश समय घोषित करने की अनुमति देता है। यह प्रश्न परीक्षण करता है कि क्या आप सर्वर ऑथराइजेशन और कार्यान्वयन-विशिष्ट सत्यापन को बनाए रखते हुए सही गेटवे सीमा पर क्रॉस-ओरिजिन नीति लागू कर सकते हैं।
इंटरव्यूअर क्या मूल्यांकन करते हैं
इंटरव्यूअर ब्राउज़र CORS सुरक्षा, गेटवे रिस्पॉन्स हेडर और वास्तविक पहचान ऑथराइजेशन के बीच अंतर की समझ देखते हैं। एक मजबूत उत्तर में OPTIONS प्रीफ़्लाइट पाथ, क्रेडेंशियल्स और ऑरिजिन, वाइल्डकार्ड जोखिम, प्रति रूट न्यूनतम विशेषाधिकार (least privilege), और क्या Gateway कार्यान्वयन इस फ़िल्टर का समर्थन करता है, शामिल होता है। केवल allowOrigins: "*" लिखना एक सुरक्षित डिज़ाइन प्रदर्शित नहीं करता है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
किन ऑरिजिन और संसाधनों को क्रॉस-ओरिजिन एक्सेस की आवश्यकता है?
प्रोडक्शन, पूर्वावलोकन (preview), प्रशासन और स्थानीय-विकास ऑरिजिन की सूची बनाएं, और उन्हें पूरे डोमेन के बजाय प्रति रूट अधिकृत करें। सूची ऑडिट योग्य और समाप्त होने योग्य (expirable) होनी चाहिए, जिसमें परीक्षण ऑरिजिन को प्रोडक्शन से बाहर रखा जाए।
क्या क्रेडेंशियल्स शामिल हैं?
पुष्टि करें कि क्या अनुरोध कुकीज़, HTTP प्रमाणीकरण, या कोई अन्य क्रेडेंशियल ले जाते हैं। क्रेडेंशियल वाले अनुरोधों के लिए अधिक सख्त ऑरिजिन और रिस्पॉन्स-हेडर नीति की आवश्यकता होती है; मनमाने ऑरिजिन को डिफ़ॉल्ट रूप से क्रेडेंशियल्स के साथ संयोजित नहीं किया जाना चाहिए।
ऑथराइजेशन और नीति रिलीज़ का स्वामी कौन है?
Gateway, एप्लिकेशन और पहचान-सेवा की ज़िम्मेदारियों को परिभाषित करें। CORS यह नियंत्रित करता है कि क्या ब्राउज़र स्क्रिप्ट किसी रिस्पॉन्स को पढ़ सकती हैं; यह टोकन सत्यापन, टेनेंट अलगाव या संसाधन ऑथराइजेशन का स्थान नहीं लेता है।
30-सेकंड का उत्तर ढांचा
“मैं पहले पूरे Gateway को विस्तारित करने के बजाय HTTPRoute और व्यावसायिक संसाधन द्वारा ऑरिजिन का दायरा सीमित करता हूँ। प्रत्येक रूट के लिए मैं ऑरिजिन, मेथड, हेडर, एक्सपोज़्ड हेडर और maxAge निर्दिष्ट करता हूँ; क्रेडेंशियल वाले रूट समीक्षित ऑरिजिन और सत्यापित रिस्पॉन्स हेडर का उपयोग करते हैं। मैं OPTIONS प्रीफ़्लाइट, वास्तविक अनुरोध, त्रुटियों और कैश समाप्ति का परीक्षण करता हूँ, और पुष्टि करता हूँ कि Gateway कार्यान्वयन फ़िल्टर का समर्थन करता है। अंत में, मैं सर्वर ऑथराइजेशन, ऑडिट और रोलबैक से अलग ब्राउज़र एक्सेस सीमा के रूप में CORS को सत्यापित करता हूँ।”
चरण-दर-चरण विस्तृत उत्तर
चरण 1: प्रति रूट न्यूनतम विशेषाधिकार बनाएं
प्रत्येक HTTPRoute के लिए संसाधन, ऑरिजिन, अनुमत मेथड और हेडर आवश्यकताओं को रिकॉर्ड करें। सार्वजनिक केवल-पढ़ने योग्य संसाधनों और क्रेडेंशियल वाले खाता संसाधनों को अलग-अलग नियमों का उपयोग करना चाहिए ताकि एक अनुमेय (permissive) नीति पूरे डोमेन को कवर न कर सके।
चरण 2: फ़िल्टर फ़ील्ड कॉन्फ़िगर करें
वास्तविक आवश्यकता के अनुसार allowOrigins, allowMethods, allowHeaders, exposeHeaders और maxAge सेट करें। कार्यान्वयन प्रलेखन और सुरक्षा नीति के विरुद्ध ऑरिजिन पैटर्न की समीक्षा करें; अनावश्यक वाइल्डकार्ड के बजाय स्पष्ट ऑरिजिन को प्राथमिकता दें।
चरण 3: प्रीफ़्लाइट को सही ढंग से संभालें
ब्राउज़र Origin, Access-Control-Request-Method और संभवतः Access-Control-Request-Headers के साथ OPTIONS भेजता है। Gateway को नीति-संगत CORS हेडर लौटाने चाहिए और CORS न समझने वाले बैकएंड पर प्रीफ़्लाइट अग्रेषित करने के बजाय अस्वीकृत अनुरोधों को स्पष्ट रूप से अस्वीकार करना चाहिए।
चरण 4: क्रेडेंशियल्स और ऑथराइजेशन को अलग करें
कुकी विशेषताओं, CSRF सुरक्षा, टोकन सत्यापन और सर्वर ऑथराइजेशन के साथ क्रेडेंशियल व्यवहार को डिज़ाइन करें। भले ही कोई ब्राउज़र स्क्रिप्ट एक्सेस को ब्लॉक कर दे, सर्वर को अनुरोध को स्वयं अधिकृत करना चाहिए।
चरण 5: कार्यान्वयन और रोलबैक सत्यापित करें
पुष्टि करें कि Gateway नियंत्रक v1.5 Standard CORS फ़िल्टर और इसके फ़ील्ड सिमेंटिक्स का समर्थन करता है। ब्राउज़र और curl के साथ प्रीफ़्लाइट, वास्तविक अनुरोधों, विफलताओं, रीडायरेक्ट और कैश व्यवहार को पुनरुत्पादित करें; नीति परिवर्तन, मेट्रिक्स और रोलबैक चरणों को रिकॉर्ड करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं एक सार्वजनिक खोज इंटरफ़ेस को क्रेडेंशियल वाले खाता इंटरफ़ेस से अलग रखते हुए, प्रति HTTPRoute ऑरिजिन का दायरा तय करूँगा। प्रत्येक नियम अनुमत ऑरिजिन, मेथड, अनुरोध हेडर, एक्सपोज़्ड हेडर और प्रीफ़्लाइट कैश समय निर्दिष्ट करेगा; क्रेडेंशियल वाले एक्सेस केवल समीक्षित प्रोडक्शन ऑरिजिन का उपयोग करेंगे। रिलीज़ से पहले मैं ब्राउज़र में त्रुटियों, रीडायरेक्ट और कैश समाप्ति सहित OPTIONS और वास्तविक अनुरोधों का परीक्षण करूँगा, फिर कॉन्फ़िगरेशन सक्रिय होने की पुष्टि करने के लिए curl और Gateway नियंत्रक स्थिति स्थितियों (status conditions) का उपयोग करूँगा। CORS केवल ब्राउज़र-रीड सीमा को परिभाषित करता है; सर्वर अभी भी पहचान, टेनेंट और संसाधन ऑथराइजेशन लागू करता है। किसी भी नियंत्रक सिमेंटिक अंतर को एप्लिकेशन-लेयर फ़ॉलबैक के साथ अनुकूलता मैट्रिक्स में ट्रैक किया जाएगा।
सामान्य गलतियाँ
- गलती: विश्व स्तर पर हर ऑरिजिन की अनुमति देना। → यह विफल क्यों होता है: कोई भी रूट ब्राउज़र स्क्रिप्ट द्वारा पढ़ने योग्य हो सकता है, जिससे ऑडिट और निरसन (revocation) मुश्किल हो जाता है। → समाधान: प्रति HTTPRoute सबसे छोटा ऑरिजिन सेट बनाएं।
- गलती: केवल वास्तविक अनुरोधों को कॉन्फ़िगर करना और OPTIONS की अनदेखी करना। → यह विफल क्यों होता है: जटिल मेथड या हेडर पहले प्रीफ़्लाइट द्वारा ब्लॉक हो जाते हैं। → समाधान: प्रीफ़्लाइट और वास्तविक रिस्पॉन्स का अलग-अलग परीक्षण करें।
- गलती: CORS को ऑथराइजेशन के रूप में मानना। → यह विफल क्यों होता है: गैर-ब्राउज़र क्लाइंट अभी भी सेवा को सीधे कॉल कर सकते हैं। → समाधान: सर्वर पहचान, टेनेंट और संसाधन जांच बनाए रखें।
- गलती: नियंत्रक का परीक्षण किए बिना v1.5 फ़ील्ड शिप करना। → यह विफल क्यों होता है: कार्यान्वयन उन्हें अनदेखा कर सकते हैं, अस्वीकार कर सकते हैं, या अलग तरह से व्याख्या कर सकते हैं। → समाधान: समर्थन मैट्रिक्स, स्थिति स्थितियां और वास्तविक ट्रैफ़िक रीप्ले की जांच करें।
फॉलो-अप और उत्तर
फॉलो-अप 1: CORS को केवल एप्लिकेशन में ही क्यों न सेट करें?
एप्लिकेशन संसाधन-विशिष्ट नीति का स्वामित्व ले सकता है, जबकि Gateway रूट-स्तरीय प्रीफ़्लाइट और क्रॉस-सर्विस सीमा को संभाल सकता है। जब दोनों परतें हेडर सेट करती हैं, तो डुप्लिकेट या विरोध से बचने के लिए प्राथमिकता को परिभाषित करें।
फॉलो-अप 2: क्या maxAge हमेशा यथासंभव लंबा होना चाहिए?
नहीं। एक लंबा प्रीफ़्लाइट कैश OPTIONS ट्रैफ़िक को कम करता है लेकिन निरसन में देरी करता है। परिवर्तन आवृत्ति, जोखिम और ब्राउज़र व्यवहार के आधार पर इसे चुनें, और तत्काल वापसी के लिए एक संस्करणित-ऑरिजिन (versioned-origin) या लघु-TTL पथ रखें।
फॉलो-अप 3: वाइल्डकार्ड ऑरिजिन कब स्वीकार्य है?
केवल बिना किसी क्रेडेंशियल और स्वीकृत जोखिम मूल्यांकन वाले वास्तविक सार्वजनिक संसाधनों के लिए। खाता, प्रशासन और टेनेंट डेटा को स्पष्ट ऑरिजिन और परीक्षण किए गए वाइल्डकार्ड व्यवहार का उपयोग करना चाहिए।
फॉलो-अप 4: आप गलती से अनुमत ऑरिजिन का पता कैसे लगाएंगे?
Origin, रूट, प्रीफ़्लाइट परिणाम और नीति संस्करण को लॉग करें; ऑरिजिन परिवर्तनों का ऑडिट करें। अनुमत, अस्वीकृत और समाप्त हो चुके ऑरिजिन से एक स्वचालित मैट्रिक्स चलाएं, जब रिस्पॉन्स हेडर नीति से भिन्न हों तो रिलीज़ को ब्लॉक करें।