CORS तपासक

Cross-Origin Resource Sharing (CORS) धोरण समजून घेणे

Cross-Origin Resource Sharing (CORS) हे एक सुरक्षा वैशिष्ट्य आहे जे वेब ब्राउझरद्वारे लागू केले जाते. हे धोरण ठरवते की एका ओरिजिनवर (मूळ) चालणारा वेब अनुप्रयोग दुसऱ्या ओरिजिनवरील संसाधनांशी संवाद साधू शकतो की नाही. जेव्हा एखादा ब्राउझर क्रॉस-ओरिजिन विनंती पाठवतो, तेव्हा तो सर्व्हरकडून येणाऱ्या HTTP प्रतिसाद शीर्षलेखांची (response headers) तपासणी करतो. जर सर्व्हरने योग्य CORS शीर्षलेख पाठवले नाहीत, तर ब्राउझर सुरक्षा कारणास्तव ती विनंती किंवा प्रतिसाद अवरोधित करतो.

CORS चे नियम समजून घेणे आणि त्यांची अंमलबजावणी करणे फ्रंट-एंड डेव्हलपर्स, बॅक-एंड डेव्हलपर्स, API प्लॅटफॉर्म डेव्हलपर्स आणि ऑपरेशन्स डेव्हलपर्ससाठी अत्यंत आवश्यक आहे. ब्राउझरमधील कोड विशिष्ट प्रतिसाद वाचू शकतो की नाही हे तपासण्यासाठी किंवा एखादे OPTIONS प्रत्युत्तर नंतरच्या पद्धतीला आणि विनंती केलेल्या शीर्षलेखांना अनुमती देते की नाही हे तपासण्यासाठी CORS नियमांचे अचूक विश्लेषण करावे लागते.

CORS तपासणीसाठी इनपुट आणि मर्यादा

CORS तपासक साधनामध्ये अचूक विश्लेषणासाठी खालील इनपुट तपशील प्रविष्ट करावे लागतात:

• तपासण्यासाठी: वापरकर्त्याला "वास्तविक प्रतिसाद" किंवा "प्रीफ्लाइट प्रतिसाद" यापैकी एक पर्याय निवडावा लागतो.
• HTTP प्रतिसाद शीर्षलेख: यामध्ये HTTP प्रतिसाद शीर्षलेख पेस्ट करावे लागतात. प्रीफ्लाइट प्रतिसाद तपासताना स्थिती ओळ (status line) पेस्ट करणे आवश्यक आहे. या इनपुटची कमाल मर्यादा 200,000 वर्ण आहे.
• विनंती मूळ: यामध्ये केवळ योजना (scheme), होस्ट (host) आणि पर्यायी पोर्ट (optional port) समाविष्ट असलेले मूळ प्रविष्ट करावे. उदाहरणार्थ: https://app.example.com. यामध्ये URL पाथ, क्वेरी किंवा क्रेडेन्शियल्स समाविष्ट नसावेत.
• विनंती केलेली पद्धत: विनंतीसाठी वापरली जाणारी HTTP पद्धत (उदा. GET, POST) येथे प्रविष्ट करावी लागते.
• विनंती केलेली शीर्षलेख नावे: Access-Control-Request-Headers मधील शीर्षलेख नावे स्वल्पविराम किंवा ओळींनी विभक्त करून प्रविष्ट करावीत. उदाहरणार्थ: Content-Type, Authorization.
• क्रेडेन्शियल समाविष्ट करा: विनंतीमध्ये कुकीज किंवा HTTP प्रमाणीकरण समाविष्ट आहे की नाही हे दर्शवण्यासाठी हा टॉगल चालू किंवा बंद करावा लागतो.

इनपुट प्रविष्ट करताना खालील त्रुटी संदेश दिसू शकतात:

• शीर्षलेख रिकामे असल्यास: "तपासण्यापूर्वी HTTP प्रतिसाद शीर्षलेख पेस्ट करा."
• इनपुट मर्यादा ओलांडल्यास: "हा प्रतिसाद असामान्यपणे मोठा आहे. ते ‹max› वर्णांखाली ठेवा."
• अवैध ओळ असल्यास: "लाइन ‹line› एक वैध HTTP शीर्षलेख किंवा स्थिती रेखा नाही."
• अवैध शीर्षलेख नाव असल्यास: "लाइन ‹line› मध्ये अवैध HTTP हेडर नाव आहे."
• अवैध मूळ असल्यास: "केवळ योजना, होस्ट आणि पर्यायी पोर्टसह मूळ प्रविष्ट करा, जसे की https://app.example.com."
• अवैध पद्धत असल्यास: "वैध HTTP पद्धत टोकन प्रविष्ट करा."
• प्रतिबंधित पद्धत असल्यास: "ब्राउझर fetch विनंत्यांमध्ये ‹method› पद्धतीला अनुमती देत ​​नाहीत."
• अवैध विनंती शीर्षलेख असल्यास: "“‹header›” हे वैध HTTP विनंती शीर्षलेख नाव नाही."
• सामान्य इनपुट त्रुटी असल्यास: "हायलाइट केलेल्या इनपुटचे निराकरण करा आणि पुन्हा प्रयत्न करा."

