CORS टेस्टर

सर्वर सहायता वेब

जाँचें कि कोई API किसी ख़ास origin, मेथड और हेडर की अनुमति देता है या नहीं। टूल एक सुरक्षित सर्वर-साइड चेकर से OPTIONS और असली रिक्वेस्ट भेजता है और बताता है कि ब्राउज़र उस कॉल को क्यों अनुमति देगा या रोकेगा।

गोपनीयता: जहाँ संभव हो प्रोसेसिंग आपके ब्राउज़र में होती है। नेटवर्क जाँच मुत्क़न बैकएंड के माध्यम से की जाती है और संग्रहीत नहीं की जाती।

CORS क्या है?

CORS (Cross-Origin Resource Sharing) ब्राउज़र की वह व्यवस्था है जो तय करती है कि एक ऑरिजिन का पेज दूसरे ऑरिजिन का रिस्पॉन्स पढ़ सकता है या नहीं। सर्वर Access-Control-Allow-Origin और संबंधित हेडर से अनुमति देता है; कस्टम हेडर या नॉन-सिंपल मेथड वाली रिक्वेस्ट के लिए ब्राउज़र पहले OPTIONS प्रीफ़्लाइट भेजता है। CORS केवल ब्राउज़र में यूज़र की रक्षा करता है — यह सर्वर, curl या मोबाइल ऐप को नहीं रोकता।

CORS को API नहीं, ब्राउज़र लागू करता है: वह OPTIONS preflight भेजता है, रिस्पॉन्स जाँचता है, और उसके बाद ही असली रिक्वेस्ट भेजकर उसे फिर जाँचता है।
  • वेब पेज https://app.example.com
  • ब्राउज़र
  • API api.example.com
  1. 1 वेब पेज से ब्राउज़र तक: credentials के साथ API कॉल करता है Authorization और Content-Type भेजता है POST /v1/orders
  2. 2 ब्राउज़र आंतरिक रूप से: preflight ज़रूरी है? हाँ: Authorization और JSON वाला Content-Type CORS-safelisted सेट से बाहर हैं
  3. 3 ब्राउज़र से API तक: preflight Origin, Access-Control-Request-Method और Access-Control-Request-Headers के साथ OPTIONS /v1/orders
  4. 4 API से ब्राउज़र तक: preflight रिस्पॉन्स जवाब स्टेटस और Access-Control-Allow-* हेडर
  5. 5 ब्राउज़र आंतरिक रूप से: preflight जाँचता है ज़रूरी: 2xx, Allow-Headers में दोनों हेडर, Allow-Credentials: true और Allow-Origin में ठीक वही origin, * नहीं
  6. 6 ब्राउज़र से API तक: असली रिक्वेस्ट सिर्फ़ preflight पास होने पर, Origin और कुकी या Authorization के साथ POST /v1/orders
  7. 7 API से ब्राउज़र तक: रिस्पॉन्स जवाब अपने Access-Control-Allow-* हेडर के साथ
  8. 8 ब्राउज़र आंतरिक रूप से: रिस्पॉन्स जाँचता है ज़रूरी: Allow-Credentials: true और Allow-Origin में ठीक वही origin, * नहीं
  9. 9 ब्राउज़र से वेब पेज तक: रिस्पॉन्स, या एक सामान्य एरर जवाब कोई भी जाँच फेल हो तो रिस्पॉन्स पेज से छिपा रहता है

परिणाम: उदाहरण में API Access-Control-Allow-Origin: * लौटाता है और Allow-Headers में Authorization नहीं रखता, इसलिए फ़ैसला Blocked है। फ़ेल

Fetch Standard के अनुसार। सिर्फ़ CORS-safelisted हेडर वाली GET, HEAD या POST रिक्वेस्ट में क़दम 3 से 5 नहीं होते; Allow-Methods सिर्फ़ दूसरे मेथड के लिए मायने रखता है। टूल का रिले दोनों रिक्वेस्ट भेजता है, और टूल उनके हेडर पर यही जाँचें लागू करता है।

CORS टेस्टर कैसे इस्तेमाल करें

  1. सार्वजनिक API का URL और उस वेब ऐप का origin डालें जो उसे कॉल करेगा।
  2. मेथड चुनें और वे रिक्वेस्ट हेडर सूचीबद्ध करें जो ऐप भेजेगा (Authorization, Content-Type…)।
  3. टेस्ट चलाएँ और फ़ैसला पढ़ें; "Why" सूची ठीक उसी हेडर का नाम बताती है जिसकी वजह से ब्राउज़र रोकेगा।
  4. सर्वर कॉन्फ़िगरेशन ठीक करें और तब तक दोबारा चलाएँ जब तक फ़ैसला Allowed न हो जाए।

