फ्रंटएंड सुरक्षा हेडर: कंटेंट सिक्योरिटी पॉलिसी (CSP) में महारत हासिल करना

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

फ्रंटएंड सुरक्षा हेडर क्या हैं?

फ्रंटएंड सुरक्षा हेडर HTTP प्रतिक्रिया हेडर होते हैं जो एक वेब सर्वर ब्राउज़र को भेजता है। इन हेडरों में निर्देश होते हैं कि ब्राउज़र को प्राप्त सामग्री को कैसे संभालना चाहिए। वे आम हमलों को रोकने में मदद करते हैं जैसे:

• क्रॉस-साइट स्क्रिप्टिंग (XSS): विश्वसनीय वेबसाइटों में दुर्भावनापूर्ण स्क्रिप्ट इंजेक्ट करना।
• क्लिकजैकिंग: उपयोगकर्ताओं को उस चीज़ से अलग कुछ क्लिक करने के लिए धोखा देना जो वे समझते हैं।
• मैन-इन-द-मिडिल अटैक: उपयोगकर्ता और सर्वर के बीच संचार का अवरोधन।

कुछ सबसे महत्वपूर्ण फ्रंटएंड सुरक्षा हेडरों में शामिल हैं:

• कंटेंट सिक्योरिटी पॉलिसी (CSP): उन स्रोतों को परिभाषित करता है जहां से ब्राउज़र को संसाधनों को लोड करने की अनुमति है।
• स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी (HSTS): ब्राउज़र को वेबसाइट के साथ सभी संचार के लिए HTTPS का उपयोग करने के लिए मजबूर करता है।
• एक्स-फ्रेम-ऑप्शंस: वेबसाइट को एक iframe में एम्बेड होने से रोकता है, जिससे क्लिकजैकिंग हमलों को कम किया जा सकता है।
• एक्स-एक्सएसएस-प्रोटेक्शन: ब्राउज़र के अंतर्निहित XSS फ़िल्टर को सक्षम करता है। (नोट: अक्सर CSP द्वारा प्रतिस्थापित किया जाता है लेकिन फिर भी रक्षा की एक परत प्रदान कर सकता है)।
• रेफ़रर-पॉलिसी: अनुरोधों के साथ भेजी जाने वाली रेफ़रर जानकारी की मात्रा को नियंत्रित करता है।
• फीचर-पॉलिसी (अब परमिशन्स-पॉलिसी): डेवलपर्स को चुनिंदा रूप से ब्राउज़र सुविधाओं और API को सक्षम और अक्षम करने की अनुमति देता है।

कंटेंट सिक्योरिटी पॉलिसी (CSP) का गहन विश्लेषण

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

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

CSP विभिन्न प्रकार की सामग्री के लिए स्वीकृत स्रोतों की एक सूची ब्राउज़र को प्रदान करके काम करता है। जब ब्राउज़र को कोई ऐसा संसाधन मिलता है जो CSP का उल्लंघन करता है, तो वह संसाधन को ब्लॉक कर देता है और उल्लंघन की रिपोर्ट करता है। यह अवरोधन तंत्र दुर्भावनापूर्ण कोड को निष्पादित होने से रोकता है, भले ही कोई हमलावर इसे HTML में इंजेक्ट करने में कामयाब हो जाए।

CSP निर्देश

CSP निर्देश एक CSP नीति के मुख्य घटक हैं। वे विभिन्न प्रकार के संसाधनों के लिए अनुमत स्रोतों को निर्दिष्ट करते हैं। कुछ सबसे अधिक उपयोग किए जाने वाले निर्देशों में शामिल हैं:

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

CSP स्रोत मान

स्रोत मान उन मूलों को परिभाषित करते हैं जहां से संसाधनों को लोड करने की अनुमति है। कुछ सामान्य स्रोत मानों में शामिल हैं:

• *: किसी भी स्रोत से सामग्री की अनुमति देता है (उत्पादन में इसका उपयोग करने से बचें!)।
• 'self': संरक्षित दस्तावेज़ के समान मूल (स्कीम, होस्ट और पोर्ट) से सामग्री की अनुमति देता है।
• 'none': किसी भी स्रोत से सामग्री को अस्वीकार करता है।
• 'unsafe-inline': इनलाइन जावास्क्रिप्ट और CSS के उपयोग की अनुमति देता है (उत्पादन में इसका उपयोग करने से बचें!)।
• 'unsafe-eval': गतिशील कोड मूल्यांकन के उपयोग की अनुमति देता है (जैसे, eval(), Function()) (उत्पादन में इसका उपयोग करने से बचें!)।
• 'strict-dynamic': यह निर्दिष्ट करता है कि मार्कअप में मौजूद एक स्क्रिप्ट को स्पष्ट रूप से दिया गया विश्वास, एक नॉन्स या हैश के साथ, उस पूर्वज द्वारा लोड की गई सभी स्क्रिप्ट में प्रचारित किया जाएगा।
• 'unsafe-hashes': विशिष्ट इनलाइन ईवेंट हैंडलर की अनुमति देता है। इसकी जटिलता और सीमित लाभ के कारण इसे आम तौर पर हतोत्साहित किया जाता है।
• data:: डेटा URL (जैसे, एम्बेडेड छवियां) से संसाधनों को लोड करने की अनुमति देता है। सावधानी से प्रयोग करें।
• mediastream:: `mediastream:` URIs को मीडिया स्रोत के रूप में उपयोग करने की अनुमति देता है।
• blob:: `blob:` URIs को मीडिया स्रोत के रूप में उपयोग करने की अनुमति देता है।
• filesystem:: संसाधनों को एक फाइल सिस्टम से लोड करने की अनुमति देता है।
• https://example.com: एक विशिष्ट डोमेन और पोर्ट से सामग्री की अनुमति देता है।
• *.example.com: example.com के किसी भी सबडोमेन से सामग्री की अनुमति देता है।
• nonce-{random-value}: मेल खाने वाले नॉन्स एट्रिब्यूट के साथ स्क्रिप्ट या स्टाइल की अनुमति देता है। इसके लिए प्रत्येक अनुरोध के लिए सर्वर-साइड पर एक यादृच्छिक नॉन्स मान उत्पन्न करने की आवश्यकता होती है।
• sha256-{hash-value}: मेल खाने वाले SHA256, SHA384, या SHA512 हैश के साथ स्क्रिप्ट या स्टाइल की अनुमति देता है।

CSP मोड: एनफोर्स बनाम रिपोर्ट-ओनली

CSP को दो मोड में तैनात किया जा सकता है:

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

CSP लागू करना: एक चरण-दर-चरण मार्गदर्शिका

CSP लागू करना कठिन लग सकता है, लेकिन एक संरचित दृष्टिकोण का पालन करके, आप अपने वेब एप्लिकेशन को प्रभावी ढंग से सुरक्षित कर सकते हैं।

1. रिपोर्ट-ओनली पॉलिसी से शुरुआत करें

रिपोर्ट-ओनली मोड में CSP को तैनात करके शुरुआत करें। यह आपको अपनी वेबसाइट की कार्यक्षमता को बाधित किए बिना उल्लंघनों की निगरानी करने की अनुमति देता है। उल्लंघन रिपोर्ट को एक निर्दिष्ट एंडपॉइंट पर भेजने के लिए report-uri या report-to निर्देश को कॉन्फ़िगर करें।

उदाहरण हेडर (रिपोर्ट-ओनली): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. उल्लंघन रिपोर्ट का विश्लेषण करें

यह पहचानने के लिए उल्लंघन रिपोर्ट का सावधानीपूर्वक विश्लेषण करें कि कौन से संसाधन अवरुद्ध हो रहे हैं और क्यों। यह आपको अपनी वेबसाइट के संसाधन निर्भरता को समझने और संभावित सुरक्षा कमजोरियों की पहचान करने में मदद करेगा।

उल्लंघन रिपोर्ट आमतौर पर JSON पेलोड के रूप में कॉन्फ़िगर किए गए report-uri या report-to एंडपॉइंट पर भेजी जाती हैं। इन रिपोर्टों में उल्लंघन के बारे में जानकारी होती है, जैसे कि अवरुद्ध URI, उल्लंघन किया गया निर्देश, और दस्तावेज़ URI।

3. CSP नीति को परिष्कृत करें

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

4. एनफोर्स मोड में संक्रमण

एक बार जब आप आश्वस्त हो जाएं कि आपकी CSP नीति वैध संसाधनों को अवरुद्ध नहीं कर रही है, तो एनफोर्स मोड में संक्रमण करें। यह किसी भी शेष उल्लंघन को अवरुद्ध करेगा और XSS हमलों के खिलाफ सुरक्षा की एक मजबूत परत प्रदान करेगा।

उदाहरण हेडर (एनफोर्स): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. CSP नीति की निगरानी और रखरखाव करें

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

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

