CORS चेकर

वेब ब्राउज़र सुरक्षा के अंतर्गत Cross-Origin Resource Sharing (CORS) एक अत्यंत महत्वपूर्ण नीति है। जब कोई वेब एप्लिकेशन अपने स्वयं के डोमेन (Origin) से बाहर किसी अन्य सर्वर से संसाधनों का अनुरोध करता है, तो ब्राउज़र सुरक्षा कारणों से इस अनुरोध को नियंत्रित करता है। CORS चेकर टूल आपको यह समझने में मदद करता है कि क्या कोई वेब ब्राउज़र आपके द्वारा प्रदान किए गए HTTP रिस्पॉन्स हेडर और अनुरोध के विवरण के आधार पर किसी विशिष्ट क्रॉस-ओरिजिन अनुरोध की अनुमति देगा या नहीं।

यह टूल फ्रंट-एंड डेवलपर्स, बैक-एंड डेवलपर्स, API प्लेटफॉर्म डेवलपर्स, ऑपरेशंस डेवलपर्स और उन सभी लोगों के लिए उपयोगी है जो यह जांचना चाहते हैं कि क्या ब्राउज़र कोड किसी विशिष्ट प्रतिक्रिया को पढ़ सकता है। इसके अतिरिक्त, यह यह भी जांचने में मदद करता है कि क्या कोई OPTIONS उत्तर बाद की विधि (Method) और उसके अनुरोधित हेडर नामों को मंजूरी देता है।

CORS नीति और रिस्पॉन्स हेडर का विश्लेषण

CORS नीति का मुख्य उद्देश्य ब्राउज़र में चलने वाली स्क्रिप्ट को अनधिकृत रूप से दूसरे डोमेन का डेटा पढ़ने से रोकना है। जब कोई ब्राउज़र क्रॉस-ओरिजिन अनुरोध भेजता है, तो वह सर्वर से मिलने वाले रिस्पॉन्स हेडर की जांच करता है।

इस प्रक्रिया में Access-Control-Allow-Origin हेडर की भूमिका सबसे महत्वपूर्ण होती है। यह हेडर सर्वर को यह घोषित करने की अनुमति देता है कि कौन से बाहरी डोमेन उसके संसाधनों तक पहुँच सकते हैं। यदि यह हेडर रिस्पॉन्स में मौजूद नहीं है, तो ब्राउज़र अनुरोध को ब्लॉक कर देता है।

CORS चेकर टूल में इनपुट के रूप में दो मुख्य विकल्प मिलते हैं:

1. वास्तविक प्रतिक्रिया: इसका उपयोग यह जांचने के लिए किया जाता है कि क्या ब्राउज़र कोड किसी प्रतिक्रिया को पढ़ सकता है।
2. उड़ान पूर्व प्रतिक्रिया: इसका उपयोग OPTIONS अनुरोध के उत्तर की जांच करने के लिए किया जाता है।

उपयोगकर्ता को टूल में "HTTP प्रतिक्रिया शीर्षलेख" पेस्ट करने होते हैं। इसकी अधिकतम सीमा 200,000 वर्ण है। यदि इनपुट खाली है, तो त्रुटि संदेश "जाँच करने से पहले HTTP प्रतिक्रिया शीर्षलेख चिपकाएँ।" दिखाई देता है। यदि इनपुट बहुत बड़ा है, तो "यह प्रतिक्रिया असामान्य रूप से बड़ी है. इसे ‹max› वर्णों के अंतर्गत रखें।" संदेश प्रदर्शित होता है। प्रत्येक पंक्ति को वैध होना चाहिए; अन्यथा "लाइन ‹line› मान्य HTTP हेडर या स्टेटस लाइन नहीं है।" या "लाइन ‹line› में एक अमान्य HTTP हेडर नाम है।" जैसी त्रुटियां आ सकती हैं।

अनुरोध विवरण और इनपुट नियम

सटीक मूल्यांकन के लिए, टूल को अनुरोध के विशिष्ट विवरणों की आवश्यकता होती है:

