कॉन्टेंट की सुरक्षा के लिए नीति

कॉन्टेंट की सुरक्षा के बारे में नीति की मदद से, मॉडर्न ब्राउज़र में क्रॉस-साइट स्क्रिप्टिंग हमलों के जोखिम और उनके असर को काफ़ी कम किया जा सकता है.

वेब का सुरक्षा मॉडल, एक ही ऑरिजिन से जुड़ी नीति पर आधारित होता है. उदाहरण के लिए, https://mybank.com के कोड के पास सिर्फ़ https://mybank.com के डेटा का ऐक्सेस होना चाहिए. साथ ही, https://evil.example.com को कभी भी ऐक्सेस करने की अनुमति नहीं होनी चाहिए. सैद्धांतिक तौर पर, हर ऑरिजिन को बाकी वेब से अलग रखा जाता है, जिससे डेवलपर को एक सुरक्षित सैंडबॉक्स बनाने में मदद मिलती है. हालांकि, असल में हमलावरों ने सिस्टम को बंद करने के कई तरीके ढूंढे हैं.

क्रॉस-साइट स्क्रिप्टिंग (XSS) जैसे हमले. उदाहरण के लिए, एक ही ऑरिजिन वाली नीति को बायपास करने के लिए, किसी साइट को धोखे से नुकसान पहुंचाने वाले कोड के साथ सही कॉन्टेंट पहुंचाने की कोशिश करते हैं. यह एक बहुत बड़ी समस्या है, क्योंकि ब्राउज़र, पेज पर दिखने वाले सभी कोड पर भरोसा करते हैं. वे यह मानते हैं कि पेज के सुरक्षा मूल का कानूनी हिस्सा होना चाहिए. XSS चीट शीट, उन तरीकों का एक पुराना, लेकिन प्रतिनिधि सेक्शन है जिनका इस्तेमाल करके, हमलावर नुकसान पहुंचाने वाले कोड इंजेक्ट करके, इस भरोसे का उल्लंघन कर सकता है. अगर कोई हमलावर कोई भी कोड इंजेक्ट करता है, तो इसका मतलब है कि उसने उपयोगकर्ता सेशन के साथ छेड़छाड़ की है और निजी जानकारी का ऐक्सेस हासिल कर लिया है.

इस पेज पर, कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी) के बारे में बताया गया है. इसका मकसद, मॉडर्न ब्राउज़र में XSS हमलों के जोखिम और असर को कम करना है.

सीएसपी के कॉम्पोनेंट

एक असरदार सीएसपी लागू करने के लिए, यह तरीका अपनाएं:

• अनुमति वाली सूची का इस्तेमाल करके, क्लाइंट को बताएं कि कौनसा कॉन्टेंट दिखाया जा सकता है और कौनसा नहीं.
• जानें कि कौनसे डायरेक्टिव उपलब्ध हैं.
• उनके द्वारा चुने गए कीवर्ड के बारे में जानें.
• इनलाइन कोड और eval() का इस्तेमाल सीमित करें.
• नीति के उल्लंघनों को लागू करने से पहले अपने सर्वर से उनकी शिकायत करें.

स्रोत की अनुमति वाली सूची

XSS हमले, ब्राउज़र की ऐसी स्क्रिप्ट के बीच अंतर करने की क्षमता का शोषण करते हैं, जो आपके ऐप्लिकेशन और स्क्रिप्ट का हिस्सा है, जिसे किसी तीसरे पक्ष ने नुकसान पहुंचाने के मकसद से डाला है. उदाहरण के लिए, इस पेज में सबसे नीचे मौजूद Google +1 बटन लोड होता है और इस पेज के मूल संदर्भ में https://apis.google.com/js/plusone.js से कोड को एक्ज़ीक्यूट करता है. हमें उस कोड पर भरोसा है, लेकिन हम यह उम्मीद नहीं कर सकते कि ब्राउज़र खुद से यह पता लगाए कि apis.google.com से मिला कोड सुरक्षित है, जबकि apis.evil.example.com से मिला कोड सुरक्षित नहीं है. ब्राउज़र, पेज के अनुरोध वाले सभी कोड को आसानी से डाउनलोड और लागू करता है. भले ही, उनका सोर्स कोई भी हो.

