VPN CORS को निष्क्रिय नहीं कर सकता, वह प्रतिक्रिया बदलता है
नया एग्ज़िट पता दो ओरिजिन को एक जैसा नहीं बनाता। दोनों रास्तों पर प्रतिक्रिया हेडर कैप्चर करें और CORS के प्रवर्तन को दोष देने से पहले उनकी तुलना करें।
एक साथ बदली दो चीज़ों को अलग करके शुरू करें: नेटवर्क पथ और ब्राउज़र का प्रवर्तन। VPN एग्ज़िट पता बदलता है; वह पेज का ओरिजिन नहीं बदलता, जो स्कीम, होस्ट और पोर्ट से बनता है। अगर अनुरोध अब सफल होता है, तो प्रतिक्रिया में कुछ बदला है, या अनुरोध ही बदला है। यह पता लगाना कि कौन-सा, पूरी जाँच है।
CORS हेडर प्रोटोकॉल है जिसे ब्राउज़र लागू करता है, इसलिए नेटवर्क पथ पर कुछ भी इसे बंद नहीं कर सकता।
ओरिजिन कोई IP पता नहीं है
ओरिजिन एक स्कीम, एक होस्ट और एक पोर्ट है। यह वह पता नहीं है जहाँ से पैकेट निकलते हैं, और यह वह IP भी नहीं है जो सर्वर देखता है। इसीलिए VPN हर देखने योग्य पता बदल सकता है और ओरिजिन एक जैसा छोड़ सकता है। ब्राउज़र प्रतिक्रिया के Access-Control-Allow-Origin की तुलना पेज के ओरिजिन से करता है, और एग्ज़िट पता उस तुलना में कभी नहीं आता।
इसलिए CORS त्रुटि ठीक करता दिखने वाला एक्सटेंशन या प्रॉक्सी कुछ और करता है: हेडर फिर से लिखता है, या अनुरोध को ऐसे रूट करता है कि वह अब क्रॉस-ओरिजिन न रहे। दोनों में से कोई VPN का गुण नहीं है।
ब्राउज़र वास्तव में क्या भेजता है
जो क्रॉस-ओरिजिन अनुरोध सरल नहीं है, उसके लिए ब्राउज़र पहले एक प्रीफ़्लाइट OPTIONS भेजता है, जो इच्छित मेथड और हेडर ले जाता है। सर्वर को अपने अनुमत अनुमतियों के साथ उत्तर देना होता है, और असली अनुरोध तभी आगे बढ़ता है जब वह उत्तर नियमों को पूरा करे। VPN दोनों आदान-प्रदान ले जाने वाला पथ बदलता है और बीच की सेवाएँ क्या उत्तर देती हैं, यह बदल सकता है। वह ओरिजिन स्ट्रिंग या प्रीफ़्लाइट की शर्त नहीं बदलता।
कमांड-लाइन क्लाइंट आमतौर पर इसमें से कुछ नहीं दिखाता। वह Origin हेडर न भी भेजे, अक्सर प्रीफ़्लाइट छोड़ देता है, और अलग क्रेडेंशियल ले जा सकता है। curl को लौटाया गया बॉडी साबित करता है कि सर्वर ने curl को उत्तर दिया।
जो प्रतिक्रिया बदली उसे खोजें
सिर्फ़ स्थिति कोड नहीं, हर रास्ते की असली प्रतिक्रिया की तुलना करें। CORS अनुमतियाँ ले जाने वाले हेडर, सामग्री का प्रकार, कोई भी रीडायरेक्ट, और यह कि WAF या CDN वैरिएंट ने अलग पेज बनाया या नहीं—ये देखें। क्षेत्रीय अस्वीकृति, प्रमाणीकरण रीडायरेक्ट या अनुमति-हेडर रहित त्रुटि पेज—सब ब्राउज़र में विफल होते हैं जबकि CORS बग जैसे दिखते हैं। ये डिलीवरी-पथ के अंतर हैं, और इन्हीं को दस्तावेज़ करना है।
दोनों रास्तों के प्रतिक्रिया हेडर कैप्चर करें और पंक्ति दर पंक्ति तुलना करें। अगर एकमात्र अंतर एक त्रुटि पेज पर Access-Control-Allow-Origin का न होना है, तो आपने कारण खोज लिया।
प्रवर्तन नहीं, सेवा ठीक करें
जब सेवा आपकी हो, तो अनुमत ओरिजिन और अनुरोध की सुविधाएँ स्पष्ट रूप से बताएँ, फिर उसके फ्रंटएंड और मध्यस्थ जो त्रुटियाँ पैदा करते हैं, उन्हें पढ़ें। अगर न करें, तो सेवा के मालिक को साफ़ की गई तुलना भेजें। उस रिपोर्ट में कभी कुकीज़, प्राधिकरण हेडर या सत्र निर्यात शामिल न करें, क्योंकि नीति उन्हीं क्रेडेंशियल की रक्षा के लिए है।
CORS निष्क्रिय करने वाले ब्राउज़र एक्सटेंशन से बचें। वे सुरक्षा सीमा बदलते हैं और साथ ही वह प्रतिक्रिया-अंतर छिपाते हैं जिसे समझाना ज़रूरी था, और हर दूसरे उपयोगकर्ता के लिए वही विफलता बनी रहती है।
दोनों प्रतिक्रियाएँ, इस्तेमाल किया गया ओरिजिन और लिया गया पथ दर्ज करें। वह रिकॉर्ड VPN की अफ़वाह को सेवा के बग में बदल देता है।