फ्रंटएंड सुरक्षा मजबूत करणे: कंटेंट सिक्युरिटी पॉलिसी (CSP) आणि CORS

आजच्या एकमेकांशी जोडलेल्या डिजिटल जगात, फ्रंटएंड सुरक्षा अत्यंत महत्त्वाची आहे. वेब ॲप्लिकेशन्सना अत्याधुनिक हल्ल्यांचा सामना करावा लागतो, त्यामुळे मजबूत सुरक्षा उपाय आवश्यक बनतात. सुरक्षित फ्रंटएंड आर्किटेक्चरचे दोन महत्त्वाचे घटक म्हणजे कंटेंट सिक्युरिटी पॉलिसी (CSP) आणि क्रॉस-ओरिजीन रिसोर्स शेअरिंग (CORS). हे सर्वसमावेशक मार्गदर्शक या तंत्रज्ञानावर सखोल माहिती देते, व्यावहारिक उदाहरणे आणि कृती करण्यायोग्य अंतर्दृष्टी प्रदान करते ज्यामुळे तुम्हाला तुमच्या वेब ॲप्लिकेशन्सना आधुनिक धोक्यांपासून वाचवता येईल.

कंटेंट सिक्युरिटी पॉलिसी (CSP) म्हणजे काय?

कंटेंट सिक्युरिटी पॉलिसी (CSP) हा सुरक्षेचा एक अतिरिक्त स्तर आहे जो क्रॉस-साइट स्क्रिप्टिंग (XSS) आणि डेटा इंजेक्शन हल्ल्यांसारख्या विशिष्ट प्रकारच्या हल्ल्यांना शोधण्यात आणि कमी करण्यात मदत करतो. वेब सर्वर ब्राउझरला Content-Security-Policy HTTP प्रतिसाद हेडर पाठवून CSP लागू करतो. हा हेडर त्या स्त्रोतांची श्वेतसूची (whitelist) परिभाषित करतो जिथून ब्राउझरला संसाधने लोड करण्याची परवानगी आहे. ब्राउझर लोड करू शकणाऱ्या सामग्रीच्या स्त्रोतांना प्रतिबंधित करून, CSP हल्लेखोरांना तुमच्या वेबसाइटमध्ये दुर्भावनापूर्ण कोड इंजेक्ट करणे लक्षणीयरीत्या अधिक कठीण बनवते.

CSP कसे कार्य करते

CSP ब्राउझरला केवळ मंजूर स्त्रोतांकडून संसाधने (उदा. स्क्रिप्ट्स, स्टाईलशीट्स, प्रतिमा, फॉन्ट) लोड करण्याचे निर्देश देऊन कार्य करते. हे स्त्रोत CSP हेडरमध्ये निर्देशांचा (directives) वापर करून निर्दिष्ट केले जातात. जर ब्राउझरने स्पष्टपणे परवानगी नसलेल्या स्त्रोतावरून एखादे संसाधन लोड करण्याचा प्रयत्न केला, तर तो विनंती अवरोधित करेल आणि उल्लंघनाची नोंद करेल.

CSP निर्देश (Directives): एक सर्वसमावेशक विहंगावलोकन

CSP निर्देश विशिष्ट स्त्रोतांकडून लोड केल्या जाऊ शकणाऱ्या संसाधनांचे प्रकार नियंत्रित करतात. येथे काही सर्वात महत्त्वाच्या निर्देशांचे विश्लेषण आहे:

• default-src: सर्व सामग्री प्रकारांसाठी डीफॉल्ट स्त्रोत निर्दिष्ट करते. हा एक फॉलबॅक निर्देश आहे जो इतर, अधिक विशिष्ट निर्देश अनुपस्थित असताना लागू होतो.
• script-src: स्क्रिप्ट्स ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते. XSS हल्ले रोखण्यासाठी हे महत्त्वाचे आहे.
• style-src: स्टाईलशीट्स ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते.
• img-src: प्रतिमा ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते.
• font-src: फॉन्ट ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते.
• media-src: ऑडिओ आणि व्हिडिओ ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते.
• object-src: प्लगइन्स (उदा. फ्लॅश) ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते. त्यांच्या अंगभूत सुरक्षा धोक्यांमुळे प्लगइन्स पूर्णपणे अक्षम करण्यासाठी हे अनेकदा 'none' वर सेट केले जाते.
• frame-src: फ्रेम्स (उदा. <iframe>) ज्या स्त्रोतांकडून लोड केल्या जाऊ शकतात ते निर्दिष्ट करते.
• connect-src: स्क्रिप्ट इंटरफेस जसे की XMLHttpRequest, WebSocket आणि EventSource वापरून वापरकर्ता एजंट (user agent) ज्या URLs शी कनेक्ट होऊ शकतो ते निर्दिष्ट करते.
• base-uri: दस्तऐवजाच्या <base> घटकामध्ये वापरल्या जाऊ शकणाऱ्या URLs निर्दिष्ट करते.
• form-action: फॉर्म सबमिशन ज्या URLs वर पाठवले जाऊ शकतात ते निर्दिष्ट करते.
• upgrade-insecure-requests: वापरकर्ता एजंटला असुरक्षित विनंत्या (HTTP) आपोआप सुरक्षित विनंत्या (HTTPS) मध्ये अपग्रेड करण्याचे निर्देश देते.
• report-uri: एक URL निर्दिष्ट करते जिथे ब्राउझरने CSP उल्लंघनांबद्दल अहवाल पाठवावेत. हा निर्देश `report-to` च्या बाजूने अप्रचलित (deprecated) केला आहे.
• report-to: `Report-To` हेडरमध्ये परिभाषित केलेला अहवाल गट (reporting group) नाव निर्दिष्ट करते, जिथे ब्राउझरने CSP उल्लंघनांबद्दल अहवाल पाठवावेत.

CSP स्त्रोत सूची कीवर्ड्स

CSP निर्देशांमध्ये, तुम्ही परवानगी असलेल्या स्त्रोतांना परिभाषित करण्यासाठी स्त्रोत सूची कीवर्ड वापरू शकता. येथे काही सामान्य कीवर्ड्स आहेत:

• 'self': दस्तऐवजाप्रमाणेच स्त्रोतावरून (स्कीम आणि होस्ट) संसाधनांना परवानगी देते.
• 'none': सर्व स्त्रोतांकडून संसाधनांना परवानगी देत ​​नाही.
• 'unsafe-inline': इनलाइन स्क्रिप्ट्स आणि स्टाईल्सच्या वापरास परवानगी देते (उदा. <script> टॅग आणि स्टाईल ॲट्रिब्यूट्स). XSS विरुद्ध CSP संरक्षण लक्षणीयरीत्या कमकुवत करत असल्यामुळे अत्यंत सावधगिरीने वापर करा.
• 'unsafe-eval': eval() आणि Function() सारख्या डायनॅमिक कोड इव्हॅल्युएशन फंक्शन्सच्या वापरास परवानगी देते. हे महत्त्वपूर्ण सुरक्षा धोके निर्माण करत असल्यामुळे अत्यंत सावधगिरीने वापर करा.
• 'unsafe-hashes': निर्दिष्ट हॅशशी जुळणारे विशिष्ट इनलाइन इव्हेंट हँडलर्स किंवा <style> टॅगना परवानगी देते. ब्राउझर सपोर्ट आवश्यक आहे. सावधगिरीने वापर करा.
• 'strict-dynamic': हे निर्दिष्ट करते की मार्कअपमध्ये उपस्थित असलेल्या स्क्रिप्टला, नॉनस (nonce) किंवा हॅश (hash) सह देऊन स्पष्टपणे दिलेला विश्वास, त्या मूळ स्क्रिप्टद्वारे लोड केलेल्या सर्व स्क्रिप्ट्सना प्रसारित केला जाईल.
• data: data: URIs ना परवानगी देते (उदा. base64 मध्ये एन्कोड केलेल्या इनलाइन प्रतिमा). सावधगिरीने वापर करा.
• https:: कोणत्याही डोमेनमधून HTTPS वरून संसाधने लोड करण्यास परवानगी देते.
• [hostname]: विशिष्ट डोमेनमधून संसाधनांना परवानगी देते (उदा. example.com). तुम्ही पोर्ट नंबर देखील निर्दिष्ट करू शकता (उदा. example.com:8080).
• [scheme]://[hostname]:[port]: एक पूर्णतः पात्र URI, निर्दिष्ट स्कीम, होस्ट आणि पोर्टवरून संसाधनांना परवानगी देते.

