कॉन्टेंट की सुरक्षा के बारे में सख्त नीति (सीएसपी) का इस्तेमाल करके, क्रॉस-साइट स्क्रिप्टिंग (XSS) को कम करें

Lukas Weichselbaum

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 52.
  • Safari: 15.4.

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

कॉन्टेंट की सुरक्षा के लिए नीति (सीएसपी), सुरक्षा की एक अतिरिक्त लेयर है. इससे एक्सएसएस के जोखिम को कम करने में मदद मिलती है. सीएसपी को कॉन्फ़िगर करने के लिए, किसी वेब पेज में Content-Security-Policy एचटीटीपी हेडर जोड़ें. साथ ही, ऐसी वैल्यू सेट करें जिनसे यह कंट्रोल किया जा सके कि उपयोगकर्ता एजेंट, उस पेज के लिए कौनसे संसाधन लोड कर सकता है.

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

मुख्य शब्द: नॉन्स एक रैंडम नंबर होता है, जिसका इस्तेमाल सिर्फ़ एक बार किया जाता है. इसका इस्तेमाल, <script> टैग को भरोसेमंद के तौर पर मार्क करने के लिए किया जा सकता है.

मुख्य शब्द: हैश फ़ंक्शन एक गणितीय फ़ंक्शन है, जो इनपुट वैल्यू को कंप्रेस की गई संख्या वाली वैल्यू में बदलता है. इसे हैश कहा जाता है. इनलाइन <script> टैग को भरोसेमंद के तौर पर मार्क करने के लिए, हैश (उदाहरण के लिए, SHA-256) का इस्तेमाल किया जा सकता है.

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

आपको सख्त सीएसपी का इस्तेमाल क्यों करना चाहिए?

अगर आपकी साइट पर पहले से ही script-src www.googleapis.com जैसा सीएसपी मौजूद है, तो हो सकता है कि वह क्रॉस-साइट के ख़िलाफ़ असरदार न हो. इस तरह के सीएसपी को अनुमति वाली सूची वाला सीएसपी कहा जाता है. इनमें बहुत ज़्यादा कस्टमाइज़ेशन की ज़रूरत होती है. साथ ही, हमलावर इन्हें बायपास कर सकते हैं.

क्रिप्टोग्राफ़िक नॉन्स या हैश पर आधारित सख्त सीएसपी, इन समस्याओं से बचाते हैं.

सख्त सीएसपी स्ट्रक्चर

कॉन्टेंट की सुरक्षा के लिए सख्त नीति, इनमें से किसी एक एचटीटीपी रिस्पॉन्स हेडर का इस्तेमाल करती है:

नॉन्स पर आधारित सख्त सीएसपी

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';
नॉन्स पर आधारित स्ट्रिक्ट सीएसपी के काम करने का तरीका.

हैश पर आधारित स्ट्रिक्ट सीएसपी

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

इन प्रॉपर्टी की वजह से, इस तरह की सीएसपी "सख्त" और सुरक्षित हो जाती है:

  • यह नॉनस 'nonce-{RANDOM}' या हैश 'sha256-{HASHED_INLINE_SCRIPT}' का इस्तेमाल करके बताता है कि साइट के डेवलपर को उपयोगकर्ता के ब्राउज़र में, किन <script> टैग को चलाने पर भरोसा है.
  • यह 'strict-dynamic' सेट करता है, ताकि नॉन्स या हैश पर आधारित सीएसपी को डिप्लॉय करने में कम मेहनत लगे. इसके लिए, यह किसी भरोसेमंद स्क्रिप्ट से बनाई गई स्क्रिप्ट को अपने-आप लागू होने की अनुमति देता है. इससे, तीसरे पक्ष की ज़्यादातर JavaScript लाइब्रेरी और विजेट के इस्तेमाल पर लगी पाबंदी भी हट जाती है.
  • यह यूआरएल की अनुमति वाली सूचियों पर आधारित नहीं है. इसलिए, इसमें सामान्य सीएसपी बायपास की समस्या नहीं आती.
  • यह इनलाइन इवेंट हैंडलर या javascript: यूआरआई जैसी अविश्वसनीय इनलाइन स्क्रिप्ट को ब्लॉक करता है.
  • यह नीति object-src को Flash जैसे खतरनाक प्लगिन बंद करने से रोकती है.
  • यह base-uri को प्रतिबंधित करता है, ताकि <base> टैग को इंजेक्ट होने से रोका जा सके. इससे, हमलावर रिलेटिव यूआरएल से लोड की गई स्क्रिप्ट की जगहों को नहीं बदल पाते.

