CORS चेकर

किसी भी URL के लिए क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) कॉन्फ़िगरेशन की जाँच करें। Access-Control-* प्रतिक्रिया हेडर का निरीक्षण करें, एक कस्टम ओरिजिन/विधि/हेडर के साथ वैकल्पिक प्रीफ़्लाइट (OPTIONS) अनुरोध चलाएँ, और सामान्य गलत कॉन्फ़िगरेशन जैसे वाइल्डकार्ड + क्रेडेंशियल्स, लापता Vary: Origin, या अत्यधिक व्यापक allow-headers का पता लगाएँ।

Loading…

के बारे में CORS चेकर

किसी API या पेज URL को पेस्ट करें और सत्यापित करें कि क्या ब्राउज़र क्रॉस-ओरिजिन अनुरोधों की अनुमति देंगे। यह उपकरण CORS प्रतिक्रिया हेडर का विश्लेषण करता है, एक यथार्थवादी प्रीफ़्लाइट (OPTIONS) जाँच चला सकता है, और जोखिम भरी या टूटी कॉन्फ़िगरेशन (जैसे क्रेडेंशियल्स के साथ "*", लापता Vary: Origin, या कमज़ोर allow-methods/allow-headers) को उजागर करता है।

विशेषताएँ

किसी भी सार्वजनिक URL के लिए CORS हेडर निरीक्षण (Access-Control-* और संबंधित हेडर)।
कस्टम ओरिजिन, अनुरोध विधि और अनुरोध हेडर के साथ वैकल्पिक प्रीफ़्लाइट सिमुलेशन (OPTIONS)।
रीडायरेक्ट का पालन करें (10 तक) ताकि आप उस अंतिम एंडपॉइंट को सत्यापित कर सकें जिसे ब्राउज़र वास्तव में हिट करते हैं।
पूर्ण पारदर्शिता और डिबगिंग के लिए कच्चे हेडर दृश्य।
निष्कर्ष + स्कोर कार्ड जिसमें त्वरित ट्रायेज के लिए "केवल समस्याएँ" फ़िल्टरिंग शामिल है।
Vary विश्लेषण जो लापता Vary: Origin और अन्य कैश-संबंधित CORS खतरों का पता लगाता है।
ऑडिट, टिकट और प्रलेखन के लिए परिणामों को JSON और PDF रिपोर्ट के रूप में निर्यात करें।
सामान्य समस्याओं के लिए अंतर्निहित सिफारिशें: वाइल्डकार्ड+क्रेडेंशियल्स, ओरिजिन को प्रतिबिंबित करना, null ओरिजिन, लापता allow-methods/allow-headers, लापता max-age, और अत्यधिक व्यापक allow-headers।

🧭 उपयोग कैसे करें for cors-checker

लक्ष्य URL दर्ज करें