CSP चे व्यावहारिक उदाहरणे

चला CSP हेडर्सची काही व्यावहारिक उदाहरणे पाहूया:

उदाहरण 1: 'self' सह मूलभूत CSP

हे धोरण फक्त त्याच स्त्रोतावरून संसाधनांना परवानगी देते:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

उदाहरण 2: विशिष्ट डोमेनमधून स्क्रिप्ट्सना परवानगी देणे

हे धोरण तुमच्या स्वतःच्या डोमेनमधून आणि विश्वसनीय CDN मधून स्क्रिप्ट्सना परवानगी देते:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

उदाहरण 3: इनलाइन स्क्रिप्ट्स आणि स्टाईल्स अक्षम करणे

हे धोरण इनलाइन स्क्रिप्ट्स आणि स्टाईल्सना परवानगी देत ​​नाही, जे XSS विरुद्ध एक मजबूत संरक्षण आहे:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

महत्त्वाचे: इनलाइन स्क्रिप्ट्स अक्षम करण्यासाठी तुमच्या HTML ला रिफॅक्टर करणे आवश्यक आहे जेणेकरून इनलाइन स्क्रिप्ट्स बाह्य फाइल्समध्ये जातील.

उदाहरण 4: इनलाइन स्क्रिप्ट्ससाठी नॉनस (Nonces) वापरणे

जर तुम्हाला इनलाइन स्क्रिप्ट्स वापरणे आवश्यक असेल, तर विशिष्ट इनलाइन स्क्रिप्ट ब्लॉक्सना श्वेतसूचीमध्ये (whitelist) समाविष्ट करण्यासाठी नॉनस (क्रिप्टोग्राफिकली रँडम, सिंगल-यूझ टोकन) वापरा. हे 'unsafe-inline' पेक्षा अधिक सुरक्षित आहे. सर्वरने प्रत्येक विनंतीसाठी एक अद्वितीय नॉनस तयार करणे आवश्यक आहे आणि ते CSP हेडर आणि <script> टॅग दोन्हीमध्ये समाविष्ट करणे आवश्यक आहे.

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

टीप: प्रत्येक विनंतीसाठी नवीन नॉनस तयार करण्याचे लक्षात ठेवा. नॉनस पुन्हा वापरू नका!

उदाहरण 5: इनलाइन स्टाईल्ससाठी हॅश (Hashes) वापरणे

नॉनसप्रमाणेच, विशिष्ट इनलाइन <style> ब्लॉक्सना श्वेतसूचीमध्ये (whitelist) समाविष्ट करण्यासाठी हॅश वापरले जाऊ शकतात. हे स्टाईल सामग्रीचा SHA256, SHA384 किंवा SHA512 हॅश तयार करून केले जाते.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

टीप: हॅश हे नॉनसपेक्षा कमी लवचिक असतात कारण स्टाईल सामग्रीमध्ये कोणताही बदल हॅशला अवैध करेल.

उदाहरण 6: CSP उल्लंघनांची नोंद करणे

CSP उल्लंघनांचे निरीक्षण करण्यासाठी, report-uri किंवा report-to निर्देश वापरा:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

तुम्हाला Report-To हेडर देखील कॉन्फिगर करणे आवश्यक आहे. Report-To हेडर एक किंवा अधिक अहवाल गट (reporting groups) परिभाषित करतो, जे अहवाल कुठे आणि कसे पाठवले जावेत हे निर्दिष्ट करतात.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

CSP ची चाचणी आणि अंमलबजावणी