Access-Control-Allow-Origin ची भूमिका आणि नियम

CORS धोरणामध्ये Access-Control-Allow-Origin हे सर्वात महत्त्वाचे शीर्षलेख आहे. हे ठरवते की कोणत्या मूळ (origin) वेबसाइटला सर्व्हरवरील संसाधन वाचण्याची परवानगी आहे.

या शीर्षलेखाचे मूल्य तपासताना खालील नियम लागू होतात:

1. तंतोतंत जुळणी: जर हे शीर्षलेख विनंती केलेल्या मूळशी तंतोतंत जुळले, तर ब्राउझर निर्णयामध्ये "Access-Control-Allow-Origin ‹origin› बरोबर जुळते." असे दर्शवतो.
2. वाइल्डकार्ड (*): जर क्रेडेन्शियल्स समाविष्ट नसतील, तर Access-Control-Allow-Origin: * हे मूल्य कोणत्याही मूळ वेबसाइटला परवानगी देते. अशा वेळी "Access-Control-Allow-Origin या विनंतीसाठी कोणत्याही मूळची अनुमती देते." हा निर्णय मिळतो.
3. क्रेडेन्शियल्ससह निर्बंध: जेव्हा विनंतीमध्ये क्रेडेन्शियल्स समाविष्ट असतात, तेव्हा Access-Control-Allow-Origin चे मूल्य वाइल्डकार्ड (*) असू शकत नाही. तसे असल्यास "Access-Control-Allow-Origin * असू शकत नाही." हा त्रुटी संदेश मिळतो.
4. अवैध मूल्ये: जर Access-Control-Allow-Origin मध्ये स्वल्पविरामाने विभक्त केलेली एकापेक्षा जास्त मूल्ये असतील, तर ते अवैध मानले जाते. अशा वेळी "Access-Control-Allow-Origin चे अवैध मूल्य आहे: ‹value›." हा संदेश मिळतो. जर हे शीर्षलेख गहाळ असेल, तर "Access-Control-Allow-Origin गहाळ आहे." हा निर्णय दर्शवला जातो.

प्रीफ्लाइट विनंत्या: पद्धती आणि शीर्षलेख तपासणी

जटिल विनंत्या पाठवण्यापूर्वी ब्राउझर स्वयंचलितपणे एक OPTIONS विनंती पाठवतो, ज्याला प्रीफ्लाइट (Preflight) विनंती म्हणतात. सर्व्हर या प्रीफ्लाइट विनंतीला यशस्वी 2xx स्थिती कोडसह प्रतिसाद देणे आवश्यक आहे. जर प्रतिसादामध्ये HTTP स्थिती ओळ नसेल, तर "नाही HTTP स्थिती ओळ पेस्ट केली होती, त्यामुळे आवश्यक 2xx प्रीफ्लाइट स्थिती तपासली जाऊ शकत नाही." हा संदेश मिळतो आणि प्रीफ्लाइट स्थिती अज्ञात राहते.

पद्धतींची तपासणी (Access-Control-Allow-Methods)

• जर विनंती केलेली पद्धत CORS-सुरक्षित (CORS-safelisted) असेल, तर ती Access-Control-Allow-Methods मध्ये असण्याची आवश्यकता नसते. अशा वेळी निर्णय "‹method› ही CORS-सुरक्षित पद्धत आहे आणि ती Access-Control-Allow-Methods मध्ये दिसण्याची आवश्यकता नाही." असा येतो.
• इतर पद्धतींसाठी, जर सर्व्हरने परवानगी दिली असेल, तर "प्रीफ्लाइट ‹method› परवानगी देते." हा संदेश मिळतो. परवानगी नसल्यास "Access-Control-Allow-Methods ‹method› ला परवानगी देत ​​नाही." हा निर्णय येतो.

शीर्षलेखांची तपासणी (Access-Control-Allow-Headers)