स्ट्रिक्ट सीएसपी अपनाएं

स्ट्रिक्ट सीएसपी लागू करने के लिए, आपको ये काम करने होंगे:

  1. यह तय करें कि आपके ऐप्लिकेशन को नॉन्स या हैश पर आधारित सीएसपी सेट करना चाहिए या नहीं.
  2. स्ट्रिक्ट सीएसपी स्ट्रक्चर सेक्शन से सीएसपी को कॉपी करें और उसे अपने ऐप्लिकेशन में रिस्पॉन्स हेडर के तौर पर सेट करें.
  3. एचटीएमएल टेंप्लेट और क्लाइंट-साइड कोड को फिर से व्यवस्थित करें, ताकि सीएसपी के साथ काम न करने वाले पैटर्न हटाए जा सकें.
  4. अपना सीएसपी डिप्लॉय करें.

इस पूरी प्रोसेस के दौरान, Lighthouse (फ़्लैग --preset=experimental के साथ v7.3.0 और इसके बाद के वर्शन) सबसे सही तरीके ऑडिट का इस्तेमाल किया जा सकता है. इससे यह पता लगाया जा सकता है कि आपकी साइट में सीएसपी है या नहीं. साथ ही, यह भी पता लगाया जा सकता है कि क्या यह एक्सएसएस के ख़िलाफ़ असरदार होने के लिए काफ़ी सख्त है.

Lighthouse की रिपोर्ट में चेतावनी दी गई है कि एनफ़ोर्समेंट मोड में कोई सीएसपी नहीं मिला.
अगर आपकी साइट पर सीएसपी नहीं है, तो Lighthouse यह चेतावनी दिखाता है.

पहला चरण: तय करें कि आपको नॉन्स या हैश पर आधारित सीएसपी की ज़रूरत है या नहीं

यहां बताया गया है कि स्ट्रिक्ट सीएसपी के दोनों टाइप कैसे काम करते हैं:

नॉन्स पर आधारित सीएसपी

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

सर्वर पर रेंडर किए गए एचटीएमएल पेजों के लिए, नॉन्स पर आधारित सीएसपी का इस्तेमाल करें. इन पेजों के लिए, हर जवाब के लिए कोई एक नंबर जनरेट किया जा सकता है.

हैश पर आधारित सीएसपी

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

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

दूसरा चरण: सख्त सीएसपी सेट करना और स्क्रिप्ट तैयार करना

सीएसपी सेट करते समय, आपके पास कुछ विकल्प होते हैं:

  • सिर्फ़ रिपोर्ट मोड (Content-Security-Policy-Report-Only) या नीति उल्लंघन ठीक करने का तरीका मोड (Content-Security-Policy). सिर्फ़ रिपोर्ट मोड में, सीएसपी अब तक संसाधनों को ब्लॉक नहीं करेगा. इसलिए, आपकी साइट पर कुछ भी नहीं टूटेगा. हालांकि, आपको गड़बड़ियां दिख सकती हैं और ब्लॉक किए गए किसी भी संसाधन की रिपोर्ट मिल सकती है. स्थानीय तौर पर, सीएसपी सेट करते समय इससे कोई फ़र्क़ नहीं पड़ता, क्योंकि दोनों मोड में ब्राउज़र कंसोल में गड़बड़ियां दिखती हैं. एनफ़ोर्समेंट मोड की मदद से, उन रिसॉर्स का पता लगाया जा सकता है जिन्हें आपके ड्राफ़्ट सीएसपी ने ब्लॉक किया है. ऐसा इसलिए, क्योंकि किसी रिसॉर्स को ब्लॉक करने से आपका पेज खराब दिख सकता है. रिपोर्ट-ओनली मोड, प्रोसेस के बाद के चरणों में ज़्यादा काम आता है (पांचवां चरण देखें).
  • हेडर या एचटीएमएल <meta> टैग. लोकल डेवलपमेंट के लिए, <meta> टैग का इस्तेमाल करना ज़्यादा आसान हो सकता है. इससे सीएसपी में बदलाव किया जा सकता है और यह तुरंत देखा जा सकता है कि इसका आपकी साइट पर क्या असर पड़ता है. हालांकि:
    • बाद में, प्रोडक्शन में सीएसपी को डिप्लॉय करते समय, हमारा सुझाव है कि आप इसे एचटीटीपी हेडर के तौर पर सेट करें.
    • अगर आपको अपने सीएसपी को सिर्फ़ रिपोर्ट मोड में सेट करना है, तो आपको इसे हेडर के तौर पर सेट करना होगा. ऐसा इसलिए, क्योंकि सीएसपी मेटा टैग, सिर्फ़ रिपोर्ट मोड के साथ काम नहीं करते.