सीएसपी के Content-Security-Policy एचटीटीपी हेडर की मदद से, भरोसेमंद कॉन्टेंट के सोर्स की अनुमति वाली सूची बनाई जा सकती है. साथ ही, ब्राउज़र को सिर्फ़ उन सोर्स के रिसॉर्स को चलाने या रेंडर करने के लिए कहा जाता है. भले ही, कोई हमलावर उस स्क्रिप्ट को इंजेक्ट करने के लिए छेद कर ले, फिर भी स्क्रिप्ट को अनुमति वाले डोमेन की सूची में शामिल नहीं किया जाएगा. इसलिए, उसे लागू नहीं किया जाएगा.

हमें apis.google.com पर भरोसा है कि मान्य कोड दिया जाएगा और ऐसा करने के लिए हम खुद पर भी भरोसा करते हैं. यहां एक नीति के उदाहरण दिए गए हैं, जो स्क्रिप्ट को सिर्फ़ तब काम करने की अनुमति देती है, जब वे उन दोनों में से किसी एक सोर्स से आती हैं:

Content-Security-Policy: script-src 'self' https://apis.google.com

script-src एक ऐसा डायरेक्टिव है जो किसी पेज के लिए, स्क्रिप्ट से जुड़े खास अधिकारों के सेट को कंट्रोल करता है. यह हेडर, स्क्रिप्ट के एक मान्य सोर्स के तौर पर 'self' और दूसरे https://apis.google.com हेडर के तौर पर है. ब्राउज़र अब एचटीटीपीएस पर apis.google.com से JavaScript को डाउनलोड और एक्ज़ीक्यूट कर सकता है. इसके अलावा, यह मौजूदा पेज के ऑरिजिन से भी JavaScript को डाउनलोड और एक्ज़ीक्यूट कर सकता है, लेकिन किसी दूसरे ऑरिजिन से नहीं. अगर कोई हमलावर आपकी साइट में कोड इंजेक्ट करता है, तो ब्राउज़र को गड़बड़ी का मैसेज दिखता है और इंजेक्ट की गई स्क्रिप्ट नहीं चलती.

यह नीति कई तरह के संसाधनों पर लागू होती है

सीएसपी, नीति से जुड़े डायरेक्टिव का एक सेट देता है, जो पेज को लोड किए जा सकने वाले संसाधनों पर पूरा कंट्रोल देता है. इनमें, पिछले उदाहरण में दिए गए script-src भी शामिल हैं.

नीचे दी गई सूची में, लेवल 2 से जुड़े बाकी रिसॉर्स डायरेक्टिव के बारे में बताया गया है. लेवल 3 स्पेसिफ़िकेशन को ड्राफ़्ट किया गया है, लेकिन मुख्य ब्राउज़र में इसे काफ़ी हद तक लागू नहीं किया गया है.

base-uri

उन यूआरएल पर पाबंदी लगाती है जो पेज के <base> एलिमेंट में दिख सकते हैं.

child-src

कर्मचारियों और एम्बेड किए गए फ़्रेम के कॉन्टेंट के यूआरएल की सूची बनाता है. उदाहरण के लिए, child-src https://youtube.com, YouTube से वीडियो एम्बेड करने की सुविधा देता है, लेकिन दूसरे ऑरिजिन से नहीं.

connect-src

यह उन ऑरिजिन को सीमित करता है जिन्हें XHR, WebSockets, और EventSource का इस्तेमाल करके कनेक्ट किया जा सकता है.

font-src

यह उन ऑरिजिन के बारे में बताता है जो वेब फ़ॉन्ट दिखा सकते हैं. उदाहरण के लिए, font-src https://themes.googleusercontent.com का इस्तेमाल करके, Google के वेब फ़ॉन्ट को अनुमति दी जा सकती है.

form-action

<form> टैग से सबमिट करने के लिए, मान्य एंडपॉइंट की सूची देता है.

frame-ancestors

