फ़्रंटएंड सुरक्षा सुदृढ़ीकरण: कंटेंट सिक्योरिटी पॉलिसी और CORS

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

कंटेंट सिक्योरिटी पॉलिसी (CSP) क्या है?

कंटेंट सिक्योरिटी पॉलिसी (CSP) सुरक्षा की एक अतिरिक्त परत है जो क्रॉस-साइट स्क्रिप्टिंग (XSS) और डेटा इंजेक्शन हमलों सहित कुछ प्रकार के हमलों का पता लगाने और उन्हें कम करने में मदद करती है। CSP को वेब सर्वर द्वारा ब्राउज़र को एक Content-Security-Policy HTTP रिस्पॉन्स हेडर भेजकर लागू किया जाता है। यह हेडर उन स्रोतों की एक व्हाइटलिस्ट को परिभाषित करता है जिनसे ब्राउज़र को संसाधन लोड करने की अनुमति है। उन सामग्री स्रोतों को प्रतिबंधित करके जिनसे एक ब्राउज़र सामग्री लोड कर सकता है, CSP हमलावरों के लिए आपकी वेबसाइट में दुर्भावनापूर्ण कोड इंजेक्ट करना काफी अधिक कठिन बना देता है।

CSP कैसे काम करता है

CSP ब्राउज़र को केवल अनुमोदित स्रोतों से संसाधन (जैसे, स्क्रिप्ट, स्टाइलशीट, छवियां, फ़ॉन्ट्स) लोड करने का निर्देश देकर काम करता है। ये स्रोत CSP हेडर में निर्देशों (directives) का उपयोग करके निर्दिष्ट किए जाते हैं। यदि कोई ब्राउज़र किसी ऐसे स्रोत से संसाधन लोड करने का प्रयास करता है जिसकी स्पष्ट रूप से अनुमति नहीं है, तो वह अनुरोध को ब्लॉक कर देगा और उल्लंघन की रिपोर्ट करेगा।

CSP निर्देश: एक व्यापक अवलोकन

CSP निर्देश उन संसाधनों के प्रकारों को नियंत्रित करते हैं जिन्हें विशिष्ट स्रोतों से लोड किया जा सकता है। यहाँ कुछ सबसे महत्वपूर्ण निर्देशों का विवरण दिया गया है:

• default-src: सभी सामग्री प्रकारों के लिए डिफ़ॉल्ट स्रोत निर्दिष्ट करता है। यह एक फॉलबैक निर्देश है जो तब लागू होता है जब अन्य, अधिक विशिष्ट निर्देश मौजूद नहीं होते हैं।
• script-src: उन स्रोतों को निर्दिष्ट करता है जिनसे स्क्रिप्ट लोड की जा सकती हैं। यह XSS हमलों को रोकने के लिए महत्वपूर्ण है।
• style-src: उन स्रोतों को निर्दिष्ट करता है जिनसे स्टाइलशीट लोड की जा सकती हैं।
• img-src: उन स्रोतों को निर्दिष्ट करता है जिनसे छवियां लोड की जा सकती हैं।
• font-src: उन स्रोतों को निर्दिष्ट करता है जिनसे फ़ॉन्ट्स लोड किए जा सकते हैं।
• media-src: उन स्रोतों को निर्दिष्ट करता है जिनसे ऑडियो और वीडियो लोड किए जा सकते हैं।
• object-src: उन स्रोतों को निर्दिष्ट करता है जिनसे प्लगइन्स (जैसे, Flash) लोड किए जा सकते हैं। इसे अक्सर 'none' पर सेट किया जाता है ताकि उनके अंतर्निहित सुरक्षा जोखिमों के कारण प्लगइन्स को पूरी तरह से अक्षम किया जा सके।
• frame-src: उन स्रोतों को निर्दिष्ट करता है जिनसे फ़्रेम (जैसे, <iframe>) लोड किए जा सकते हैं।
• connect-src: उन URL को निर्दिष्ट करता है जिनसे उपयोगकर्ता एजेंट स्क्रिप्ट इंटरफेस जैसे XMLHttpRequest, WebSocket और EventSource का उपयोग करके कनेक्ट हो सकता है।
• base-uri: उन URL को निर्दिष्ट करता है जिनका उपयोग दस्तावेज़ के <base> तत्व में किया जा सकता है।
• form-action: उन URL को निर्दिष्ट करता है जहाँ फ़ॉर्म सबमिशन भेजे जा सकते हैं।
• upgrade-insecure-requests: उपयोगकर्ता एजेंट को असुरक्षित अनुरोधों (HTTP) को स्वचालित रूप से सुरक्षित अनुरोधों (HTTPS) में अपग्रेड करने का निर्देश देता है।
• report-uri: एक URL निर्दिष्ट करता है जहाँ ब्राउज़र को CSP उल्लंघनों के बारे में रिपोर्ट भेजनी चाहिए। यह निर्देश `report-to` के पक्ष में बहिष्कृत (deprecated) है।
• report-to: `Report-To` हेडर में परिभाषित एक रिपोर्टिंग समूह का नाम निर्दिष्ट करता है, जहाँ ब्राउज़र को CSP उल्लंघनों के बारे में रिपोर्ट भेजनी चाहिए।

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