आइए विभिन्न परिदृश्यों के लिए कुछ व्यावहारिक CSP उदाहरण देखें:

उदाहरण 1: एक साधारण वेबसाइट के लिए मूल CSP

यह CSP एक ही मूल से सामग्री की अनुमति देता है और किसी भी स्रोत से छवियों की अनुमति देता है।

Content-Security-Policy: default-src 'self'; img-src *

उदाहरण 2: विशिष्ट स्क्रिप्ट और स्टाइल स्रोतों के साथ CSP

यह CSP एक ही मूल से और एक विशिष्ट CDN से स्क्रिप्ट की अनुमति देता है, और एक ही मूल से और इनलाइन स्टाइल की अनुमति देता है।

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

उदाहरण 3: इनलाइन स्क्रिप्ट के लिए नॉन्स के साथ CSP

इस CSP को प्रत्येक इनलाइन स्क्रिप्ट के लिए एक अद्वितीय नॉन्स की आवश्यकता होती है।

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

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

महत्वपूर्ण: नॉन्स मान को प्रत्येक अनुरोध के लिए सर्वर पर गतिशील रूप से उत्पन्न किया जाना चाहिए। यह हमलावरों को नॉन्स का पुन: उपयोग करने से रोकता है।

उदाहरण 4: क्लिकजैकिंग को रोकने के लिए फ्रेम पूर्वजों को प्रतिबंधित करने वाला CSP

यह CSP `https://example.com` को छोड़कर किसी भी डोमेन पर पेज को iframe में एम्बेड होने से रोकता है।

Content-Security-Policy: frame-ancestors 'self' https://example.com

उदाहरण 5: 'strict-dynamic' और 'self' के लिए एक फ़ॉलबैक का उपयोग करके एक अधिक प्रतिबंधात्मक CSP

यह CSP आधुनिक ब्राउज़रों के लिए `strict-dynamic` का लाभ उठाता है, जबकि अभी भी पुराने ब्राउज़रों का समर्थन करता है जो इसका समर्थन नहीं करते हैं। इसमें उल्लंघनों की निगरानी के लिए एक `report-uri` भी शामिल है।

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

सर्वर साइड पर `{random-nonce}` को गतिशील रूप से उत्पन्न नॉन्स मान से बदलना याद रखें।

CSP और सिंगल-पेज एप्लिकेशन (SPAs)

SPAs में CSP लागू करना इन अनुप्रयोगों की गतिशील प्रकृति के कारण चुनौतीपूर्ण हो सकता है। SPAs अक्सर DOM को उत्पन्न और हेरफेर करने के लिए जावास्क्रिप्ट पर बहुत अधिक निर्भर करते हैं, जिससे CSP उल्लंघन हो सकते हैं यदि सावधानी से नियंत्रित नहीं किया जाता है।

SPAs में CSP लागू करने के लिए यहां कुछ सुझाव दिए गए हैं:

• 'unsafe-inline' और 'unsafe-eval' से बचें: इन निर्देशों से जब भी संभव हो SPAs में बचना चाहिए। वे आपके एप्लिकेशन की सुरक्षा को काफी कमजोर करते हैं।
• नॉन्स या हैश का उपयोग करें: इनलाइन स्क्रिप्ट और स्टाइल के लिए नॉन्स या हैश का उपयोग करें। यह SPAs के लिए अनुशंसित दृष्टिकोण है।
• विश्वसनीय प्रकारों पर विचार करें: विश्वसनीय प्रकार एक ब्राउज़र API है जो DOM-आधारित XSS कमजोरियों को रोकने में मदद करता है। इसका उपयोग सुरक्षा को और बढ़ाने के लिए CSP के साथ किया जा सकता है।
• CSP-संगत ढांचे का उपयोग करें: कुछ फ्रंटएंड ढांचे (जैसे विशिष्ट कॉन्फ़िगरेशन के साथ रिएक्ट, एंगुलर और Vue.js) आपको CSP को अधिक आसानी से लागू करने में मदद करने के लिए सुविधाएँ प्रदान करते हैं।

अन्य महत्वपूर्ण फ्रंटएंड सुरक्षा हेडर

जबकि CSP फ्रंटएंड सुरक्षा की आधारशिला है, अन्य हेडर एक व्यापक रक्षा रणनीति प्रदान करने में महत्वपूर्ण भूमिका निभाते हैं:

स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी (HSTS)