वह एंडपॉइंट पेस्ट करें जिसका आप परीक्षण करना चाहते हैं (उदाहरण के लिए, https://api.example.com/resource)।

वह ओरिजिन सेट करें जिससे आप परीक्षण कर रहे हैं

अपने फ्रंटएंड ऐप का ओरिजिन (स्कीम + होस्ट) दर्ज करें, उदाहरण के लिए, https://app.example.com। यह वह मान है जो ब्राउज़र ओरिजिन हेडर में भेजते हैं।

एक जाँच मोड चुनें

प्रतिक्रिया हेडर और प्रीफ़्लाइट व्यवहार दोनों का विश्लेषण करने के लिए ऑटो (अनुशंसित) का उपयोग करें। यदि आप विशेष रूप से एक गैर-प्रीफ़्लाइट परिदृश्य चाहते हैं, तो सरल अनुरोध का उपयोग करें, या केवल OPTIONS जाँच चलाने के लिए केवल प्रीफ़्लाइट का उपयोग करें।

प्रीफ़्लाइट विवरण कॉन्फ़िगर करें (यदि लागू हो)

"प्रीफ़्लाइट चलाएँ (OPTIONS)" सक्षम करें और वास्तविक ब्राउज़र प्रीफ़्लाइट व्यवहार (उदाहरण के लिए, प्राधिकरण, सामग्री-प्रकार) का अनुकरण करने के लिए अनुरोध विधि और अनुरोध हेडर (अल्पविराम से अलग) सेट करें। यदि आपके उपयोग के मामले में कुकीज़ या प्रमाणीकरण हेडर शामिल हैं, तो "क्रेडेंशियल्स पर विचार करें" टॉगल करें।

निष्कर्षों की समीक्षा करें और निर्यात करें

निष्कर्षों/स्कोर कार्ड और CORS विश्लेषण विवरण की जाँच करें। डिबगिंग करते समय "कच्चे हेडर दिखाएँ" चालू करें। ऑडिट, टिकट और प्रलेखन के लिए JSON/PDF निर्यात करें।

तकनीकी विशिष्टताएँ

अनुरोध मॉडल

यह उपकरण किसी लक्ष्य URL के लिए CORS हेडर का निरीक्षण करता है और वैकल्पिक रूप से प्रदान किए गए ओरिजिन, विधि और अनुरोधित हेडर का उपयोग करके एक प्रीफ़्लाइट (OPTIONS) अनुरोध कर सकता है। रीडायरेक्ट का पालन समर्थित है।

सेटिंग	व्यवहार	डिफ़ॉल्ट
जाँच मोड	स्वचालित, सरल अनुरोध, या केवल प्रीफ़्लाइट	स्वचालित
प्रीफ़्लाइट चलाएँ (OPTIONS)	यदि सक्षम है, तो एक OPTIONS प्रीफ़्लाइट सिमुलेशन करता है	सक्षम
मूल	विश्लेषण/प्रीफ़्लाइट के लिए उपयोग किया गया मूल हेडर मान	https://example.com
अनुरोध विधि	प्रीफ़्लाइट के लिए Access-Control-Request-Method मान	GET
अनुरोध हेडर	प्रीफ़्लाइट के लिए Access-Control-Request-Headers (अल्पविराम से अलग किए गए)	खाली
रीडायरेक्ट का पालन करें	अंतिम URL तक रीडायरेक्ट श्रृंखला का पालन करता है	सक्षम
अधिकतम रीडायरेक्ट	लूप को रोकने के लिए रीडायरेक्ट सीमा	10 (सीमा 0–20)
समय सीमा	अनुरोध समय सीमा सीमा	15000 ms
यूज़र-एजेंट	अनुरोध यूज़र एजेंट की पहचान करता है	Encode64Bot/1.0 (+https://encode64.com)
निजी नेटवर्क	सुरक्षा के लिए निजी नेटवर्क रेंज तक पहुँच को अवरुद्ध करता है	अक्षम (निजी नेटवर्क की अनुमति नहीं)

विश्लेषित हेडर (मुख्य CORS सेट)

विश्लेषक ब्राउज़र और प्रीफ़्लाइट जाँचों द्वारा उपयोग किए जाने वाले मानक CORS प्रतिक्रिया और अनुरोध हेडर पर केंद्रित है।

हेडर	उद्देश्य
Access-Control-Allow-Origin	कौन सा मूल (मूलों) की अनुमति है
Access-Control-Allow-Credentials	क्या कुकीज़/क्रेडेंशियल्स की अनुमति है (गैर-वाइल्डकार्ड मूल की आवश्यकता है)
Access-Control-Allow-Methods	क्रॉस-ओरिजिन अनुरोधों के लिए अनुमत विधियाँ (प्रीफ्लाइट के लिए महत्वपूर्ण)
Access-Control-Allow-Headers	अनुमत हेडर्स (प्राधिकरण और कस्टम हेडर्स के लिए महत्वपूर्ण)
Access-Control-Expose-Headers	ब्राउज़र JS द्वारा कौन से हेडर्स पठनीय हैं
Access-Control-Max-Age	ब्राउज़र द्वारा प्रीफ्लाइट को कितनी देर तक कैश किया जा सकता है
Vary	कैश कुंजी भिन्नता (जैसे, Vary: Origin) कैश विषाक्तता/मिश्रण को रोकने के लिए
Origin / Access-Control-Request-*	प्रीफ्लाइट व्यवहार का अनुकरण करने के लिए उपयोग किया जाता है

ह्यूरिस्टिक्स (सामान्य CORS समस्याएँ चिह्नित)

टूटी या जोखिम भरी CORS सेटअप का पता लगाने के लिए निष्कर्ष व्यावहारिक और सुरक्षा-केंद्रित जाँचों पर आधारित हैं।

जाँच	यह क्यों महत्वपूर्ण है
वाइल्डकार्ड + क्रेडेंशियल्स	Access-Control-Allow-Origin: * का उपयोग क्रेडेंशियल्स के साथ नहीं किया जा सकता; ब्राउज़र ब्लॉक करेंगे या व्यवहार असुरक्षित है
Vary: Origin का अभाव	यदि प्रतिक्रियाएँ प्रति Origin भिन्न होती हैं लेकिन सही ढंग से कैश नहीं की जातीं, तो साझा कैश साइटों में प्रतिक्रियाएँ मिला सकते हैं
Origin प्रतिबिंबित करना	Origin को बिना सोचे-समझे प्रतिध्वनित करना अनजाने में अविश्वसनीय ओरिजिन की अनुमति दे सकता है
Null Origin चेतावनियाँ	Origin: null सैंडबॉक्स्ड iframes या फ़ाइल संदर्भों में दिखाई दे सकता है; इसे अनुमति देना अक्सर जोखिम भरा होता है
Allow-Methods / Allow-Headers का अभाव	प्रीफ्लाइट विफल हो सकती है यदि सर्वर स्पष्ट रूप से विधि/हेडर्स की अनुमति नहीं देता
अत्यधिक व्यापक Allow-Headers	बहुत अधिक हेडर्स की अनुमति देने से हमले की सतह बढ़ सकती है
Max-Age का अभाव	प्रीफ्लाइट बहुत बार चल सकती है, विलंबता बढ़ा सकती है

CORS एक ब्राउज़र प्रवर्तन तंत्र है। सर्वर अभी भी गैर-ब्राउज़र क्लाइंट के माध्यम से क्रॉस-ओरिजिन पहुँच योग्य हो सकते हैं; CORS को व्यापक सुरक्षा रुख के हिस्से के रूप में मानें, न कि एकमात्र नियंत्रण।

कमांड लाइन

CORS और प्रीफ्लाइट व्यवहार को अपने टर्मिनल से पुनरुत्पादित करने के लिए इन कमांड्स का उपयोग करें। ये डिबगिंग और टूल द्वारा रिपोर्ट किए गए तथ्यों को सत्यापित करने में सहायक हैं।

macOS / Linux

सामान्य अनुरोध के लिए CORS हेडर्स जाँचें (ब्राउज़र Origin का अनुकरण करें)

curl -i -H "Origin: https://example.com" https://api.example.com/resource

Access-Control-Allow-Origin, Access-Control-Allow-Credentials, और Vary देखें।

एक प्रीफ्लाइट OPTIONS अनुरोध चलाएँ (विधि + हेडर्स)

curl -i -X OPTIONS -H "Origin: https://app.example.com" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: authorization, content-type" https://api.example.com/private

ब्राउज़र को आगे बढ़ने के लिए प्रीफ्लाइट को सही Access-Control-Allow-Methods और Access-Control-Allow-Headers वापस करने होंगे।

हेडर जांचते समय रीडायरेक्ट का पालन करें

curl -iL -H "Origin: https://example.com" https://api.example.com

उपयोगी जब एंडपॉइंट्स एक अलग होस्ट पर रीडायरेक्ट करते हैं जिसके अलग CORS नियम हैं।

विंडोज़ (PowerShell)

ओरिजिन हेडर के साथ प्रतिक्रिया हेडर का निरीक्षण करें

$r = Invoke-WebRequest -Uri https://api.example.com/resource -Headers @{ Origin = "https://example.com" }; $r.Headers

Access-Control-* हेडर प्रदर्शित करता है यदि वे मौजूद हैं।

यदि आपका फ्रंटएंड कुकीज़ या प्रमाणीकरण का उपयोग करता है, तो अनुमेय CORS से बचें। विश्वसनीय ओरिजिन की एक स्पष्ट अनुमति सूची को प्राथमिकता दें और Vary: Origin शामिल करें जब प्रतिक्रियाएँ ओरिजिन के अनुसार भिन्न हों।

उपयोग के मामले

फ्रंटएंड "CORS ब्लॉक्ड" ब्राउज़र त्रुटि को डीबग करें

जब fetch/XHR CORS त्रुटि के साथ विफल होता है, तो सत्यापित करें कि सर्वर आपके ओरिजिन और अनुरोध प्रकार के लिए आवश्यक Access-Control-* हेडर लौटाता है या नहीं।

पुष्टि करें कि Access-Control-Allow-Origin आपके ऐप ओरिजिन से मेल खाता है
यदि कुकीज़/प्रमाणीकरण का उपयोग कर रहे हैं, तो जांचें कि Access-Control-Allow-Credentials सही है (और ओरिजिन वाइल्डकार्ड नहीं है)
सुनिश्चित करें कि Vary: Origin मौजूद है जब कई ओरिजिन की अनुमति दी जाती है

प्राधिकरण / कस्टम हेडर के लिए प्रीफ़्लाइट सत्यापित करें

अधिकांश प्रमाणित API कॉल Authorization या गैर-सरल सामग्री प्रकारों के कारण प्रीफ़्लाइट ट्रिगर करते हैं। यह टूल सुनिश्चित करने में मदद करता है कि OPTIONS प्रतिक्रियाएँ आवश्यक विधि और हेडर की अनुमति देती हैं।

सत्यापित करें कि Access-Control-Allow-Methods में आवश्यकतानुसार POST/PUT/PATCH/DELETE शामिल हैं
सत्यापित करें कि Access-Control-Allow-Headers में authorization, content-type, और आवश्यक X-* हेडर शामिल हैं
तैनाती से पहले लापता allow-methods/allow-headers को पकड़ें

CORS नीति की सुरक्षा समीक्षा

CORS गलत कॉन्फ़िगरेशन अनजाने में निजी API को दुर्भावनापूर्ण साइटों के लिए उजागर कर सकते हैं (विशेष रूप से प्रमाण-पत्रों के साथ)। उच्च-जोखिम पैटर्न को पकड़ने के लिए निष्कर्षों का उपयोग करें।

प्रमाण-पत्रों के साथ संयुक्त वाइल्डकार्ड ओरिजिन का पता लगाएं
उन ओरिजिन पैटर्न को प्रतिबिंबित करने का पता लगाएं जो मनमानी साइटों की अनुमति देते हैं
ओरिजिन: null की अनुमति देने पर ध्वजांकित करें जब इरादा न हो

प्रीफ़्लाइट कैशिंग द्वारा प्रदर्शन में सुधार करें

प्रीफ़्लाइट अनुरोध राउंड-ट्रिप और विलंबता जोड़ते हैं। सही Max-Age स्थिर API के लिए दोहराए गए प्रीफ़्लाइट चेक को कम कर सकता है।

सत्यापित करें कि Access-Control-Max-Age उपयुक्त होने पर मौजूद है
लगातार API ट्रैफ़िक के लिए दोहराए गए OPTIONS कॉल कम करें

❓ Frequently Asked Questions

❓सरल शब्दों में CORS क्या है?

CORS (क्रॉस-ओरिजिन रिसोर्स शेयरिंग) एक ब्राउज़र सुरक्षा तंत्र है जो नियंत्रित करता है कि क्या एक ओरिजिन (योजना + होस्ट + पोर्ट) से एक वेबपेज दूसरे ओरिजिन से प्रतिक्रियाएँ पढ़ सकता है। यह विशिष्ट Access-Control-* प्रतिक्रिया हेडर पर निर्भर करता है।

❓ब्राउज़र प्रीफ़्लाइट (OPTIONS) अनुरोध कब भेजता है?

प्रीफ़्लाइट तब भेजा जाता है जब अनुरोध "सरल" नहीं होता है, उदाहरण के लिए जब POST जैसी विधियों का उपयोग कुछ सामग्री प्रकारों के साथ किया जाता है या Authorization या कस्टम X-* हेडर जैसे हेडर भेजे जाते हैं। ब्राउज़र वास्तविक अनुरोध भेजने से पहले OPTIONS के माध्यम से अनुमतियाँ जाँचता है।

❓"Access-Control-Allow-Origin: *" प्रमाण-पत्रों के साथ खतरनाक क्यों है?

ब्राउज़र को प्रमाण-पत्र शामिल होने पर एक स्पष्ट ओरिजिन की आवश्यकता होती है। प्रमाण-पत्रों के साथ वाइल्डकार्ड का उपयोग प्रमाणित अनुरोधों के लिए अमान्य है और एक जोखिम भरी कॉन्फ़िगरेशन को इंगित करता है। विश्वसनीय ओरिजिन की एक स्पष्ट अनुमति सूची को प्राथमिकता दें।

❓मुझे Vary: Origin की आवश्यकता क्यों है?

यदि आपका सर्वर अनुरोध ओरिजिन के आधार पर भिन्न Access-Control-Allow-Origin मान लौटाता है, तो कैश को ओरिजिन के अनुसार भिन्न होना चाहिए ताकि एक साइट के लिए इच्छित प्रतिक्रिया दूसरी को परोसने से बचा जा सके। Vary: Origin कैश मिश्रण और संबंधित सुरक्षा मुद्दों को रोकने में मदद करता है।

❓क्या CORS मेरी API को गैर-ब्राउज़र क्लाइंट्स से बचा सकता है?

नहीं। CORS ब्राउज़र द्वारा लागू किया जाता है। ब्राउज़र के बाहर चलने वाली स्क्रिप्ट्स (सर्वर, कर्ल, मोबाइल ऐप्स) CORS की परवाह किए बिना आपकी API को कॉल कर सकती हैं। वास्तविक एक्सेस नियंत्रण के लिए प्रमाणीकरण, अधिकार प्रबंधन और दर सीमा का उपयोग करें।

❓प्रीफ़्लाइट टेस्टिंग के दौरान "Request Headers" में क्या डालना चाहिए?

वे हेडर्स सूचीबद्ध करें जो आपका फ्रंटएंड भेजेगा, कॉमा से अलग किए गए (जैसे, authorization, content-type, x-request-id)। यह Access-Control-Request-Headers का अनुकरण करता है और जाँचता है कि सर्वर उन्हें अनुमति देता है या नहीं।

❓क्या यहाँ URL पेस्ट करना सुरक्षित है?

यह टूल प्रदान किए गए URL पर सर्वर-साइड अनुरोध करता है और निजी-नेटवर्क लक्ष्यों को ब्लॉक करता है। URL में गुप्त जानकारी (जैसे क्वेरी स्ट्रिंग में टोकन) शामिल करने से बचें और उन सार्वजनिक एंडपॉइंट्स को प्राथमिकता दें जिन पर आप भरोसा करते हैं।