• जर विनंती केलेल्या कोणत्याही शीर्षलेखाला प्रीफ्लाइट मंजुरीची आवश्यकता नसेल, तर "विनंती केलेल्या कोणत्याही शीर्षलेख नावांना प्रीफ्लाइट मंजुरीची आवश्यकता नाही." हा निर्णय मिळतो.
• क्रेडेन्शियल्स नसलेल्या विनंत्यांसाठी वाइल्डकार्ड * सर्व शीर्षलेखांना परवानगी देते, परंतु Authorization शीर्षलेख याला अपवाद आहे. Authorization शीर्षलेख नेहमी स्पष्टपणे सूचीबद्ध असणे आवश्यक आहे. जर ते सूचीबद्ध नसेल, तर "Authorization स्पष्टपणे सूचीबद्ध करणे आवश्यक आहे; Access-Control-Allow-Headers: * ते कव्हर करत नाही." हा संदेश मिळतो.

क्रेडेन्शियल्स आणि वाइल्डकार्डचे वर्तन

क्रेडेन्शियल्स (जसे की कुकीज किंवा HTTP प्रमाणीकरण) समाविष्ट असलेल्या विनंत्यांसाठी CORS चे नियम अधिक कडक असतात:

• क्रेडेन्शियल्स समाविष्ट असताना Access-Control-Allow-Credentials हे शीर्षलेख तंतोतंत true असणे बंधनकारक आहे. जर ते नसेल, तर "क्रेडेंशियल विनंतीसाठी Access-Control-Allow-Credentials: true आवश्यक आहे." हा निर्णय मिळतो.
• क्रेडेन्शियल्स समाविष्ट नसताना या शीर्षलेखाचा निर्णयावर कोणताही परिणाम होत नाही.
• क्रेडेन्शियल्स समाविष्ट असताना, अनुमत पद्धती आणि शीर्षलेखांसाठी वापरले जाणारे वाइल्डकार्ड (*) त्यांचा वाइल्डकार्ड अर्थ गमावतात.

गोपनीयता आणि प्रक्रियेची माहिती

या साधनामध्ये सुरक्षितता आणि गोपनीयतेला प्राधान्य दिले जाते. तुमचे प्रविष्ट केलेले प्रतिसाद शीर्षलेख आणि विनंतीचे तपशील पूर्णपणे तुमच्या ब्राउझरमध्येच प्रक्रिया केले जातात. BroBroGo वर कोणताही डेटा अपलोड किंवा जतन केला जात नाही.

हे साधन केवळ प्रदान केलेल्या प्रतिसाद शीर्षलेखांचे आणि विनंती तपशीलांचे विश्लेषण करते. हे साधन कोणत्याही बाह्य सर्व्हरशी संपर्क साधत नाही, URL वाचत नाही, कुकीज सेट करत नाही, DNS/TLS तपासत नाही किंवा सर्व्हर कॉन्फिगरेशनमध्ये बदल करत नाही.

वारंवार विचारले जाणारे प्रश्न (FAQ)

मी वास्तविक प्रतिसाद पेस्ट करावा की प्रीफ्लाइट प्रतिसाद?
ब्राउझर कोड एक प्रतिसाद वाचू शकतो की नाही हे तपासण्यासाठी वास्तविक प्रतिसाद वापरा. OPTIONS प्रत्युत्तरासाठी प्रीफ्लाइट प्रतिसाद वापरा जे नंतरची पद्धत आणि त्याच्या विनंती केलेल्या शीर्षलेख नावांना मान्यता देते.

क्रेडेन्शियलसह वाइल्डकार्ड अयशस्वी का होऊ शकते?
जेव्हा कुकीज किंवा HTTP प्रमाणीकरण समाविष्ट केले जाते, तेव्हा अनुमत मूळ विनंती केलेल्या मूळशी तंतोतंत जुळले पाहिजे. अनुमत पद्धती आणि शीर्षलेखांसाठी वाइल्डकार्ड देखील त्यांचा वाइल्डकार्ड अर्थ गमावतात.

उत्तीर्ण परिणाम थेट विनंती कार्य करेल हे सिद्ध करते का?
नाही. हा परिणाम फक्त पेस्ट केलेला प्रतिसाद आणि येथे प्रविष्ट केलेल्या विनंती तपशीलांचा समावेश करतो. पुनर्निर्देशन, कॅशे केलेले प्रतिसाद, सर्व्हरचे नियम बदलणे, ब्राउझर विस्तार आणि प्रीफ्लाइट नंतर प्रत्यक्ष प्रतिसाद तरीही परिणाम बदलू शकतात.