CSP लागू करण्यासाठी काळजीपूर्वक नियोजन आणि चाचणी आवश्यक आहे. प्रतिबंधात्मक धोरणाने सुरुवात करा आणि आवश्यकतेनुसार हळूहळू ते शिथिल करा. संसाधने अवरोधित न करता तुमच्या धोरणाची चाचणी घेण्यासाठी Content-Security-Policy-Report-Only हेडर वापरा. हा हेडर धोरण लागू न करता उल्लंघनांची नोंद करतो, ज्यामुळे तुम्हाला उत्पादन (production) मध्ये धोरण तैनात करण्यापूर्वी समस्या ओळखता आणि दुरुस्त करता येतात.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

कोणतीही उल्लंघने ओळखण्यासाठी ब्राउझरद्वारे व्युत्पन्न केलेल्या अहवालांचे विश्लेषण करा आणि त्यानुसार तुमचे धोरण समायोजित करा. एकदा तुम्हाला खात्री झाली की तुमचे धोरण योग्यरित्या कार्य करत आहे, तर Content-Security-Policy हेडर वापरून ते तैनात करा.

CSP साठी सर्वोत्तम पद्धती

• default-src ने सुरुवात करा: मूलभूत धोरण स्थापित करण्यासाठी नेहमी default-src परिभाषित करा.
• विशिष्ट रहा: तुमच्या धोरणाची व्याप्ती मर्यादित करण्यासाठी विशिष्ट निर्देश आणि स्त्रोत सूची कीवर्ड वापरा.
• 'unsafe-inline' आणि 'unsafe-eval' टाळा: हे कीवर्ड CSP ला लक्षणीयरीत्या कमकुवत करतात आणि शक्य असेल तेव्हा टाळले पाहिजेत.
• इनलाइन स्क्रिप्ट्स आणि स्टाईल्ससाठी नॉनस किंवा हॅश वापरा: जर तुम्हाला इनलाइन स्क्रिप्ट्स किंवा स्टाईल्स वापरणे आवश्यक असेल, तर विशिष्ट कोड ब्लॉक्सना श्वेतसूचीमध्ये समाविष्ट करण्यासाठी नॉनस किंवा हॅश वापरा.
• CSP उल्लंघनांवर लक्ष ठेवा: CSP उल्लंघनांवर लक्ष ठेवण्यासाठी आणि त्यानुसार तुमचे धोरण समायोजित करण्यासाठी report-uri किंवा report-to निर्देश वापरा.
• कसून चाचणी करा: उत्पादन (production) मध्ये धोरण तैनात करण्यापूर्वी तुमच्या धोरणाची चाचणी घेण्यासाठी Content-Security-Policy-Report-Only हेडर वापरा.
• पुनरावृत्ती करा आणि परिष्कृत करा: CSP हे एकदाच कॉन्फिगर करण्याचे नाही. तुमच्या ॲप्लिकेशनमधील बदलांशी आणि धोक्यांच्या परिस्थितीशी जुळवून घेण्यासाठी तुमच्या धोरणाचे सतत निरीक्षण करा आणि त्यात सुधारणा करा.

क्रॉस-ओरिजीन रिसोर्स शेअरिंग (CORS) म्हणजे काय?

क्रॉस-ओरिजीन रिसोर्स शेअरिंग (CORS) ही एक यंत्रणा आहे जी एका स्त्रोतावरील (डोमेन) वेब पृष्ठांना वेगळ्या स्त्रोतावरील संसाधनांना ॲक्सेस करण्याची परवानगी देते. डीफॉल्टनुसार, ब्राउझर Same-Origin Policy लागू करतात, जे स्क्रिप्ट्सना ज्या स्त्रोतावरून स्क्रिप्ट उत्पन्न झाली आहे त्यापेक्षा वेगळ्या स्त्रोतावर विनंत्या करण्यापासून प्रतिबंधित करते. CORS या निर्बंधांना निवडकपणे शिथिल करण्याचा एक मार्ग प्रदान करते, ज्यामुळे दुर्भावनापूर्ण हल्ल्यांपासून संरक्षण करताना कायदेशीर क्रॉस-ओरिजीन विनंत्यांना परवानगी मिळते.