उन सोर्स के बारे में बताता है जो मौजूदा पेज को एम्बेड कर सकते हैं. यह डायरेक्टिव <frame>, <iframe>, <embed>, और <applet> टैग पर लागू होता है. इसका इस्तेमाल <meta> टैग या एचटीएमएल रिसॉर्स के लिए नहीं किया जा सकता.

frame-src

लेवल 2 में इस डायरेक्टिव के इस्तेमाल पर रोक लगा दी गई थी, लेकिन लेवल 3 में इसे पहले जैसा कर दिया गया है. अगर यह मौजूद नहीं है, तो ब्राउज़र वापस child-src में चला जाता है.

img-src

यह बताता है कि ऑरिजिन से किन इमेज को लोड किया जा सकता है.

media-src

वीडियो और ऑडियो डिलीवर करने की अनुमति वाले ऑरिजिन को प्रतिबंधित करता है.

object-src

इससे Flash और अन्य प्लग इन पर नियंत्रण मिलता है.

plugin-types

यह तय करती है कि पेज किस तरह के प्लग इन शुरू कर सकता है.

report-uri

यह उस यूआरएल के बारे में बताता है जिस पर ब्राउज़र कॉन्टेंट की सुरक्षा नीति का उल्लंघन होने पर रिपोर्ट भेजता है. यह डायरेक्टिव, <meta> टैग में इस्तेमाल नहीं किया जा सकता.

style-src

यह उन ऑरिजिन को सीमित करता है जिनसे स्टाइलशीट का इस्तेमाल, पेज कर सकता है.

upgrade-insecure-requests

एचटीटीपी को एचटीटीपीएस में बदलकर, उपयोगकर्ता एजेंट को यूआरएल स्कीम फिर से लिखने का निर्देश देता है. यह निर्देश उन वेबसाइटों के लिए है जिनमें बड़ी संख्या में पुराने यूआरएल हैं और जिन्हें दोबारा लिखने की ज़रूरत है.

worker-src

सीएसपी लेवल 3 का डायरेक्टिव, जो उन यूआरएल पर पाबंदी लगाता है जिन्हें वर्कर, शेयर वर्कर या सर्विस वर्कर के तौर पर लोड किया जा सकता है. जुलाई 2017 से, इस डायरेक्टिव को सीमित तौर पर लागू किया जा सकता है.

डिफ़ॉल्ट रूप से, ब्राउज़र किसी भी ऑरिजिन से संबंधित संसाधन को तब तक लोड करता है, जब तक कि आप किसी खास निर्देश वाली नीति सेट न कर दें. डिफ़ॉल्ट को बदलने के लिए, default-src डायरेक्टिव तय करें. यह डायरेक्टिव, -src से खत्म होने वाले किसी भी ऐसे डायरेक्टिव के लिए डिफ़ॉल्ट होता है जिसके बारे में जानकारी नहीं है. उदाहरण के लिए, अगर default-src को https://example.com पर सेट किया जाता है और font-src डायरेक्टिव नहीं दिया जाता है, तो सिर्फ़ https://example.com से फ़ॉन्ट लोड किए जा सकते हैं.

ये डायरेक्टिव, default-src का इस्तेमाल फ़ॉलबैक के तौर पर नहीं करते. याद रखें कि उन्हें सेट न कर पाना किसी भी चीज़ की अनुमति देने जैसा ही है:

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

बेसिक सीएसपी सिंटैक्स

सीएसपी डायरेक्टिव का इस्तेमाल करने के लिए, उन्हें कोलन से अलग किए गए डायरेक्टिव के साथ एचटीटीपी हेडर में डालें. पक्का करें कि किसी खास टाइप के सभी ज़रूरी संसाधनों को, एक ही डायरेक्टिव में इस तरह से शामिल किया गया हो:

script-src https://host1.com https://host2.com

नीचे एक से ज़्यादा डायरेक्टिव के उदाहरण दिए गए हैं. इस मामले में, ऐसे वेब ऐप्लिकेशन के लिए जो अपने सभी रिसॉर्स, https://cdn.example.net पर कॉन्टेंट डिलीवरी नेटवर्क से लोड करता है और फ़्रेम किए गए कॉन्टेंट या प्लगिन का इस्तेमाल नहीं करता है:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

