डेवलपर्स CORS को नहीं समझते (2019)

मूल लेख ↗ Hacker News चर्चा ↗

समग्र भावना

  • कई प्रतिभागी मानते हैं कि वे 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 करना अभी भी आवश्यक रहता है।