Same-Origin Policy समजून घेणे

Same-Origin Policy ही एक मूलभूत सुरक्षा यंत्रणा आहे जी एका वेबसाइटवरील दुर्भावनापूर्ण स्क्रिप्टला दुसऱ्या वेबसाइटवरील संवेदनशील डेटा ॲक्सेस करण्यापासून प्रतिबंधित करते. एक स्त्रोत स्कीम (प्रोटोकॉल), होस्ट (डोमेन) आणि पोर्टद्वारे परिभाषित केला जातो. दोन URLs चा स्त्रोत (origin) समान असतो जर आणि तरच त्यांचा स्कीम, होस्ट आणि पोर्ट समान असतील.

उदाहरणार्थ:

• https://www.example.com/app1/index.html आणि https://www.example.com/app2/index.html यांचा स्त्रोत (origin) समान आहे.
• https://www.example.com/index.html आणि http://www.example.com/index.html यांचे स्त्रोत (origin) भिन्न आहेत (भिन्न स्कीम).
• https://www.example.com/index.html आणि https://sub.example.com/index.html यांचे स्त्रोत (origin) भिन्न आहेत (भिन्न होस्ट).
• https://www.example.com:8080/index.html आणि https://www.example.com:80/index.html यांचे स्त्रोत (origin) भिन्न आहेत (भिन्न पोर्ट).

CORS कसे कार्य करते

जेव्हा एखादे वेब पृष्ठ क्रॉस-ओरिजीन विनंती करते, तेव्हा ब्राउझर प्रथम सर्वरला "प्रीफ्लाइट" विनंती पाठवतो. प्रीफ्लाइट विनंती HTTP OPTIONS पद्धत वापरते आणि त्यात HTTP पद्धत आणि वास्तविक विनंती वापरणारे हेडर्स दर्शवणारे हेडर्स समाविष्ट असतात. त्यानंतर सर्वर क्रॉस-ओरिजीन विनंतीला परवानगी आहे की नाही हे दर्शवणारे हेडर्ससह प्रतिसाद देतो.

जर सर्वर विनंतीला परवानगी देत ​​असेल, तर तो प्रतिसादामध्ये Access-Control-Allow-Origin हेडर समाविष्ट करतो. हा हेडर त्या स्त्रोतांना (origins) निर्दिष्ट करतो ज्यांना संसाधनामध्ये प्रवेश करण्याची परवानगी आहे. त्यानंतर ब्राउझर वास्तविक विनंतीसह पुढे जातो. जर सर्वर विनंतीला परवानगी देत ​​नसेल, तर तो Access-Control-Allow-Origin हेडर समाविष्ट करत नाही आणि ब्राउझर विनंतीला अवरोधित करतो.

CORS हेडर्स: एक सविस्तर दृष्टिकोन

CORS ब्राउझर आणि सर्वर दरम्यान संवाद साधण्यासाठी HTTP हेडर्सवर अवलंबून असतो. येथे मुख्य CORS हेडर्स आहेत:

• Access-Control-Allow-Origin: संसाधनामध्ये प्रवेश करण्याची परवानगी असलेल्या स्त्रोतांना (origins) निर्दिष्ट करते. या हेडरमध्ये एक विशिष्ट स्त्रोत (उदा. https://www.example.com), एक वाईल्डकार्ड (*), किंवा null असू शकते. * वापरल्याने कोणत्याही स्त्रोताकडून विनंत्यांना परवानगी मिळते, जे सुरक्षिततेच्या कारणास्तव सामान्यतः शिफारस केलेले नाही. `null` चा वापर केवळ "अपारदर्शक प्रतिसादांसाठी" (opaque responses) योग्य आहे, जसे की जेव्हा संसाधन `file://` प्रोटोकॉल किंवा डेटा URI वापरून प्राप्त केले जाते.
• Access-Control-Allow-Methods: क्रॉस-ओरिजीन विनंतीसाठी परवानगी असलेल्या HTTP पद्धती निर्दिष्ट करते (उदा. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: क्रॉस-ओरिजीन विनंतीमध्ये परवानगी असलेल्या HTTP हेडर्सना निर्दिष्ट करते. कस्टम हेडर्स हाताळण्यासाठी हे महत्त्वाचे आहे.
• Access-Control-Allow-Credentials: ब्राउझरने क्रॉस-ओरिजीन विनंतीमध्ये क्रेडेंशियल्स (उदा. कुकीज, ऑथोरायझेशन हेडर्स) समाविष्ट करावेत की नाही हे दर्शवते. क्रेडेंशियल्सना परवानगी देण्यासाठी हा हेडर true वर सेट करणे आवश्यक आहे.
• Access-Control-Expose-Headers: क्लायंटला कोणते हेडर्स उघड केले जाऊ शकतात ते निर्दिष्ट करते. डीफॉल्टनुसार, केवळ हेडर्सचा एक मर्यादित संच उघड केला जातो.
• Access-Control-Max-Age: ब्राउझर प्रीफ्लाइट विनंतीला (preflight request) किती जास्तीत जास्त वेळ (सेकंदात) कॅश करू शकतो हे निर्दिष्ट करते.
• Origin: हे ब्राउझरने विनंतीचा स्त्रोत दर्शवण्यासाठी पाठवलेला एक विनंती हेडर आहे.
• Vary: एक सामान्य HTTP हेडर, परंतु CORS साठी महत्त्वाचे आहे. जेव्हा `Access-Control-Allow-Origin` डायनॅमिकली तयार केले जाते, तेव्हा कॅशिंग यंत्रणांना `Origin` विनंती हेडरवर आधारित प्रतिसाद बदलतो हे सूचित करण्यासाठी प्रतिसादामध्ये `Vary: Origin` हेडर समाविष्ट केला पाहिजे.

CORS ची व्यावहारिक उदाहरणे

चला CORS कॉन्फिगरेशन्सची काही व्यावहारिक उदाहरणे पाहूया:

उदाहरण 1: विशिष्ट स्त्रोतावरून (Origin) विनंत्यांना परवानगी देणे

हे कॉन्फिगरेशन फक्त https://www.example.com वरून विनंत्यांना परवानगी देते:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

उदाहरण 2: कोणत्याही स्त्रोतावरून विनंत्यांना परवानगी देणे (शिफारस केलेले नाही)

हे कॉन्फिगरेशन कोणत्याही स्त्रोतावरून विनंत्यांना परवानगी देते. हे सुरक्षा धोके निर्माण करू शकत असल्याने सावधगिरीने वापर करा:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

उदाहरण 3: विशिष्ट पद्धती (Methods) आणि हेडर्सना परवानगी देणे

हे कॉन्फिगरेशन GET, POST आणि PUT पद्धतींना, तसेच Content-Type आणि Authorization हेडर्सना परवानगी देते:

            Access-Control-Allow-Origin: https://www.example.com\nAccess-Control-Allow-Methods: GET, POST, PUT\nAccess-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

उदाहरण 4: क्रेडेंशियल्सना परवानगी देणे

क्रेडेंशियल्सना (उदा. कुकीज) परवानगी देण्यासाठी, तुम्हाला Access-Control-Allow-Credentials true वर सेट करणे आणि एक विशिष्ट स्त्रोत निर्दिष्ट करणे आवश्यक आहे (क्रेडेंशियल्सना परवानगी देताना तुम्ही * वापरू शकत नाही):

            Access-Control-Allow-Origin: https://www.example.com\nAccess-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

तुम्हाला तुमच्या JavaScript fetch/XMLHttpRequest विनंतीमध्ये credentials: 'include' देखील सेट करणे आवश्यक आहे.

            fetch('https://api.example.com/data', {\n  credentials: 'include'\n})
            

              
                Copy
              
            
          

CORS प्रीफ्लाइट विनंत्या

विशिष्ट प्रकारच्या क्रॉस-ओरिजीन विनंत्यांसाठी (उदा. कस्टम हेडर्ससह विनंत्या किंवा GET, HEAD, किंवा POST व्यतिरिक्त Content-Type सह application/x-www-form-urlencoded, multipart/form-data, किंवा text/plain), ब्राउझर OPTIONS पद्धत वापरून प्रीफ्लाइट विनंती पाठवतो. वास्तविक विनंतीला परवानगी आहे की नाही हे दर्शवण्यासाठी सर्वरने योग्य CORS हेडर्ससह प्रीफ्लाइट विनंतीला प्रतिसाद देणे आवश्यक आहे.

प्रीफ्लाइट विनंती आणि प्रतिसादाचे एक उदाहरण येथे दिले आहे:

प्रीफ्लाइट विनंती (OPTIONS):

            OPTIONS /data HTTP/1.1\nOrigin: https://www.example.com\nAccess-Control-Request-Method: PUT\nAccess-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

प्रीफ्लाइट प्रतिसाद (200 OK):

            HTTP/1.1 200 OK\nAccess-Control-Allow-Origin: https://www.example.com\nAccess-Control-Allow-Methods: GET, POST, PUT\nAccess-Control-Allow-Headers: Content-Type, Authorization\nAccess-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Access-Control-Max-Age हेडर ब्राउझर प्रीफ्लाइट प्रतिसादाला (preflight response) किती वेळ कॅश करू शकतो हे निर्दिष्ट करतो, ज्यामुळे प्रीफ्लाइट विनंत्यांची संख्या कमी होते.

CORS आणि JSONP

JSON with Padding (JSONP) ही Same-Origin Policy ला बायपास करण्याची एक जुनी पद्धत आहे. तथापि, JSONP मध्ये महत्त्वपूर्ण सुरक्षा धोके आहेत आणि CORS च्या बाजूने ते टाळले पाहिजे. JSONP पृष्ठात <script> टॅग इंजेक्ट करण्यावर अवलंबून असते, जे अनियंत्रित कोड कार्यान्वित करू शकते. CORS क्रॉस-ओरिजीन विनंत्या हाताळण्यासाठी अधिक सुरक्षित आणि लवचिक मार्ग प्रदान करते.

CORS साठी सर्वोत्तम पद्धती

• * वापरणे टाळा: Access-Control-Allow-Origin हेडरमध्ये वाईल्डकार्ड (*) वापरणे टाळा, कारण ते कोणत्याही स्त्रोताकडून विनंत्यांना परवानगी देते. त्याऐवजी, संसाधनात प्रवेश करण्याची परवानगी असलेल्या विशिष्ट स्त्रोतांना निर्दिष्ट करा.
• पद्धती (methods) आणि हेडर्समध्ये विशिष्ट रहा: Access-Control-Allow-Methods आणि Access-Control-Allow-Headers हेडर्समध्ये परवानगी असलेल्या अचूक HTTP पद्धती आणि हेडर्स निर्दिष्ट करा.
• Access-Control-Allow-Credentials सावधगिरीने वापरा: तुम्हाला क्रॉस-ओरिजीन विनंत्यांमध्ये क्रेडेंशियल्सना (उदा. कुकीज) परवानगी देण्याची आवश्यकता असल्यासच Access-Control-Allow-Credentials सक्षम करा. क्रेडेंशियल्सना परवानगी देण्याच्या सुरक्षा परिणामांबद्दल जागरूक रहा.
• तुमच्या प्रीफ्लाइट विनंत्या सुरक्षित करा: तुमचा सर्वर प्रीफ्लाइट विनंत्या योग्यरित्या हाताळतो आणि योग्य CORS हेडर्स परत करतो याची खात्री करा.
• HTTPS वापरा: स्त्रोत आणि तुम्ही क्रॉस-ओरिजीन ॲक्सेस करत असलेल्या संसाधनांसाठी नेहमी HTTPS वापरा. हे मॅन-इन-द-मिडल हल्ल्यांपासून संरक्षण करण्यास मदत करते.
• Vary: Origin: जर तुम्ही `Access-Control-Allow-Origin` हेडर डायनॅमिकली तयार करत असाल, तर कॅशिंग समस्या टाळण्यासाठी नेहमी `Vary: Origin` हेडर समाविष्ट करा.

व्यवहारात CSP आणि CORS: एक संयुक्त दृष्टिकोन

CSP आणि CORS दोन्ही सुरक्षा समस्यांना संबोधित करत असले तरी, ते वेगवेगळ्या स्तरांवर कार्य करतात आणि पूरक संरक्षण प्रदान करतात. CSP ब्राउझरला दुर्भावनापूर्ण सामग्री लोड करण्यापासून रोखण्यावर लक्ष केंद्रित करते, तर CORS तुमच्या सर्वरवरील संसाधनांना कोणते स्त्रोत ॲक्सेस करू शकतात हे नियंत्रित करण्यावर लक्ष केंद्रित करते.

CSP आणि CORS एकत्र करून, तुम्ही तुमच्या वेब ॲप्लिकेशन्ससाठी अधिक मजबूत सुरक्षा स्थिती (security posture) तयार करू शकता. उदाहरणार्थ, स्क्रिप्ट्स कोणत्या स्त्रोतांकडून लोड केल्या जाऊ शकतात हे प्रतिबंधित करण्यासाठी तुम्ही CSP वापरू शकता आणि तुमच्या API एंडपॉइंट्सना कोणते स्त्रोत ॲक्सेस करू शकतात हे नियंत्रित करण्यासाठी CORS वापरू शकता.

उदाहरण: CSP आणि CORS सह API सुरक्षित करणे

समजा तुमच्याकडे https://api.example.com वर होस्ट केलेला एक API आहे जो तुम्हाला फक्त https://www.example.com वरून ॲक्सेसिबल असावा असे वाटते. तुम्ही तुमचा सर्वर खालील हेडर्स परत करण्यासाठी कॉन्फिगर करू शकता:

API प्रतिसाद हेडर्स (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com\nContent-Type: application/json
            

              
                Copy
              
            
          

आणि तुम्ही तुमच्या वेबसाइटला (https://www.example.com) खालील CSP हेडर वापरण्यासाठी कॉन्फिगर करू शकता:

वेबसाइट CSP हेडर (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

हे CSP धोरण वेबसाइटला स्क्रिप्ट्स लोड करण्यास आणि API शी कनेक्ट होण्यास परवानगी देते, परंतु ते स्क्रिप्ट्स लोड करण्यापासून किंवा इतर डोमेनशी कनेक्ट होण्यापासून प्रतिबंधित करते.

निष्कर्ष

कंटेंट सिक्युरिटी पॉलिसी (CSP) आणि क्रॉस-ओरिजीन रिसोर्स शेअरिंग (CORS) ही तुमच्या फ्रंटएंड ॲप्लिकेशन्सची सुरक्षा मजबूत करण्यासाठी आवश्यक साधने आहेत. CSP आणि CORS काळजीपूर्वक कॉन्फिगर करून, तुम्ही XSS हल्ले, डेटा इंजेक्शन हल्ले आणि इतर सुरक्षा भेद्यतांचा धोका लक्षणीयरीत्या कमी करू शकता. प्रतिबंधात्मक धोरणाने सुरुवात करणे, कसून चाचणी करणे आणि तुमच्या ॲप्लिकेशनमधील बदल आणि विकसित होणाऱ्या धोक्यांच्या परिस्थितीशी जुळवून घेण्यासाठी तुमच्या कॉन्फिगरेशनचे सतत निरीक्षण करणे आणि त्यात सुधारणा करणे लक्षात ठेवा. फ्रंटएंड सुरक्षेला प्राधान्य देऊन, तुम्ही तुमच्या वापरकर्त्यांचे संरक्षण करू शकता आणि आजच्या वाढत्या जटिल डिजिटल जगात तुमच्या वेब ॲप्लिकेशन्सची अखंडता सुनिश्चित करू शकता.