पहला विकल्प: नॉन्स पर आधारित सीएसपी

अपने ऐप्लिकेशन में, यह Content-Security-Policy एचटीटीपी रिस्पॉन्स हेडर सेट करें: 

Content-Security-Policy:
  script-src 'nonce-{RANDOM}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

सीएसपी के लिए नॉन्स जनरेट करना

नॉन्स, एक रैंडम नंबर होता है. इसका इस्तेमाल, हर पेज लोड पर सिर्फ़ एक बार किया जाता है. नॉनस पर आधारित सीएसपी, एक्सएसएस के जोखिम को सिर्फ़ तब कम कर सकता है, जब हमलावर नॉनस वैल्यू का अनुमान न लगा पाएं. सीएसपी नॉन्स के लिए ज़रूरी है कि:

  • क्रिप्टोग्राफ़ी के हिसाब से मज़बूत रैंडम वैल्यू (आम तौर पर, 128+ बिट की लंबाई)
  • हर जवाब के लिए नया कोड जनरेट किया जाता है
  • Base64 कोड में बदला गया

सर्वर-साइड फ़्रेमवर्क में सीएसपी नॉन्स जोड़ने के कुछ उदाहरण यहां दिए गए हैं:

const app = express();

app.get('/', function(request, response) {
  // Generate a new random nonce value for every response.
  const nonce = crypto.randomBytes(16).toString("base64");

  // Set the strict nonce-based CSP response header
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response.set("Content-Security-Policy", csp);

  // Every <script> tag in your application should set the `nonce` attribute to this value.
  response.render(template, { nonce: nonce });
});

<script> एलिमेंट में nonce एट्रिब्यूट जोड़ें

नॉन्स पर आधारित सीएसपी के साथ, हर <script> एलिमेंट में एक nonce एट्रिब्यूट होना चाहिए. यह एट्रिब्यूट, सीएसपी हेडर में बताई गई रैंडम नॉन्स वैल्यू से मेल खाना चाहिए. सभी स्क्रिप्ट में एक ही नॉन्स हो सकता है. सबसे पहले, इन एट्रिब्यूट को सभी स्क्रिप्ट में जोड़ें, ताकि सीएसपी उन्हें अनुमति दे सके.

दूसरा विकल्प: हैश पर आधारित सीएसपी रिस्पॉन्स हेडर

अपने ऐप्लिकेशन में, यह Content-Security-Policy एचटीटीपी रिस्पॉन्स हेडर सेट करें: 

Content-Security-Policy:
  script-src 'sha256-{HASHED_INLINE_SCRIPT}' 'strict-dynamic';
  object-src 'none';
  base-uri 'none';

एक से ज़्यादा इनलाइन स्क्रिप्ट के लिए, सिंटैक्स इस तरह होता है: 'sha256-{HASHED_INLINE_SCRIPT_1}' 'sha256-{HASHED_INLINE_SCRIPT_2}'.

सोर्स की गई स्क्रिप्ट को डाइनैमिक तौर पर लोड करना

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