• मूल का अनुरोध करें: यह वह डोमेन है जहां से अनुरोध उत्पन्न हो रहा है। इसमें केवल स्कीम, होस्ट और वैकल्पिक पोर्ट होना चाहिए (जैसे https://app.example.com)। इसमें URL पाथ, क्वेरी या क्रेडेंशियल शामिल नहीं होने चाहिए। गलत प्रारूप होने पर "केवल एक स्कीम, होस्ट और वैकल्पिक पोर्ट, जैसे https://app.example.com के साथ एक मूल दर्ज करें।" त्रुटि दिखाई देती है।
• अनुरोधित विधि: वह HTTP मेथड (जैसे GET, POST, PUT) जिसका उपयोग किया जा रहा है। अमान्य टोकन होने पर "एक वैध HTTP विधि टोकन दर्ज करें।" और ब्राउज़र द्वारा प्रतिबंधित होने पर "ब्राउज़र fetch अनुरोधों में ‹method› विधि की अनुमति नहीं देते हैं।" त्रुटि आती है।
• अनुरोधित शीर्षलेख नाम: Access-Control-Request-Headers से लिए गए हेडर नाम, जिन्हें अल्पविराम या नई लाइनों द्वारा अलग किया जाता है। अमान्य नाम होने पर ""‹header›" एक वैध HTTP अनुरोध हेडर नाम नहीं है।" त्रुटि मिलती है।
• क्रेडेंशियल शामिल करें: एक टॉगल बटन जो यह दर्शाता है कि क्या अनुरोध में कुकीज़ या HTTP प्रमाणीकरण शामिल हैं।

क्रेडेंशियल और वाइल्डकार्ड के विशेष नियम

CORS नीति में क्रेडेंशियल (जैसे कुकीज़ और HTTP ऑथेंटिकेशन) शामिल होने पर नियम अत्यधिक सख्त हो जाते हैं:

1. वाइल्डकार्ड प्रतिबंध: जब क्रेडेंशियल शामिल होते हैं, तो Access-Control-Allow-Origin का मान वाइल्डकार्ड * नहीं हो सकता। इसे अनुरोध करने वाले मूल से बिल्कुल मेल खाना चाहिए।
2. क्रेडेंशियल हेडर की आवश्यकता: क्रेडेंशियल वाले अनुरोधों के लिए Access-Control-Allow-Credentials हेडर का मान बिल्कुल true होना चाहिए। यदि यह मौजूद नहीं है या इसका मान कुछ और है, तो ब्राउज़र अनुरोध को ब्लॉक कर देता है।
3. विधियों और हेडर पर प्रभाव: क्रेडेंशियल शामिल होने पर, अनुमत विधियों और हेडर के लिए उपयोग किए जाने वाले वाइल्डकार्ड अपना वाइल्डकार्ड अर्थ खो देते हैं।
4. एकल मान नियम: यदि Access-Control-Allow-Origin में एकाधिक मान हैं या यह अल्पविराम से अलग किया गया है, तो इसे अमान्य माना जाता है।

यदि क्रेडेंशियल शामिल नहीं हैं, तो Access-Control-Allow-Methods और Access-Control-Allow-Headers के लिए * का उपयोग किया जा सकता है, लेकिन इसमें Authorization हेडर शामिल नहीं है। Authorization हेडर को हमेशा Access-Control-Allow-Headers में स्पष्ट रूप से सूचीबद्ध किया जाना चाहिए; वाइल्डकार्ड * इसे कवर नहीं करता है।

प्रीफ़्लाइट (उड़ान पूर्व) अनुरोधों का महत्व

जटिल अनुरोधों (जैसे गैर-मानक हेडर या विशिष्ट HTTP विधियों वाले अनुरोध) के लिए ब्राउज़र वास्तविक अनुरोध भेजने से पहले एक OPTIONS प्रीफ़्लाइट अनुरोध भेजता है।

• HTTP स्टेटस कोड: प्रीफ़्लाइट प्रतिक्रिया में एक सफल 2xx स्टेटस कोड होना आवश्यक है। यदि प्रीफ़्लाइट प्रतिक्रिया में कोई HTTP स्टेटस लाइन नहीं चिपकाई गई है, तो परिणाम "हेडर पास हो जाते हैं, लेकिन उड़ान पूर्व स्थिति अज्ञात होती है।" (indeterminate) के रूप में प्रदर्शित होता है।
• सफलता और विफलता: यदि स्टेटस कोड सफल है, तो "उड़ान पूर्व स्थिति ‹status› सफल है।" प्रदर्शित होता है। असफल होने पर "उड़ान पूर्व स्थिति ‹status› एक सफल 2xx स्थिति नहीं है।" दिखाई देता है।
• सुरक्षित सूचीबद्ध विधियाँ: कुछ विधियाँ (जैसे GET या POST) CORS-सुरक्षित सूचीबद्ध (safelisted) होती हैं और उन्हें Access-Control-Allow-Methods में प्रदर्शित होने की आवश्यकता नहीं होती है।

ब्राउज़र निर्णय और व्याख्या

सभी इनपुट की जांच करने के बाद, टूल निम्नलिखित निर्णयों में से एक प्रदर्शित करता है:

• चिपकाए गए CORS प्रतिक्रिया द्वारा अनुमति दी गई। (Allowed)
• चिपकाए गए CORS प्रतिक्रिया द्वारा अवरोधित किया गया। (Blocked)
• हेडर पास हो जाते हैं, लेकिन उड़ान पूर्व स्थिति अज्ञात होती है। (Indeterminate)

इसके साथ ही, टूल निर्णय के पीछे के कारणों को स्पष्ट रूप से सूचीबद्ध करता है, जैसे:

• "Access-Control-Allow-Origin बिल्कुल ‹origin› से मेल खाता है।"
• "Access-Control-Allow-Origin इस अनुरोध के लिए किसी भी मूल की अनुमति देता है।"
• "Access-Control-Allow-Origin गायब है।"
• "क्रेडेंशियल शामिल होने पर Access-Control-Allow-Origin * नहीं हो सकता।"
• "Access-Control-Allow-Origin ‹actual› है, ‹expected› नहीं।"
• "Access-Control-Allow-Origin का एक अमान्य मान है: ‹value›।"
• "Access-Control-Allow-Credentials बिल्कुल सत्य है।"
• "एक क्रेडेंशियल अनुरोध के लिए Access-Control-Allow-Credentials की आवश्यकता है: सत्य।"
• "क्रेडेंशियल शामिल नहीं हैं, इसलिए Access-Control-Allow-Credentials इस निर्णय को प्रभावित नहीं करता है।"

गोपनीयता और प्रसंस्करण की सीमाएं

यह टूल पूरी तरह से क्लाइंट-साइड पर काम करता है। आपके द्वारा दर्ज किए गए हेडर और अनुरोध के विवरण केवल आपके ब्राउज़र में ही संसाधित होते हैं। BroBroGo पर कोई भी डेटा अपलोड या सहेजने की प्रक्रिया नहीं की जाती है।

यह ध्यान रखना महत्वपूर्ण है कि यह टूल केवल आपके द्वारा प्रदान किए गए प्रतिक्रिया हेडर और अनुरोध विवरणों की जांच करता है। यह किसी बाहरी सर्वर से संपर्क नहीं करता, URL को रीड नहीं करता, कुकीज़ सेट नहीं करता, DNS/TLS की जांच नहीं करता और न ही सर्वर कॉन्फ़िगरेशन में कोई बदलाव करता है। एक सफल परिणाम केवल चिपकाई गई प्रतिक्रिया और दर्ज किए गए विवरणों पर लागू होता है; यह वास्तविक समय के रीडायरेक्ट, कैश्ड प्रतिक्रियाओं, बदलते सर्वर नियमों, ब्राउज़र एक्सटेंशन या प्रीफ़्लाइट के बाद मिलने वाली वास्तविक प्रतिक्रिया को ध्यान में नहीं रखता है।

सामान्य प्रश्न (FAQ)

क्या मुझे वास्तविक प्रतिक्रिया या उड़ान पूर्व प्रतिक्रिया पेस्ट करनी चाहिए?
यह जांचने के लिए वास्तविक प्रतिक्रिया का उपयोग करें कि ब्राउज़र कोड एक प्रतिक्रिया पढ़ सकता है या नहीं। OPTIONS उत्तर के लिए प्रीफ़्लाइट प्रतिक्रिया का उपयोग करें जो बाद की विधि और उसके अनुरोधित हेडर नामों को मंजूरी देता है।

वाइल्डकार्ड क्रेडेंशियल्स के साथ विफल क्यों हो सकता है?
जब कुकीज़ या HTTP प्रमाणीकरण शामिल किया जाता है, तो अनुमत मूल को अनुरोध करने वाले मूल से बिल्कुल मेल खाना चाहिए। अनुमत विधियों और हेडर के लिए वाइल्डकार्ड भी अपना वाइल्डकार्ड अर्थ खो देते हैं।

क्या उत्तीर्ण परिणाम साबित करता है कि लाइव अनुरोध काम करेगा?
नहीं, इस परिणाम में केवल चिपकाई गई प्रतिक्रिया और यहां दर्ज किए गए अनुरोध विवरण शामिल हैं। रीडायरेक्ट, कैश्ड प्रतिक्रियाएं, बदलते सर्वर नियम, ब्राउज़र एक्सटेंशन और प्रीफ़्लाइट के बाद वास्तविक प्रतिक्रिया अभी भी परिणाम बदल सकती है।

क्या Authorization हेडर को वाइल्डकार्ड (*) के साथ अनुमति दी जा सकती है?
नहीं, Authorization हेडर को Access-Control-Allow-Headers में स्पष्ट रूप से सूचीबद्ध किया जाना चाहिए। Access-Control-Allow-Headers: * इसे कवर नहीं करता है।