क्रियान्वयन विवरण

आधुनिक ब्राउज़र में, बिना प्रीफ़िक्स वाले Content-Security-Policy हेडर का इस्तेमाल किया जा सकता है. हम आपको यही हेडर इस्तेमाल करने का सुझाव देते हैं. ऑनलाइन ट्यूटोरियल में शायद आपको दिखने वाले X-WebKit-CSP और X-Content-Security-Policy हेडर अब काम नहीं करते.

सीएसपी को हर पेज के हिसाब से तय किया जाता है. आपको हर उस रिस्पॉन्स के साथ एचटीटीपी हेडर भेजना होगा जिसे सुरक्षित रखना है. इससे कुछ पेजों की खास ज़रूरतों के हिसाब से, नीति में बदलाव किया जा सकता है. उदाहरण के लिए, अगर आपकी साइट पर, पेजों के एक सेट में +1 बटन है, जबकि दूसरे में नहीं है, तो ज़रूरी होने पर ही बटन कोड को लोड होने की अनुमति दी जा सकती है.

हर डायरेक्टिव की सोर्स सूची में बदलाव किया जा सकता है. आपके पास सोर्स को स्कीम (data:, https:) के हिसाब से या सिर्फ़ होस्टनेम (example.com, जो उस होस्ट के किसी भी ऑरिजिन: किसी भी स्कीम, किसी भी पोर्ट) से पूरी तरह क्वालिफ़ाइड यूआरआई (https://example.com:443, जो सिर्फ़ एचटीटीपीएस, सिर्फ़ example.com, और सिर्फ़ पोर्ट 443 से मेल खाता है) से मैच करता है. इस रेंज के आधार पर भी सोर्स तय किए जा सकते हैं. वाइल्डकार्ड को स्वीकार किया जाता है. हालांकि, यह सिर्फ़ स्कीम, पोर्ट या होस्टनेम की बाईं ओर वाले हिस्से में होगा: *://*.example.com:* किसी भी पोर्ट पर, किसी भी स्कीम का इस्तेमाल करके, example.com के सभी सबडोमेन से मेल खाएगा (लेकिन example.com से नहीं).

सोर्स सूची में चार कीवर्ड भी स्वीकार किए जाते हैं:

• 'none' कुछ भी मैच नहीं करता.
• 'self' मौजूदा ऑरिजिन से मैच करता है, लेकिन उसके सबडोमेन से नहीं.
• 'unsafe-inline' इनलाइन JavaScript और सीएसएस की अनुमति देता है. ज़्यादा जानकारी के लिए, इनलाइन कोड से बचें लेख देखें.
• 'unsafe-eval', टेक्स्ट को JavaScript में इस्तेमाल करने की अनुमति देता है, जैसे कि eval. ज़्यादा जानकारी के लिए, eval() से बचें देखें.

इन कीवर्ड के लिए सिंगल कोट की ज़रूरत होती है. उदाहरण के लिए, script-src 'self' (कोटेशन के साथ) मौजूदा होस्ट के JavaScript को चलाने की अनुमति देता है; script-src self (कोई कोट नहीं) "self" नाम वाले सर्वर से JavaScript को अनुमति देता है (और मौजूदा होस्ट के नहीं).

अपने पेजों को सैंडबॉक्स करें

यहां एक और डायरेक्टिव भी है जिसके बारे में बात करनी चाहिए: sandbox. यह उन दूसरे टूल से थोड़ा अलग है जिन्हें हमने देखा है. इसमें पेज लोड होने वाले रिसॉर्स के बजाय, पेज की कार्रवाइयों पर पाबंदी लगाई गई है. अगर sandbox डायरेक्टिव मौजूद है, तो पेज को ऐसा माना जाता है जैसे उसे sandbox एट्रिब्यूट वाले <iframe> के अंदर लोड किया गया था. इसके कई तरह के असर हो सकते हैं. जैसे, पेज को एक खास ऑरिजिन पर डालना, फ़ॉर्म सबमिट न करना वगैरह. यह इस पेज के दायरे से बाहर की जानकारी है. हालांकि, आपको HTML5 स्पेसिफ़िकेशन के "सैंडबॉक्सिंग" सेक्शन में, मान्य सैंडबॉक्सिंग एट्रिब्यूट के बारे में पूरी जानकारी मिल सकती है.

मेटा टैग

सीएसपी के लिए, डिलीवरी का पसंदीदा तरीका एक एचटीटीपी हेडर है. हालांकि, सीधे मार्कअप में किसी पेज पर नीति सेट करना फ़ायदेमंद हो सकता है. ऐसा करने के लिए, http-equiv एट्रिब्यूट वाले <meta> टैग का इस्तेमाल करें:

<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

इसका इस्तेमाल frame-ancestors, report-uri या sandbox के लिए नहीं किया जा सकता.

इनलाइन कोड का इस्तेमाल न करें

सीएसपी के निर्देशों में इस्तेमाल किए जाने वाले, ऑरिजिन के आधार पर अनुमति वाली सूची की तरह ही, ये XSS हमलों से होने वाले सबसे बड़े खतरे को हल नहीं कर सकते: इनलाइन स्क्रिप्ट इंजेक्शन. अगर कोई हमलावर ऐसा स्क्रिप्ट टैग इंजेक्ट कर सकता है जिसमें सीधे तौर पर नुकसान पहुंचाने वाला कुछ पेलोड (जैसे कि <script>sendMyDataToEvilDotCom()</script>) शामिल है, तो ब्राउज़र के पास इसे किसी सही इनलाइन स्क्रिप्ट टैग से अलग करने का कोई तरीका नहीं होता है. सीएसपी, इनलाइन स्क्रिप्ट पर पूरी तरह से पाबंदी लगाकर इस समस्या को हल करता है.

इस पाबंदी में, सीधे तौर पर script टैग में एम्बेड की गई स्क्रिप्ट के साथ-साथ, इनलाइन इवेंट हैंडलर और javascript: यूआरएल भी शामिल होते हैं. आपको script टैग के कॉन्टेंट को किसी बाहरी फ़ाइल में ले जाना होगा और javascript: यूआरएल और <a ... onclick="[JAVASCRIPT]"> को सही addEventListener() कॉल से बदलना होगा. उदाहरण के लिए, आपके पास इन्हें फिर से लिखने का विकल्प है:

<script>
    function doAmazingThings() {
    alert('YOU ARE AMAZING!');
    }
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>

जैसे कुछ इस तरह से लिखें:

<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>

// amazing.js
function doAmazingThings() {
    alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
    document.getElementById('amazing')
    .addEventListener('click', doAmazingThings);
});