स्क्रिप्ट को इनलाइन करने का उदाहरण.
सीएसपी ने अनुमति दी है 
<script>
  var scripts = [ 'https://example.org/foo.js', 'https://example.org/bar.js'];

  scripts.forEach(function(scriptUrl) {
    var s = document.createElement('script');
    s.src = scriptUrl;
    s.async = false; // to preserve execution order
    document.head.appendChild(s);
  });
</script>
 इस स्क्रिप्ट को चलाने के लिए, आपको इनलाइन स्क्रिप्ट के हैश का हिसाब लगाना होगा. इसके बाद, उसे सीएसपी रिस्पॉन्स हेडर में जोड़ना होगा. साथ ही, {HASHED_INLINE_SCRIPT} प्लेसहोल्डर को बदलना होगा. हैश की संख्या कम करने के लिए, सभी इनलाइन स्क्रिप्ट को एक ही स्क्रिप्ट में मर्ज किया जा सकता है. इसे काम करते हुए देखने के लिए, यह उदाहरण और इसका कोड देखें.
सीएसपी ने ब्लॉक किया
<script src="https://example.org/foo.js"></script>
<script src="https://example.org/bar.js"></script>
 सीएसपी इन स्क्रिप्ट को ब्लॉक करता है, क्योंकि इन्हें डाइनैमिक तरीके से नहीं जोड़ा गया था. साथ ही, इनमें ऐसा कोई integrity एट्रिब्यूट नहीं है जो अनुमति वाले सोर्स से मैच करता हो.

स्क्रिप्ट लोड करने से जुड़ी ज़रूरी बातें

इनलाइन स्क्रिप्ट के उदाहरण में s.async = false को जोड़ा गया है, ताकि यह पक्का किया जा सके कि foo, bar से पहले लागू हो. भले ही, bar पहले लोड हो. इस स्निपेट में, स्क्रिप्ट लोड होने के दौरान s.async = false पार्सर को ब्लॉक नहीं करता, क्योंकि स्क्रिप्ट डाइनैमिक तरीके से जोड़ी जाती हैं. पार्सर सिर्फ़ तब रुकता है, जब स्क्रिप्ट एक्ज़ीक्यूट होती हैं. ऐसा async स्क्रिप्ट के लिए होता है. हालांकि, इस स्निपेट के साथ, इन बातों का ध्यान रखें:

  • दस्तावेज़ के डाउनलोड होने से पहले, एक या दोनों स्क्रिप्ट एक्ज़ीक्यूट हो सकती हैं. अगर आपको स्क्रिप्ट के लागू होने तक दस्तावेज़ तैयार करना है, तो स्क्रिप्ट जोड़ने से पहले DOMContentLoaded इवेंट का इंतज़ार करें. अगर स्क्रिप्ट जल्दी डाउनलोड न होने की वजह से परफ़ॉर्मेंस की समस्या आती है, तो पेज पर पहले प्रीलोड टैग का इस्तेमाल करें.
  • defer = true से कुछ नहीं होता. अगर आपको इस तरह का व्यवहार चाहिए, तो ज़रूरत पड़ने पर स्क्रिप्ट को मैन्युअल तरीके से चलाएं.

तीसरा चरण: एचटीएमएल टेंप्लेट और क्लाइंट-साइड कोड को रीफ़ैक्टर करें

स्क्रिप्ट चलाने के लिए, इनलाइन इवेंट हैंडलर (जैसे, onclick="…", onerror="…") और JavaScript यूआरआई (<a href="javascript:…">) का इस्तेमाल किया जा सकता है. इसका मतलब है कि अगर किसी हमलावर को XSS बग मिलता है, तो वह इस तरह का एचटीएमएल इंजेक्ट कर सकता है और नुकसान पहुंचाने वाली JavaScript को चला सकता है. नॉन्स या हैश पर आधारित सीएसपी, इस तरह के मार्कअप के इस्तेमाल पर पाबंदी लगाता है. अगर आपकी साइट इनमें से किसी भी पैटर्न का इस्तेमाल करती है, तो आपको उन्हें सुरक्षित विकल्पों में बदलना होगा.

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

Chrome डेवलपर कंसोल में सीएसपी के उल्लंघन की रिपोर्ट.
ब्लॉक किए गए कोड के लिए कंसोल की गड़बड़ियां.

ज़्यादातर मामलों में, समस्या को ठीक करना आसान होता है:

इनलाइन इवेंट हैंडलर को रीफ़ैक्टर करना

सीएसपी ने अनुमति दी है
<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things').addEventListener('click', doThings);
</script>
 सीएसपी, JavaScript का इस्तेमाल करके रजिस्टर किए गए इवेंट हैंडलर को अनुमति देता है.
सीएसपी ने ब्लॉक किया
<span onclick="doThings();">A thing.</span>
 सीएसपी, इनलाइन इवेंट हैंडलर को ब्लॉक करता है.

javascript: यूआरआई को रीफ़ैक्टर करें

सीएसपी ने अनुमति दी है
<a id="foo">foo</a>
<script nonce="${nonce}">
  document.getElementById('foo').addEventListener('click', linkClicked);
</script>
 सीएसपी, JavaScript का इस्तेमाल करके रजिस्टर किए गए इवेंट हैंडलर को अनुमति देता है.
सीएसपी ने ब्लॉक किया
<a href="javascript:linkClicked()">foo</a>
 सीएसपी, javascript: यूआरआई को ब्लॉक करता है.

अपने JavaScript से eval() को हटाएं

अगर आपका ऐप्लिकेशन JSON स्ट्रिंग सीरियलाइज़ेशन को JS ऑब्जेक्ट में बदलने के लिए eval() का इस्तेमाल करता है, तो आपको ऐसे इंस्टेंस को JSON.parse() में रीफ़ैक्टर करना चाहिए. यह तेज़ भी है.

अगर eval() के सभी इस्तेमाल नहीं हटाए जा सकते, तो भी नॉनस पर आधारित सख्त सीएसपी सेट किया जा सकता है. हालांकि, आपको 'unsafe-eval' सीएसपी कीवर्ड का इस्तेमाल करना होगा. इससे आपकी नीति थोड़ी कम सुरक्षित हो जाती है.

इस स्ट्रिक्ट सीएसपी कोड लैब में, आपको इस तरह के रीफ़ैक्टरिंग के और भी उदाहरण मिल सकते हैं:

चौथा चरण (ज़रूरी नहीं): ब्राउज़र के पुराने वर्शन के साथ काम करने के लिए फ़ॉलबैक जोड़ना

Browser Support

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 52.
  • Safari: 15.4.

अगर आपको ब्राउज़र के पुराने वर्शन के साथ काम करने वाली साइटें बनानी हैं, तो:

  • strict-dynamic का इस्तेमाल करने के लिए, Safari के पुराने वर्शन के लिए https: को फ़ॉलबैक के तौर पर जोड़ना ज़रूरी है. ऐसा करने पर:
    • strict-dynamic के साथ काम करने वाले सभी ब्राउज़र, https: फ़ॉलबैक को अनदेखा कर देते हैं. इसलिए, इससे नीति की मज़बूती कम नहीं होगी.
    • पुराने ब्राउज़र में, बाहरी सोर्स से मिली स्क्रिप्ट सिर्फ़ तब लोड हो सकती हैं, जब वे एचटीटीपीएस ऑरिजिन से मिली हों. यह तरीका, सख्त सीएसपी से कम सुरक्षित है. हालांकि, यह एक्सएसएस की कुछ आम वजहों को रोकता है. जैसे, javascript: यूआरआई का इंजेक्शन.
  • चार साल से ज़्यादा पुराने ब्राउज़र वर्शन के साथ काम करने के लिए, फ़ॉलबैक के तौर पर unsafe-inline को जोड़ा जा सकता है. अगर सीएसपी नॉन्स या हैश मौजूद है, तो सभी नए ब्राउज़र unsafe-inline को अनदेखा कर देते हैं.
Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