Strict-Transport-Security (HSTS) हेडर ब्राउज़र को वेबसाइट से कनेक्ट करने के लिए हमेशा HTTPS का उपयोग करने का निर्देश देता है। यह मैन-इन-द-मिडिल हमलों को रोकता है जो कनेक्शन को HTTP में डाउनग्रेड करने का प्रयास करते हैं।

उदाहरण हेडर: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: उस अवधि (सेकंड में) को निर्दिष्ट करता है जिसके लिए ब्राउज़र को केवल HTTPS के माध्यम से साइट तक पहुंचने के लिए याद रखना चाहिए। उत्पादन वातावरण के लिए 31536000 सेकंड (1 वर्ष) का मान अनुशंसित है।
• includeSubDomains: इंगित करता है कि HSTS नीति डोमेन के सभी सबडोमेन पर लागू होती है।
• preload: डोमेन को HSTS-सक्षम डोमेन की सूची में शामिल करने की अनुमति देता है जो ब्राउज़रों में प्रीलोड होता है। इसके लिए आपको अपने डोमेन को Google द्वारा बनाए रखी गई HSTS प्रीलोड सूची में सबमिट करना होगा।

एक्स-फ्रेम-ऑप्शंस

X-Frame-Options हेडर यह नियंत्रित करके क्लिकजैकिंग हमलों को रोकता है कि क्या वेबसाइट को iframe में एम्बेड किया जा सकता है।

उदाहरण हेडर: X-Frame-Options: DENY

संभावित मान:

• DENY: पृष्ठ को iframe में प्रदर्शित होने से रोकता है, चाहे मूल कुछ भी हो।
• SAMEORIGIN: पृष्ठ को iframe में केवल तभी प्रदर्शित करने की अनुमति देता है जब iframe का मूल पृष्ठ के मूल से मेल खाता हो।
• ALLOW-FROM uri: पृष्ठ को iframe में केवल तभी प्रदर्शित करने की अनुमति देता है जब iframe का मूल निर्दिष्ट URI से मेल खाता हो। नोट: यह विकल्प पदावनत है और सभी ब्राउज़रों द्वारा समर्थित नहीं हो सकता है।

नोट: CSP में frame-ancestors निर्देश फ्रेमिंग को नियंत्रित करने का एक अधिक लचीला और शक्तिशाली तरीका प्रदान करता है और आम तौर पर X-Frame-Options पर इसे प्राथमिकता दी जाती है।

एक्स-एक्सएसएस-प्रोटेक्शन

X-XSS-Protection हेडर ब्राउज़र के अंतर्निहित XSS फ़िल्टर को सक्षम करता है। जबकि CSP XSS हमलों को रोकने के लिए एक अधिक मजबूत समाधान है, यह हेडर रक्षा की एक अतिरिक्त परत प्रदान कर सकता है, खासकर पुराने ब्राउज़रों के लिए जो पूरी तरह से CSP का समर्थन नहीं कर सकते हैं।

उदाहरण हेडर: X-XSS-Protection: 1; mode=block

• 1: XSS फ़िल्टर को सक्षम करता है।
• 0: XSS फ़िल्टर को अक्षम करता है।
• mode=block: यदि XSS हमले का पता चलता है तो ब्राउज़र को पृष्ठ को ब्लॉक करने का निर्देश देता है।
• report=uri: एक URL निर्दिष्ट करता है जिस पर ब्राउज़र को रिपोर्ट भेजनी चाहिए यदि XSS हमले का पता चलता है।

रेफ़रर-पॉलिसी

Referrer-Policy हेडर अनुरोधों के साथ भेजी जाने वाली रेफ़रर जानकारी की मात्रा को नियंत्रित करता है। रेफ़रर जानकारी का उपयोग वेबसाइटों पर उपयोगकर्ताओं को ट्रैक करने के लिए किया जा सकता है, इसलिए इसे नियंत्रित करने से उपयोगकर्ता की गोपनीयता में सुधार हो सकता है।

उदाहरण हेडर: Referrer-Policy: strict-origin-when-cross-origin

कुछ सामान्य मान:

• no-referrer: कभी भी Referer हेडर न भेजें।
• no-referrer-when-downgrade: TLS (HTTPS) के बिना मूल को Referer हेडर न भेजें।
• origin: Referer हेडर में केवल मूल (स्कीम, होस्ट और पोर्ट) भेजें।
• origin-when-cross-origin: क्रॉस-ओरिजिन अनुरोधों के लिए मूल और समान-ओरिजिन अनुरोधों के लिए पूरा URL भेजें।
• same-origin: समान-ओरिजिन अनुरोधों के लिए Referer हेडर भेजें, लेकिन क्रॉस-ओरिजिन अनुरोधों के लिए नहीं।
• strict-origin: जब प्रोटोकॉल सुरक्षा स्तर समान रहता है (HTTPS से HTTPS) तो केवल मूल भेजें, लेकिन कम सुरक्षित गंतव्य (HTTPS से HTTP) पर कोई हेडर न भेजें।
• strict-origin-when-cross-origin: समान-ओरिजिन अनुरोध करते समय मूल भेजें। क्रॉस-ओरिजिन अनुरोधों के लिए, केवल तभी मूल भेजें जब प्रोटोकॉल सुरक्षा स्तर समान रहता है (HTTPS से HTTPS), लेकिन कम सुरक्षित गंतव्य (HTTPS से HTTP) पर कोई हेडर न भेजें।
• unsafe-url: Referer हेडर में पूरा URL भेजें, चाहे मूल कुछ भी हो। अत्यधिक सावधानी के साथ प्रयोग करें, क्योंकि यह संवेदनशील जानकारी को उजागर कर सकता है।

परमिशन्स-पॉलिसी (पूर्व में फीचर-पॉलिसी)

Permissions-Policy हेडर (जिसे पहले Feature-Policy के नाम से जाना जाता था) डेवलपर्स को चुनिंदा रूप से ब्राउज़र सुविधाओं और API को सक्षम और अक्षम करने की अनुमति देता है। यह आपके एप्लिकेशन के हमले की सतह को कम करने और उपयोगकर्ता की गोपनीयता में सुधार करने में मदद कर सकता है।

उदाहरण हेडर: Permissions-Policy: geolocation=()

यह उदाहरण वेबसाइट के लिए जियोलोकेशन API को अक्षम करता है।

अन्य सुविधाएँ जिन्हें Permissions-Policy से नियंत्रित किया जा सकता है उनमें शामिल हैं:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

विभिन्न प्लेटफार्मों पर सुरक्षा हेडर सेट करना

सुरक्षा हेडर सेट करने की विधि आपके द्वारा उपयोग किए जा रहे वेब सर्वर या प्लेटफॉर्म के आधार पर भिन्न होती है। यहां कुछ सामान्य उदाहरण दिए गए हैं:

अपाचे

आप अपाचे में सुरक्षा हेडर को .htaccess फ़ाइल या सर्वर कॉन्फ़िगरेशन फ़ाइल (httpd.conf) में जोड़कर सेट कर सकते हैं।

उदाहरण .htaccess कॉन्फ़िगरेशन:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

आप Nginx कॉन्फ़िगरेशन फ़ाइल (nginx.conf) में सर्वर ब्लॉक में सुरक्षा हेडर जोड़कर उन्हें Nginx में सेट कर सकते हैं।

उदाहरण Nginx कॉन्फ़िगरेशन:

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (एक्सप्रेस)

आप Node.js में हेलमेट जैसे मिडलवेयर का उपयोग करके सुरक्षा हेडर सेट कर सकते हैं।

हेलमेट का उपयोग करके उदाहरण:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Customize CSP if needed
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

क्लाउडफ्लेयर

क्लाउडफ्लेयर आपको उनके पेज रूल्स या ट्रांसफॉर्म रूल्स का उपयोग करके सुरक्षा हेडर सेट करने की अनुमति देता है।

अपने सुरक्षा हेडरों का परीक्षण करना

सुरक्षा हेडर लागू करने के बाद, यह सुनिश्चित करने के लिए उनका परीक्षण करना महत्वपूर्ण है कि वे सही ढंग से काम कर रहे हैं। कई ऑनलाइन टूल आपकी वेबसाइट के सुरक्षा हेडरों का विश्लेषण करने में आपकी सहायता कर सकते हैं:

• SecurityHeaders.com: सुरक्षा हेडरों का विश्लेषण करने के लिए एक सरल और प्रभावी उपकरण।
• Mozilla Observatory: सुरक्षा हेडरों सहित वेबसाइट सुरक्षा का परीक्षण करने के लिए एक व्यापक उपकरण।
• WebPageTest.org: आपको वॉटरफॉल चार्ट में HTTP हेडर देखने की अनुमति देता है।

निष्कर्ष

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

फ्रंटएंड सुरक्षा के प्रति एक सक्रिय दृष्टिकोण अपनाकर, आप अधिक सुरक्षित और भरोसेमंद वेब एप्लिकेशन बना सकते हैं जो आपके उपयोगकर्ताओं और आपके व्यवसाय की रक्षा करते हैं।