CORS टेस्टर की खूबियाँ

  • preflight (OPTIONS) भेजता है जो आपका मेथड और रिक्वेस्ट हेडर घोषित करता है, फिर आपके चुने हुए Origin के साथ असली रिक्वेस्ट
  • फ़ैसला क़दम-दर-क़दम समझाया जाता है: origin का मिलान, credentials, अनुमत मेथड और हेडर, preflight स्टेटस, max-age
  • CORS-safelisted नियमों से पहचानता है कि preflight ज़रूरी है या नहीं
  • preflight और असली रिस्पॉन्स के हेडर की व्याख्या सहित तालिकाएँ
  • credentials के साथ wildcard और Vary: Origin के न होने पर चेतावनी

CORS टेस्टर का उदाहरण

credentials वाली POST रिक्वेस्ट टेस्ट करना (नतीजे का अंश)

इनपुट:

URL: https://api.example.com/v1/orders · Origin: https://app.example.com · Method: POST · Headers: Authorization, Content-Type

आउटपुट:

Result: Blocked
Preflight needed: Yes (OPTIONS) · Preflight status: 204
Access-Control-Allow-Origin is "*" but the request is credentialed; browsers reject the wildcard with credentials.
Access-Control-Allow-Headers does not list: Authorization.

CORS टेस्टर के बारे में अक्सर पूछे जाने वाले सवाल

ब्राउज़र preflight कब भेजता है?

GET, HEAD या POST के अलावा किसी भी मेथड के लिए, और CORS-safelisted सेट से बाहर के रिक्वेस्ट हेडर के लिए। safelisted हेडर ये हैं: Accept, Accept-Language, Content-Language; Content-Type सिर्फ़ application/x-www-form-urlencoded, multipart/form-data या text/plain वैल्यू के साथ; और Range सिर्फ़ एक bytes रेंज के साथ। इसलिए Content-Type: application/json से preflight होता है। टूल बता देता है कि आपके संयोजन से OPTIONS ट्रिगर होगा या नहीं; उसे सिर्फ़ हेडर के नाम मिलते हैं, इसलिए सूची में दिया गया Content-Type या Range non-safelisted वैल्यू वाला माना जाता है। form या text/plain रिक्वेस्ट टेस्ट करनी हो तो उसे सूची से हटा दें।

Access-Control-Allow-Origin * होने पर भी मेरी रिक्वेस्ट क्यों रुक रही है?

जब रिक्वेस्ट credentials इस्तेमाल करती है (कुकी या credentials: "include" के साथ Authorization), तब wildcard अस्वीकार कर दिया जाता है। इसके बजाय ठीक वही origin लौटाएँ और Access-Control-Allow-Credentials: true तथा Vary: Origin जोड़ें।

टूल API को मेरे ब्राउज़र के बजाय सर्वर से क्यों कॉल करता है?

ब्राउज़र रुकी हुई रिक्वेस्ट का रिस्पॉन्स छिपा देता है, इसलिए आपको सिर्फ़ एक सामान्य एरर दिखता। रिले आपके चुने हुए Origin हेडर के साथ OPTIONS और असली रिक्वेस्ट भेजता है तथा कच्चे Access-Control-* हेडर लौटाता है, ताकि फ़ैसले की हर वजह समझाई जा सके।

क्या मैं localhost या कोई आंतरिक API टेस्ट कर सकता हूँ?

नहीं। सुरक्षा के लिए रिले निजी, loopback और link-local पतों को मना कर देता है। टेस्ट करने के लिए API को किसी tunnel या सार्वजनिक staging होस्ट के ज़रिए उपलब्ध कराएँ।

तकनीकी नोट्स

रिले Fetch Standard के ब्राउज़र एल्गोरिद्म की नक़ल करता है: preflight Access-Control-Request-Method और Access-Control-Request-Headers के साथ भेजा जाता है तथा असली रिक्वेस्ट Origin हेडर के साथ। सर्वर-साइड फ़ैसले को लोकल पुनर्मूल्यांकन के साथ मिलाया जाता है, ताकि हर वजह साफ़-साफ़ लिखी जा सके — उन मामलों सहित जिन्हें रिले अनुमत मानता है पर जो credentials वाली रिक्वेस्ट में फेल हो जाते हैं।

संदर्भ

  • Fetch StandardWHATWGCORS को परिभाषित करता है: प्रीफ़्लाइट रिक्वेस्ट, Access-Control-* हेडर और कौन-से रिस्पॉन्स ब्राउज़र पेज को दिखा सकता है।
  • Cross-Origin Resource Sharing (CORS) — MDNMDN Web Docs (Mozilla)CORS व्यवहार में कैसे काम करता है: सिंपल बनाम प्रीफ़्लाइटेड रिक्वेस्ट, क्रेडेंशियल और ब्राउज़र की रिपोर्ट की गई त्रुटियाँ।