दोबारा लिखा गया कोड न सिर्फ़ सीएसपी के साथ काम करता है, बल्कि वेब डिज़ाइन के सबसे सही तरीकों के मुताबिक भी है. इनलाइन JavaScript, स्ट्रक्चर और व्यवहार को इस तरह मिला देता है कि कोड को समझना मुश्किल हो जाता है. इसे कैश मेमोरी में सेव करना और कंपाइल करना भी मुश्किल हो गया है. अपने कोड को बाहरी संसाधनों में ले जाने से आपके पेज बेहतर परफ़ॉर्म करते हैं.

हमारा सुझाव है कि इनलाइन style टैग और एट्रिब्यूट को बाहरी स्टाइलशीट में ले जाएं. इससे आपकी साइट को सीएसएस पर आधारित डेटा बाहर निकाले जाने के हमलों से बचाया जा सकता है.

इनलाइन स्क्रिप्ट और स्टाइल को कुछ समय के लिए अनुमति देने का तरीका

script-src या style-src डायरेक्टिव में, 'unsafe-inline' को अनुमति वाले सोर्स के तौर पर जोड़कर, इनलाइन स्क्रिप्ट और स्टाइल चालू किए जा सकते हैं. सीएसपी लेवल 2 आपको क्रिप्टोग्राफ़िक नॉन्स (एक बार इस्तेमाल किया जाने वाला नंबर) या हैश का इस्तेमाल करके, अनुमति वाली सूची में खास इनलाइन स्क्रिप्ट जोड़ने की सुविधा देता है.