CSP निर्देशों के भीतर, आप अनुमत स्रोतों को परिभाषित करने के लिए स्रोत सूची कीवर्ड का उपयोग कर सकते हैं। यहाँ कुछ सामान्य कीवर्ड दिए गए हैं:

• 'self': दस्तावेज़ के समान ऑरिजिन (स्कीम और होस्ट) से संसाधनों की अनुमति देता है।
• 'none': सभी स्रोतों से संसाधनों को अस्वीकार करता है।
• 'unsafe-inline': इनलाइन स्क्रिप्ट और स्टाइल (जैसे, <script> टैग और स्टाइल एट्रिब्यूट्स) के उपयोग की अनुमति देता है। अत्यधिक सावधानी के साथ प्रयोग करें क्योंकि यह XSS के खिलाफ CSP सुरक्षा को काफी कमजोर करता है।
• 'unsafe-eval': eval() और Function() जैसे डायनेमिक कोड मूल्यांकन कार्यों के उपयोग की अनुमति देता है। अत्यधिक सावधानी के साथ प्रयोग करें क्योंकि यह महत्वपूर्ण सुरक्षा जोखिम पैदा करता है।
• 'unsafe-hashes': विशिष्ट इनलाइन ईवेंट हैंडलर या <style> टैग की अनुमति देता है जो एक निर्दिष्ट हैश से मेल खाते हैं। ब्राउज़र समर्थन की आवश्यकता है। सावधानी से प्रयोग करें।
• 'strict-dynamic': यह निर्दिष्ट करता है कि मार्कअप में मौजूद स्क्रिप्ट को स्पष्ट रूप से दिया गया विश्वास, एक नॉन्स या हैश के साथ, उस रूट स्क्रिप्ट द्वारा लोड की गई सभी स्क्रिप्ट्स में प्रचारित किया जाएगा।
• data: data: URIs की अनुमति देता है (जैसे, बेस64 के रूप में एन्कोड की गई इनलाइन छवियां)। सावधानी से प्रयोग करें।
• 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: इनलाइन स्क्रिप्ट्स के लिए नॉन्स का उपयोग करना

यदि आपको इनलाइन स्क्रिप्ट का उपयोग करना ही है, तो विशिष्ट इनलाइन स्क्रिप्ट ब्लॉक को व्हाइटलिस्ट करने के लिए नॉन्स (क्रिप्टोग्राफ़िक रूप से रैंडम, एकल-उपयोग टोकन) का उपयोग करें। यह '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: इनलाइन स्टाइल्स के लिए हैश का उपयोग करना

नॉन्स के समान, हैश का उपयोग विशिष्ट इनलाइन <style> ब्लॉक को व्हाइटलिस्ट करने के लिए किया जा सकता है। यह स्टाइल सामग्री का 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 हेडर एक या अधिक रिपोर्टिंग समूहों को परिभाषित करता है, जो यह निर्दिष्ट करते हैं कि रिपोर्ट कहाँ और कैसे भेजी जानी चाहिए।

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

              
                Copy
              
            
          

CSP का परीक्षण और परिनियोजन

CSP को लागू करने के लिए सावधानीपूर्वक योजना और परीक्षण की आवश्यकता होती है। एक प्रतिबंधात्मक पॉलिसी से शुरू करें और आवश्यकतानुसार धीरे-धीरे इसे ढीला करें। संसाधनों को ब्लॉक किए बिना अपनी पॉलिसी का परीक्षण करने के लिए Content-Security-Policy-Report-Only हेडर का उपयोग करें। यह हेडर पॉलिसी को लागू किए बिना उल्लंघनों की रिपोर्ट करता है, जिससे आप उत्पादन में पॉलिसी को तैनात करने से पहले समस्याओं की पहचान और उन्हें ठीक कर सकते हैं।

            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 निर्देश का उपयोग करें।
