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

Lukas Weichselbaum

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

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

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

मुख्य शब्द: nonce ऐसा नंबर होता है जिसे सिर्फ़ एक बार इस्तेमाल किया जाता है. इसका इस्तेमाल, <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 (v7.3.0 और इसके बाद के वर्शन वाले फ़्लैग --preset=experimental के साथ) का इस्तेमाल करने से, इस पूरी प्रक्रिया के सबसे सही तरीके ऑडिट किए जा सकते हैं. इनसे पता चलता है कि आपकी साइट पर सीएसपी की सुविधा है या नहीं और XSS के असर को कम करने के लिए वह काफ़ी है या नहीं.

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

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

नोेंस-आधारित सीएसपी

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

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

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

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

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

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

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

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

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

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 });
});

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

अपने ऐप्लिकेशन में, यह 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>

सीएसपी इन स्क्रिप्ट को ब्लॉक करता है, क्योंकि सिर्फ़ इनलाइन-स्क्रिप्ट को हैश किया जा सकता है.

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

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

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

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

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

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

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

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

<span id="things">A thing.</span>
<script nonce="${nonce}">
  document.getElementById('things').addEventListener('click', doThings);
</script>

<span onclick="doThings();">A thing.</span>

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

<a id="foo">foo</a>
<script nonce="${nonce}">
  document.getElementById('foo').addEventListener('click', linkClicked);
</script>

<a href="javascript:linkClicked()">foo</a>

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

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

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

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

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

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

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

सीमाएं

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

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

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

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

• सीएसपी इज़ डेड, लॉन्ग लाइव सीएसपी! व्हाइटलिस्ट की सुरक्षा से जुड़ी नीति और कॉन्टेंट की सुरक्षा का भविष्य
• सीएसपी का आकलन करने वाला
• LocoMoco कॉन्फ़्रेंस: कॉन्टेंट की सुरक्षा के बारे में नीति - सुरक्षा के सख्त और कम करने के तरीकों के बीच एक सफल गड़बड़ी
• Google I/O के बारे में बातचीत: मॉडर्न प्लैटफ़ॉर्म सुविधाओं की मदद से वेब ऐप्लिकेशन सुरक्षित करना