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

Lukas Weichselbaum

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

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

सोर्स

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

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

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>
 CSP, JavaScript का इस्तेमाल करके रजिस्टर किए गए इवेंट हैंडलर को अनुमति देता है.
सीएसपी ने ब्लॉक किया है
<span onclick="doThings();">A thing.</span>
 सीएसपी, इनलाइन इवेंट हैंडलर को ब्लॉक करता है.

javascript: यूआरआई को फिर से तैयार करना

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

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

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

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

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

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

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

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

सोर्स

अगर आपको ब्राउज़र के पुराने वर्शन पर काम करना है, तो:

  • strict-dynamic का इस्तेमाल करने के लिए, Safari के पुराने वर्शन के लिए फ़ॉलबैक के तौर पर https: को जोड़ना ज़रूरी है. ऐसा करने पर:
    • strict-dynamic के साथ काम करने वाले सभी ब्राउज़र, https: फ़ॉलबैक को अनदेखा करते हैं. इसलिए, इससे नीति की अहमियत कम नहीं होती.
    • पुराने ब्राउज़र में, बाहर से सोर्स की गई स्क्रिप्ट सिर्फ़ तब लोड हो सकती हैं, जब वे एचटीटीपीएस ऑरिजिन से आती हों. यह सख्त सीएसपी के मुकाबले कम सुरक्षित है. हालांकि, यह अब भी javascript: यूआरआई के इंजेक्शन जैसी कुछ सामान्य XSS समस्याओं को रोकता है.
  • यह पक्का करने के लिए कि ब्राउज़र के बहुत पुराने वर्शन (चार साल से ज़्यादा) के साथ काम करता है या नहीं, आपके पास unsafe-inline को फ़ॉलबैक के तौर पर जोड़ने का विकल्प होता है. अगर CSP नॉन्स या हैश मौजूद है, तो सभी नए ब्राउज़र 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> टैग से ज़्यादा सुरक्षित है. यह चरण पूरा करने के बाद, आपका सीएसपी आपके ऐप्लिकेशन को एक्सएसएस से सुरक्षित करना शुरू कर देता है.

सीमाएं

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

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

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

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