पांचवां चरण: सीएसपी को डिप्लॉय करना

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

  1. (ज़रूरी नहीं) Content-Security-Policy-Report-Only हेडर का इस्तेमाल करके, अपने सीएसपी को सिर्फ़ रिपोर्ट मोड में डिप्लॉय करें. सिर्फ़ रिपोर्ट मोड, नुकसान पहुंचा सकने वाले बदलाव की जांच करने के लिए मददगार होता है. जैसे, प्रोडक्शन में नया सीएसपी. ऐसा सीएसपी से जुड़ी पाबंदियां लागू करने से पहले किया जाता है. सिर्फ़ रिपोर्ट मोड में, सीएसपी आपके ऐप्लिकेशन के काम करने के तरीके पर असर नहीं डालता. हालांकि, जब ब्राउज़र को आपके सीएसपी के साथ काम न करने वाले पैटर्न मिलते हैं, तब भी वह कंसोल से जुड़ी गड़बड़ियां और उल्लंघन की रिपोर्ट जनरेट करता है. इससे आपको यह पता चलता है कि आपके असली उपयोगकर्ताओं के लिए क्या काम नहीं करेगा. ज़्यादा जानकारी के लिए, Reporting API देखें.
  2. जब आपको भरोसा हो जाए कि सीएसपी की वजह से असली उपयोगकर्ताओं के लिए आपकी साइट काम करना बंद नहीं करेगी, तो Content-Security-Policy रिस्पॉन्स हेडर का इस्तेमाल करके अपना सीएसपी डिप्लॉय करें. हमारा सुझाव है कि आप एचटीटीपी हेडर सर्वर-साइड का इस्तेमाल करके, अपना सीएसपी सेट करें. ऐसा इसलिए, क्योंकि यह <meta> टैग से ज़्यादा सुरक्षित है. इस चरण को पूरा करने के बाद, सीएसपी आपके ऐप्लिकेशन को एक्सएसएस से सुरक्षित करना शुरू कर देता है.

सीमाएं

सख्त सीएसपी, आम तौर पर सुरक्षा की एक मज़बूत लेयर उपलब्ध कराता है. इससे एक्सएसएस के जोखिम को कम करने में मदद मिलती है. ज़्यादातर मामलों में, सीएसपी हमले की जगह को काफ़ी हद तक कम कर देता है. इसके लिए, वह javascript: यूआरआई जैसे खतरनाक पैटर्न को अस्वीकार कर देता है. हालांकि, आपके इस्तेमाल किए जा रहे सीएसपी के टाइप (नॉन्स, हैश, 'strict-dynamic' के साथ या इसके बिना) के आधार पर, कुछ मामलों में सीएसपी आपके ऐप्लिकेशन को सुरक्षित नहीं रखता:

  • अगर किसी स्क्रिप्ट को नॉन्स किया जाता है, लेकिन उस <script> एलिमेंट के मुख्य हिस्से या src पैरामीटर में सीधे तौर पर इंजेक्शन मौजूद है.
  • अगर डाइनैमिक तौर पर बनाई गई स्क्रिप्ट (document.createElement('script')) की जगहों में इंजेक्शन मौजूद हैं, तो इनमें लाइब्रेरी के ऐसे फ़ंक्शन भी शामिल हैं जो अपने आर्ग्युमेंट की वैल्यू के आधार पर script डीओएम नोड बनाते हैं. इसमें jQuery के .html() जैसे कुछ सामान्य एपीआई के साथ-साथ, jQuery < 3.0 में .get() और .post() भी शामिल हैं.
  • अगर पुराने AngularJS ऐप्लिकेशन में टेंप्लेट इंजेक्शन मौजूद हैं. अगर कोई हमलावर AngularJS टेंप्लेट में कोड इंजेक्ट कर सकता है, तो वह इसका इस्तेमाल करके आर्बिट्रेरी JavaScript को एक्ज़ीक्यूट कर सकता है.
  • अगर नीति में 'unsafe-eval' शामिल है, तो eval(), setTimeout(), और कुछ अन्य एपीआई में इंजेक्शन की अनुमति नहीं है. इन एपीआई का इस्तेमाल बहुत कम किया जाता है.

डेवलपर और सुरक्षा इंजीनियर को कोड रिव्यू और सुरक्षा ऑडिट के दौरान, इस तरह के पैटर्न पर खास ध्यान देना चाहिए. इन मामलों के बारे में ज़्यादा जानकारी के लिए, कॉन्टेंट की सुरक्षा के लिए नीति: सुरक्षा कड़ी करने और जोखिम कम करने की प्रोसेस के बीच की उलझन लेख पढ़ें.

इस बारे में और पढ़ें