नेटवर्क/HTTP

CORS Checker / Explainer

चरण-दर-चरण समझाएं कि क्या ब्राउज़र क्रॉस-ओरिजिन अनुरोध की अनुमति देगा — simple/preflight वर्गीकरण, प्रतिक्रिया के Access-Control-* हेडर की जांच, सारांश।

Credentials (fetch)

प्रति पंक्ति एक, "नाम" या "नाम: मान" — मान वर्गीकरण को प्रभावित नहीं करता।

DevTools के Network टैब से लें (स्वयं प्रतिक्रिया के हेडर या preflight OPTIONS) या curl -I से।

CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.

How to use it

Common uses

Things to keep in mind

CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.

Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.

इस टूल के बारे में लेख: CORS एरर: ब्राउज़र रिस्पॉन्स को क्यों ब्लॉक करता है

अक्सर पूछे जाने वाले प्रश्न

सर्वर के सफलतापूर्वक जवाब देने के बावजूद रिक्वेस्ट CORS एरर के साथ क्यों फ़ेल होती है?

CORS सर्वर नहीं, ब्राउज़र लागू करता है — यदि रिस्पॉन्स में रिक्वेस्टिंग ओरिजिन से मेल खाता Access-Control-Allow-Origin हेडर नहीं है, तो ब्राउज़र JavaScript को रिस्पॉन्स पढ़ने से रोक देता है, भले ही रिक्वेस्ट खुद पूरी हो गई हो।

सामान्य रिक्वेस्ट और प्रीफ़्लाइट रिक्वेस्ट में क्या अंतर है?

सामान्य रिक्वेस्ट (स्टैंडर्ड हेडर्स के साथ बेसिक GET/POST) सीधे गुज़र जाती हैं, जबकि कस्टम हेडर्स, अन्य मेथड्स, या कुछ कंटेंट टाइप्स वाली रिक्वेस्ट वास्तविक रिक्वेस्ट भेजने से पहले परमिशन चेक करने के लिए पहले एक प्रीफ़्लाइट OPTIONS रिक्वेस्ट ट्रिगर करती हैं।

क्या यहां CORS हेडर्स चेक करना मेरा डेटा किसी सर्वर पर भेजता है?

यह टूल आपके द्वारा दिए गए हेडर्स की जांच करता है या उन्हें सीधे आपके ब्राउज़र से फ़ेच करता है — कोई भी बिचौलिया सर्वर आपके रिक्वेस्ट डेटा को स्टोर नहीं करता।

क्या CORS किसी API को मैलिशियस रिक्वेस्ट से बचाता है?

नहीं। CORS सिर्फ़ यह सीमित करता है कि ब्राउज़र में JavaScript क्या पढ़ सकता है — curl, Postman या बैकएंड स्क्रिप्ट इस्तेमाल करने वाला हमलावर इसे पूरी तरह नज़रअंदाज़ कर देता है, इसलिए असली ऑथेंटिकेशन और ऑथराइज़ेशन सर्वर पर ही लागू करना चाहिए।

Access-Control-Allow-Origin: * credentials: include के साथ क्यों काम नहीं करता?

स्पेसिफ़िकेशन जानबूझकर सुरक्षा कारणों से यह मना करती है: credentials (कुकी, ऑथराइज़ेशन हेडर) को किसी भी origin स्वीकार करने वाले wildcard के साथ इजाज़त देना एक गंभीर सुरक्षा ख़ामी होती, इसलिए credentials इस्तेमाल होने पर सर्वर को एक सटीक origin ही लौटाना होता है।

लेख: नेटवर्क/HTTP

URL पार्सिंग: वेब एड्रेस किन हिस्सों से बनता है

URL के फ़्रैगमेंट हिस्से (# के बाद) को सर्वर कभी नहीं देखता, सिर्फ़ ब्राउज़र प्रोसेस करता है।

क्वेरी स्ट्रिंग बनाम JSON: जटिल डेटा भेजने के लिए कौन बेहतर

क्वेरी स्ट्रिंग में ऐरे भेजने का कोई एक स्टैंडर्ड तरीक़ा क्यों नहीं है।

User-Agent: Chrome के स्ट्रिंग में "Mozilla" और "Safari" क्यों हैं

Chrome का User-Agent ख़ुद को "Mozilla" और "Safari" क्यों बताता है, जबकि वह कोई भी नहीं है।

HTTP Basic Auth: Authorization हेडर कैसे बनता है

Base64 एन्क्रिप्शन नहीं है — Basic Auth का पासवर्ड कुछ ही सेकंड में डिकोड किया जा सकता है।

HTTP हेडर: रिक्वेस्ट और रिस्पॉन्स के साथ क्या मेटाडेटा जाता है

Content-Type हेडर ब्राउज़र को यह कैसे बताता है कि रिस्पॉन्स को HTML, JSON या इमेज की तरह समझना है।

कुकीज़: Secure, HttpOnly और SameSite एट्रिब्यूट क्यों मायने रखते हैं

HttpOnly कुकी XSS अटैक में सेशन कुकी चोरी होने से क्यों बचाती है।

ईमेल हेडर: SPF, DKIM और DMARC असली भेजने वाले को कैसे जाँचते हैं

किसी ईमेल का असली भेजने वाला पता लगाने के लिए Received हेडर नीचे से ऊपर क्यों पढ़े जाते हैं।