नॉन्स का इस्तेमाल करने के लिए, अपने स्क्रिप्ट टैग को नॉन्स एट्रिब्यूट दें. इसकी वैल्यू, भरोसेमंद सोर्स की सूची में मौजूद वैल्यू से मेल खानी चाहिए. उदाहरण के लिए:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
    // Some inline code I can't remove yet, but need to as soon as possible.
</script>

nonce- कीवर्ड के बाद, अपने script-src डायरेक्टिव में नॉन्स जोड़ें:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

हर पेज के अनुरोध के लिए, नॉन्स दोबारा जनरेट किए जाने चाहिए और वे अनदेखे होने चाहिए.

हैश भी इसी तरह काम करते हैं. स्क्रिप्ट टैग में कोड जोड़ने के बजाय, स्क्रिप्ट का SHA हैश बनाएं और उसे script-src डायरेक्टिव में जोड़ें. उदाहरण के लिए, अगर आपके पेज पर यह है:

<script>alert('Hello, world.');</script>

आपकी नीति में यह जानकारी शामिल होनी चाहिए:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

sha*- प्रीफ़िक्स, हैश जनरेट करने वाले एल्गोरिदम के बारे में बताता है. पिछले उदाहरण में, sha256- का इस्तेमाल किया गया है, लेकिन सीएसपी sha384- और sha512- के साथ भी काम करता है. हैश जनरेट करते समय, <script> टैग को छोड़ दें. कैपिटल लेटर का इस्तेमाल और खाली सफ़ेद जगह मायने रखती है. इसमें आगे और पीछे की खाली सफ़ेद जगह शामिल है.

SHA हैश जनरेट करने के लिए समाधान कई भाषाओं में उपलब्ध हैं. Chrome 40 या उसके बाद के वर्शन का इस्तेमाल करके, DevTools खोला जा सकता है. इसके बाद, अपने पेज को फिर से लोड किया जा सकता है. कंसोल टैब, आपकी हर इनलाइन स्क्रिप्ट के लिए सही SHA-256 हैश के साथ गड़बड़ी के मैसेज दिखाता है.

eval() से बचें

भले ही, कोई हमलावर स्क्रिप्ट को सीधे इंजेक्ट न कर पाए, फिर भी वह आपके ऐप्लिकेशन को धोखे से इनपुट टेक्स्ट को एक्ज़ीक्यूटेबल JavaScript में बदल सकता है और अपनी तरफ़ से उसे एक्ज़ीक्यूट कर सकता है. eval(), new Function(), setTimeout([string], …), और setInterval([string], ...) ऐसे सभी वेक्टर हैं जिनका इस्तेमाल इंजेक्ट किए गए टेक्स्ट की मदद से, नुकसान पहुंचाने वाले कोड को एक्ज़ीक्यूट करने के लिए किया जा सकता है. इस जोखिम को लेकर सीएसपी डिफ़ॉल्ट रूप से इन सभी वेक्टर को पूरी तरह से ब्लॉक कर देता है.

इसका ऐप्लिकेशन बनाने के तरीके पर ये असर होता है:

• आपको eval पर भरोसा करने के बजाय, पहले से मौजूद JSON.parse का इस्तेमाल करके, JSON को पार्स करना होगा. JSON की सुरक्षित कार्रवाइयां, IE8 के बाद से हर ब्राउज़र पर उपलब्ध हैं.

