इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

Joe Medley

Mike West

ब्राउज़र के इस्तेमाल से जुड़ी सहायता

सोर्स

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

कंसोल में गड़बड़ी: स्क्रिप्ट 'http://evil.example.com/evil.js' को लोड करने से इनकार किया गया, क्योंकि यह कॉन्टेंट की सुरक्षा से जुड़ी नीति के इस निर्देश का उल्लंघन करती है: script-src 'self' https://apis.google.com — अगर कोई स्क्रिप्ट, अनुमति वाली सूची में शामिल नहीं ऑरिजिन से चलने की कोशिश करती है, तो Console में गड़बड़ी दिखती है.

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

सीएसपी, नीति के निर्देशों का एक सेट उपलब्ध कराता है. इससे, उन संसाधनों पर बारीकी से कंट्रोल किया जा सकता है जिन्हें पेज पर लोड करने की अनुमति है. इनमें, पिछले उदाहरण में दिया गया 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: इससे फ़्लैश और अन्य प्लग इन को कंट्रोल करने की अनुमति मिलती है.
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', eval जैसे टेक्स्ट-टू-JavaScript मशीन को अनुमति देता है. ज़्यादा जानकारी के लिए, eval() से बचना लेख पढ़ें.

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

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

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

मेटा टैग

सीएसपी के लिए, डिलीवरी का पसंदीदा तरीका एचटीटीपी हेडर है. हालांकि, सीधे मार्कअप में किसी पेज पर नीति सेट करना मददगार हो सकता है. ऐसा करने के लिए, 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 डायरेक्टिव, इसका एक अच्छा उदाहरण है. हालांकि, हमारा सुझाव है कि आप टेंप्लेट बनाने के लिए, ऐसी भाषा का इस्तेमाल करें जो पहले से कॉम्पाइल की जा सकती हो. जैसे, Handlebars. अपने टेंप्लेट को पहले से कंपाइल करने से, उपयोगकर्ता अनुभव को सबसे तेज़ रनटाइम लागू करने की तुलना में ज़्यादा तेज़ बनाया जा सकता है. साथ ही, इससे आपकी साइट ज़्यादा सुरक्षित बन सकती है.

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

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

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

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/ से कनेक्ट करती है. यह फ़्रेम का इस्तेमाल करता है, लेकिन सिर्फ़ साइट के स्थानीय पेजों के लिए (तीसरे पक्ष के ऑरिजिन नहीं). साइट पर कोई फ़्लैश, फ़ॉन्ट या अन्य चीज़ें नहीं हैं. यह सबसे ज़्यादा पाबंदी वाला सीएसपी हेडर भेज सकता है:

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 में बताया गया है, लेकिन स्क्रिप्ट और स्टाइल निर्देश उस सोर्स को अपने-आप इनहेरिट नहीं करते. हर डायरेक्टिव, उस खास तरह के संसाधन के लिए डिफ़ॉल्ट वैल्यू को बदल देता है.

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

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

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