• पूरी तरह से परीक्षण करें: उत्पादन में अपनी पॉलिसी को तैनात करने से पहले उसका परीक्षण करने के लिए Content-Security-Policy-Report-Only हेडर का उपयोग करें।
• पुनरावृति और सुधार करें: CSP एक बार का कॉन्फ़िगरेशन नहीं है। अपने एप्लिकेशन और खतरे के परिदृश्य में परिवर्तनों के अनुकूल होने के लिए अपनी पॉलिसी की लगातार निगरानी और सुधार करें।

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

क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) एक तंत्र है जो एक ऑरिजिन (डोमेन) से वेब पेजों को एक अलग ऑरिजिन से संसाधनों तक पहुंचने की अनुमति देता है। डिफ़ॉल्ट रूप से, ब्राउज़र एक समान-ऑरिजिन नीति (Same-Origin Policy) लागू करते हैं, जो स्क्रिप्ट्स को उस ऑरिजिन से भिन्न ऑरिजिन पर अनुरोध करने से रोकती है जहाँ से स्क्रिप्ट उत्पन्न हुई है। CORS इस प्रतिबंध को चुनिंदा रूप से शिथिल करने का एक तरीका प्रदान करता है, जिससे दुर्भावनापूर्ण हमलों से बचाव करते हुए वैध क्रॉस-ऑरिजिन अनुरोधों की अनुमति मिलती है।

समान-ऑरिजिन नीति को समझना

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

उदाहरण के लिए:

• https://www.example.com/app1/index.html और https://www.example.com/app2/index.html का ऑरिजिन समान है।
• https://www.example.com/index.html और http://www.example.com/index.html के ऑरिजिन भिन्न हैं (भिन्न स्कीम)।
• https://www.example.com/index.html और https://sub.example.com/index.html के ऑरिजिन भिन्न हैं (भिन्न होस्ट)।
• https://www.example.com:8080/index.html और https://www.example.com:80/index.html के ऑरिजिन भिन्न हैं (भिन्न पोर्ट)।

CORS कैसे काम करता है

जब कोई वेब पेज क्रॉस-ऑरिजिन अनुरोध करता है, तो ब्राउज़र पहले सर्वर को एक "प्रीफ़्लाइट" अनुरोध भेजता है। प्रीफ़्लाइट अनुरोध HTTP OPTIONS विधि का उपयोग करता है और इसमें हेडर शामिल होते हैं जो HTTP विधि और उन हेडर्स को इंगित करते हैं जिनका वास्तविक अनुरोध उपयोग करेगा। सर्वर तब उन हेडर्स के साथ प्रतिक्रिया देता है जो यह इंगित करते हैं कि क्रॉस-ऑरिजिन अनुरोध की अनुमति है या नहीं।

यदि सर्वर अनुरोध की अनुमति देता है, तो वह प्रतिक्रिया में Access-Control-Allow-Origin हेडर शामिल करता है। यह हेडर उन ऑरिजिन(ओं) को निर्दिष्ट करता है जिन्हें संसाधन तक पहुंचने की अनुमति है। ब्राउज़र तब वास्तविक अनुरोध के साथ आगे बढ़ता है। यदि सर्वर अनुरोध की अनुमति नहीं देता है, तो वह Access-Control-Allow-Origin हेडर शामिल नहीं करता है, और ब्राउज़र अनुरोध को ब्लॉक कर देता है।

CORS हेडर्स: एक विस्तृत नज़र

CORS ब्राउज़र और सर्वर के बीच संवाद करने के लिए HTTP हेडर पर निर्भर करता है। यहाँ प्रमुख CORS हेडर दिए गए हैं:

• Access-Control-Allow-Origin: उन ऑरिजिन(ओं) को निर्दिष्ट करता है जिन्हें संसाधन तक पहुंचने की अनुमति है। इस हेडर में एक विशिष्ट ऑरिजिन (जैसे, https://www.example.com), एक वाइल्डकार्ड (*), या null हो सकता है। * का उपयोग करने से किसी भी ऑरिजिन से अनुरोधों की अनुमति मिलती है, जो आम तौर पर सुरक्षा कारणों से अनुशंसित नहीं है। `null` का उपयोग केवल "अपारदर्शी प्रतिक्रियाओं" के लिए उपयुक्त है जैसे कि जब संसाधन `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: उस अधिकतम समय (सेकंड में) को निर्दिष्ट करता है जिसके लिए ब्राउज़र प्रीफ़्लाइट अनुरोध को कैश कर सकता है।
• Origin: यह एक अनुरोध हेडर है जो ब्राउज़र द्वारा अनुरोध के ऑरिजिन को इंगित करने के लिए भेजा जाता है।
• Vary: एक सामान्य HTTP हेडर, लेकिन CORS के लिए महत्वपूर्ण है। जब `Access-Control-Allow-Origin` गतिशील रूप से उत्पन्न होता है, तो `Vary: Origin` हेडर को प्रतिक्रिया में शामिल किया जाना चाहिए ताकि कैशिंग तंत्र को यह निर्देश दिया जा सके कि प्रतिक्रिया `Origin` अनुरोध हेडर के आधार पर भिन्न होती है।

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

आइए CORS कॉन्फ़िगरेशन के कुछ व्यावहारिक उदाहरण देखें:

उदाहरण 1: एक विशिष्ट ऑरिजिन से अनुरोधों की अनुमति देना

यह कॉन्फ़िगरेशन केवल https://www.example.com से अनुरोधों की अनुमति देता है:

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

              
                Copy
              
            
          

उदाहरण 2: किसी भी ऑरिजिन से अनुरोधों की अनुमति देना (अनुशंसित नहीं)

यह कॉन्फ़िगरेशन किसी भी ऑरिजिन से अनुरोधों की अनुमति देता है। सावधानी से प्रयोग करें क्योंकि यह सुरक्षा जोखिम पैदा कर सकता है:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

उदाहरण 3: विशिष्ट विधियों और हेडर्स की अनुमति देना

यह कॉन्फ़िगरेशन GET, POST, और PUT विधियों, और Content-Type और Authorization हेडर की अनुमति देता है:

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

              
                Copy
              
            
          

उदाहरण 4: क्रेडेंशियल्स की अनुमति देना

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

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

              
                Copy
              
            
          

आपको अपने JavaScript fetch/XMLHttpRequest अनुरोध में credentials: 'include' भी सेट करना होगा।

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

              
                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
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

प्रीफ़्लाइट प्रतिक्रिया (200 OK):

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

              
                Copy
              
            
          

Access-Control-Max-Age हेडर यह निर्दिष्ट करता है कि ब्राउज़र प्रीफ़्लाइट प्रतिक्रिया को कितने समय तक कैश कर सकता है, जिससे प्रीफ़्लाइट अनुरोधों की संख्या कम हो जाती है।

CORS और JSONP

JSON with Padding (JSONP) समान-ऑरिजिन नीति को दरकिनार करने की एक पुरानी तकनीक है। हालांकि, JSONP में महत्वपूर्ण सुरक्षा जोखिम हैं और CORS के पक्ष में इससे बचा जाना चाहिए। JSONP पेज में <script> टैग इंजेक्ट करने पर निर्भर करता है, जो मनमाना कोड निष्पादित कर सकता है। CORS क्रॉस-ऑरिजिन अनुरोधों को संभालने का एक अधिक सुरक्षित और लचीला तरीका प्रदान करता है।

CORS के लिए सर्वोत्तम अभ्यास

• * का उपयोग करने से बचें: Access-Control-Allow-Origin हेडर में वाइल्डकार्ड (*) का उपयोग करने से बचें, क्योंकि यह किसी भी ऑरिजिन से अनुरोधों की अनुमति देता है। इसके बजाय, उन विशिष्ट ऑरिजिन(ओं) को निर्दिष्ट करें जिन्हें संसाधन तक पहुंचने की अनुमति है।
• विधियों और हेडर्स के साथ विशिष्ट रहें: 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 को मिलाकर, आप अपने वेब एप्लिकेशन के लिए एक अधिक मजबूत सुरक्षा मुद्रा बना सकते हैं। उदाहरण के लिए, आप उन स्रोतों को प्रतिबंधित करने के लिए CSP का उपयोग कर सकते हैं जिनसे स्क्रिप्ट लोड की जा सकती हैं, और यह नियंत्रित करने के लिए CORS का उपयोग कर सकते हैं कि कौन से ऑरिजिन आपके API एंडपॉइंट्स तक पहुंच सकते हैं।

उदाहरण: 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
Content-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 हमलों, डेटा इंजेक्शन हमलों और अन्य सुरक्षा कमजोरियों के जोखिम को काफी कम कर सकते हैं। एक प्रतिबंधात्मक पॉलिसी से शुरू करना, पूरी तरह से परीक्षण करना, और अपने एप्लिकेशन और विकसित हो रहे खतरे के परिदृश्य में परिवर्तनों के अनुकूल होने के लिए अपने कॉन्फ़िगरेशन की लगातार निगरानी और सुधार करना याद रखें। फ़्रंटएंड सुरक्षा को प्राथमिकता देकर, आप अपने उपयोगकर्ताओं की रक्षा कर सकते हैं और आज की तेजी से जटिल होती डिजिटल दुनिया में अपने वेब एप्लिकेशन की अखंडता सुनिश्चित कर सकते हैं।