• आपको स्ट्रिंग के बजाय इनलाइन फ़ंक्शन का इस्तेमाल करके किए गए सभी setTimeout या setInterval कॉल को फिर से लिखना होगा. उदाहरण के लिए, अगर आपके पेज पर ये चीज़ें मौजूद हैं:

  setTimeout("document.querySelector('a').style.display = 'none';", 10);
  

  इसे इस तरह फिर से लिखो:

  setTimeout(function () {
      document.querySelector('a').style.display = 'none';
  }, 10);
    ```
  

• रनटाइम के दौरान इनलाइन टेंप्लेट बनाने से बचें. कई टेंप्लेट बनाने वाली लाइब्रेरी, रनटाइम के दौरान टेंप्लेट जनरेट करने की प्रोसेस को तेज़ करने के लिए, अक्सर new Function() का इस्तेमाल करती हैं. इससे, नुकसान पहुंचाने वाले टेक्स्ट का आकलन किया जा सकता है. कुछ फ़्रेमवर्क, सीएसपी के साथ काम करते हैं और eval के बिना, बेहतर पार्सर का इस्तेमाल करते हैं. AngularJS का ng-csp डायरेक्टिव इसका एक अच्छा उदाहरण है. हालांकि, हमारा सुझाव है कि आप टेंप्लेट की ऐसी भाषा का इस्तेमाल करें जिसमें प्रीकंपाइलेशन उपलब्ध हो, जैसे कि हैंडलबार. अपने टेंप्लेट को पहले से कंपाइल करने से, उपयोगकर्ता का अनुभव, सबसे तेज़ रनटाइम लागू करने के तरीके से ज़्यादा तेज़ हो सकता है. साथ ही, इससे आपकी साइट ज़्यादा सुरक्षित हो सकती है.

अगर आपके ऐप्लिकेशन के लिए eval() या टेक्स्ट-टू-JavaScript के अन्य फ़ंक्शन ज़रूरी हैं, तो script-src डायरेक्टिव में 'unsafe-eval' को अनुमति वाले सोर्स के तौर पर जोड़कर, उन्हें चालू किया जा सकता है. हम इसका सुझाव नहीं देते हैं, क्योंकि इससे कोड इंजेक्शन का जोखिम हो सकता है.

नीति के उल्लंघनों की शिकायत करना

ऐसे गड़बड़ियों के बारे में सर्वर को बताने के लिए जो नुकसान पहुंचाने वाले इंजेक्शन की अनुमति दे सकती हैं, ब्राउज़र को report-uri डायरेक्टिव में बताई गई जगह के बारे में POST JSON-फ़ॉर्मैट के उल्लंघन की रिपोर्ट बताने के लिए कहें:

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

ये रिपोर्ट कुछ इस तरह दिखती हैं:

{
    "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
    }
}

रिपोर्ट में नीति के उल्लंघन की वजह का पता लगाने से जुड़ी काम की जानकारी होती है. इसमें पेज का वह पेज (document-uri), उस पेज का referrer, पेज की नीति का उल्लंघन करने वाला रिसॉर्स (blocked-uri), उल्लंघन करने वाले खास निर्देश (violated-directive), और पेज की पूरी नीति (original-policy) की जानकारी शामिल होती है.

रिपोर्ट-ओनली

अगर आपने हाल ही में सीएसपी का इस्तेमाल किया है, तो हमारा सुझाव है कि नीति बदलने से पहले, अपने ऐप्लिकेशन की स्थिति का आकलन करने के लिए, 'सिर्फ़ रिपोर्ट' मोड का इस्तेमाल करें. ऐसा करने के लिए, Content-Security-Policy हेडर भेजने के बजाय, कोई Content-Security-Policy-Report-Only हेडर भेजें:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

सिर्फ़ रिपोर्ट वाले मोड में बताई गई नीति, पाबंदी वाले संसाधनों को ब्लॉक नहीं करती. हालांकि, यह आपकी बताई गई जगह पर उल्लंघन की रिपोर्ट भेजती है. किसी एक नीति को लागू करने के लिए, दूसरी नीति को मॉनिटर करने के लिए दोनों हेडर भी भेजे जा सकते हैं. अपनी मौजूदा नीति को लागू करते समय अपने सीएसपी में किए गए बदलावों की जांच करने का यह एक बेहतरीन तरीका है: नई नीति के लिए रिपोर्ट करने की सुविधा चालू करें, उल्लंघन की रिपोर्ट पर नज़र रखें, और गड़बड़ियों को ठीक करें. जब आप नई नीति से संतुष्ट हो जाएं, तो उसे लागू करना शुरू करें.

असल दुनिया में इस्तेमाल

अपने ऐप्लिकेशन के लिए नीति बनाने का पहला कदम है, लोड होने वाले संसाधनों का आकलन करना. अपने ऐप्लिकेशन के स्ट्रक्चर को समझने के बाद, उसकी ज़रूरी शर्तों के मुताबिक नीति बनाएं. नीचे दिए गए सेक्शन में, इस्तेमाल के कुछ आम उदाहरणों और सीएसपी के दिशा-निर्देशों का पालन करने के लिए, बेहतर फ़ैसले लेने के तरीके के बारे में बताया गया है.

सोशल मीडिया विजेट

• Facebook के 'पसंद करें' बटन में लागू करने के कई विकल्प हैं. हमारा सुझाव है कि आप <iframe> वर्शन का इस्तेमाल करें, ताकि इसे आपकी साइट के बाकी हिस्सों से सैंडबॉक्स रखा जा सके. यह ठीक से काम करे, इसके लिए child-src https://facebook.com डायरेक्टिव की ज़रूरत होती है.
• X का ट्वीट बटन, स्क्रिप्ट के ऐक्सेस पर निर्भर करता है. इससे मिली स्क्रिप्ट को बाहरी JavaScript फ़ाइल में ले जाएं और निर्देश script-src https://platform.twitter.com; child-src https://platform.twitter.com का इस्तेमाल करें.
• दूसरे प्लैटफ़ॉर्म की भी ज़रूरतें जैसी होती हैं और उन्हें भी इसी तरह पूरा किया जा सकता है. इन संसाधनों की जांच करने के लिए, हमारा सुझाव है कि आप 'none' के default-src को सेट करें. साथ ही, अपने कंसोल पर देखें कि आपको किन संसाधनों को चालू करने की ज़रूरत होगी.

एक से ज़्यादा विजेट का इस्तेमाल करने के लिए, निर्देशों को इस तरह जोड़ें:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

लॉकडाउन

कुछ वेबसाइटों के लिए, आपको यह पक्का करना होगा कि सिर्फ़ स्थानीय संसाधन ही लोड किए जा सकें. नीचे दिए गए उदाहरण में, एक बैंकिंग साइट के लिए सीएसपी बनाया गया है. इसकी शुरुआत एक ऐसी डिफ़ॉल्ट नीति से की गई है जो सभी चीज़ों (default-src 'none') को ब्लॉक करती है.

यह साइट https://cdn.mybank.net पर, सीडीएन से सभी इमेज, स्टाइल, और स्क्रिप्ट लोड करती है. साथ ही, डेटा वापस पाने के लिए, XHR का इस्तेमाल करके https://api.mybank.com/ से कनेक्ट की जाती है. इसमें फ़्रेम का इस्तेमाल होता है, लेकिन सिर्फ़ साइट के स्थानीय पेजों के लिए (तीसरे-पक्ष का नहीं). साइट पर न तो Flash है, न कोई फ़ॉन्ट है, न कोई अतिरिक्त. यह सबसे ज़्यादा पाबंदी वाला सीएसपी हेडर भेज सकता है:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

सिर्फ़ एसएसएल

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

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

हालांकि, https: के बारे में default-src में बताया गया है, लेकिन स्क्रिप्ट और स्टाइल डायरेक्टिव अपने-आप उस सोर्स को इनहेरिट नहीं करते. हर डायरेक्टिव, उस तरह के संसाधन के लिए डिफ़ॉल्ट रूप से लागू हो जाता है.

सीएसपी स्टैंडर्ड डेवलपमेंट

कॉन्टेंट की सुरक्षा के बारे में नीति लेवल 2, W3C का सुझाया गया स्टैंडर्ड है. W3C का वेब ऐप्लिकेशन सिक्योरिटी वर्किंग ग्रुप, स्पेसिफ़िकेशन में शामिल अगले बदलाव, कॉन्टेंट की सुरक्षा के बारे में नीति लेवल 3 को डेवलप कर रहा है.

इन आने वाली सुविधाओं के बारे में चर्चा को जारी रखने के लिए, public-webappsec@ ईमेल पाने वाले लोगों की सूची के संग्रह को देखें.