डेवलपर्स CORS को नहीं समझते (2019)
कई वेब डेवलपर्स Cross-Origin Resource Sharing (CORS) को लेकर अब भी भ्रमित हैं, जो एक browser mechanism है जो Same Origin Policy को ढीला करके sites को अन्य origins के साथ data साझा करने के लिए opt in करने देता है, जबकि cross-site attacks से users की रक्षा करने की कोशिश करता है। टिप्पणीकार बताते हैं कि CORS केवल compliant browsers में लागू होता है, अक्सर उल्टा-सा लगता है क्योंकि यह server की बजाय user की रक्षा करता है, और इसे गलत तरीके से configure करना आसान है—जिससे insecure “allow *” setups या brittle workarounds बन जाते हैं। कई लोग तर्क देते हैं कि वास्तविक security boundary Same Origin Policy और CSRF protections हैं, जबकि CORS एक सूक्ष्म, खराब तरीके से समझाया गया exception layer है जिसकी complexity कमजोर tooling और कम उपयोग के कारण और बढ़ जाती है।
समग्र भावना
- कई प्रतिभागी मानते हैं कि वे CORS को वास्तव में नहीं समझते, यहाँ तक कि अनुभवी वेब डेवलपर्स भी।
- कमेंट थ्रेड को ही इस बात के प्रमाण के रूप में उद्धृत किया गया है कि इकोसिस्टम CORS और उसके threat model को लेकर बहुत भ्रमित है।
Same-Origin Policy बनाम CORS
- कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि मूल सुरक्षा तंत्र Same-Origin Policy (SOP) है; CORS इसे चुनिंदा रूप से ढीला करने का एक तरीका है।
- मुख्य स्पष्टता: ब्राउज़र सामान्यतः cross-origin responses को पढ़ने से रोकता है, requests भेजने से नहीं; CORS तब कुछ cross-origin reads की अनुमति देता है जब server इसके लिए opt in करे।
Threat model और CORS वास्तव में क्या सुरक्षा देता है
- CORS को उस browser में मौजूद user की सुरक्षा के रूप में बताया गया है, malicious third-party sites से, न कि backend को generic HTTP clients से बचाने के लिए।
- सामान्य परिदृश्य: user site A में logged in है (cookies set हैं), फिर वह malicious site B पर जाता है जो A के खिलाफ private data पढ़ने या उसकी ओर से action करने की कोशिश करती है।
- कई टिप्पणियाँ CSRF protections के साथ overlap और भ्रम की ओर इशारा करती हैं; कुछ दोनों को गड्डमड्ड कर देते हैं, जबकि अन्य insist करते हैं कि CSRF को अलग से संभालना ही होगा।
Preflight, “simple” requests, और edge cases
- CORS की कई समस्याएँ इन अंतर से उत्पन्न होती हैं:
- “Simple” requests (GET, कुछ POSTs जिनमें विशिष्ट content types हों) जो preflight से बचते हैं।
- “Non-simple” requests (जैसे JSON POST, custom headers) जिन्हें OPTIONS preflight और स्पष्ट CORS approval चाहिए।
- उदाहरण दिखाते हैं कि ढीली Content-Type checking (जैसे
text/plainया form encodings में JSON स्वीकार करना) preflight-आधारित धारणाओं को कैसे bypass कर सकती है। - टिप्पणीकार ज़ोर देते हैं कि संभावित रूप से destructive behavior को “safe” या simple methods जैसे GET के माध्यम से expose नहीं करना चाहिए।
गलत उपयोग और गलत धारणाएँ
- आम पैटर्न: डेवलपर्स “बस
Access-Control-Allow-Origin: *सेट कर देते हैं” ताकि चीज़ें काम करें, और security implications की अनदेखी कर देते हैं। - कुछ लोग गलती से मानते हैं कि CORS अन्य sites या scrapers को किसी API को call करने से पूरी तरह रोक सकता है; अन्य लोग स्पष्ट करते हैं कि non-browser या CORS-disabled clients इससे प्रभावित नहीं होते।
- Zoom localhost वाला उदाहरण भ्रामक बताया गया है: CORS headers ने, जैसा कि implied था, access को पूरी तरह “restricted” नहीं किया होता।
Developer experience और learning
- Debugging को दर्दनाक बताया गया है: browser error messages अस्पष्ट हैं, devtools views भ्रमित करने वाली हैं, और असली कारण (server headers) छिपा रहता है।
- कई लोग CORS को “set-and-forget” मानते हैं; वे हर बार इसे फिर से सीखते हैं, फिर भूल जाते हैं।
- कुछ लोग MDN के CORS docs और पहले SOP को समझने की सलाह देते हैं; अन्य का कहना है कि spec और docs बहुत जटिल हैं और इसलिए protocol प्रभावी रूप से “bad” है।
Architecture और alternatives
- एक दृष्टिकोण: सबसे अच्छा है frontend और backend को same origin पर host करना (reverse proxy के माध्यम से) और CORS से पूरी तरह बचना।
- प्रतिवाद: वास्तविक-world architectures में अक्सर अलग origins की आवश्यकता होती है, इसलिए CORS को समझना और configure करना अभी भी आवश्यक रहता है।