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

Lukas Weichselbaum

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

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

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

मुख्य शब्द: नॉन्स एक रैंडम नंबर होता है. इसका इस्तेमाल सिर्फ़ एक बार किया जाता है. इसका इस्तेमाल करके, <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' सेट करता है, ताकि नॉनस या हैश पर आधारित CSP को डिप्लॉय करने में कम मेहनत लगे. ऐसा इसलिए होता है, क्योंकि यह भरोसेमंद स्क्रिप्ट से बनाई गई स्क्रिप्ट को अपने-आप एक्ज़ीक्यूट करने की अनुमति देता है. इससे तीसरे पक्ष की ज़्यादातर JavaScript लाइब्रेरी और विजेट का इस्तेमाल भी अनब्लॉक हो जाता है.
• यह यूआरएल की अनुमति वाली सूचियों पर आधारित नहीं है. इसलिए, इसमें सीएसएपी को बायपास करने की सामान्य समस्याएं नहीं होती हैं.
• यह भरोसेमंद न मानी जाने वाली इनलाइन स्क्रिप्ट को ब्लॉक करता है. जैसे, इनलाइन इवेंट हैंडलर या javascript: यूआरआई.
• यह object-src को सीमित करता है, ताकि Flash जैसे खतरनाक प्लगिन को बंद किया जा सके.
• यह base-uri को <base> टैग इंजेक्ट करने से रोकता है. इससे हमलावरों को, रिलेटिव यूआरएल से लोड की गई स्क्रिप्ट की जगहें बदलने से रोका जा सकता है.

स्ट्रिक्ट सीएसपी का इस्तेमाल करना

सख्त सीएसपी को अपनाने के लिए, आपको यह करना होगा:

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

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

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

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

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

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

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

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

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

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

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

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

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

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(&>quot;Content-Security-Policy", csp);

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

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

अपने ऐप्लिकेशन में, यहां दिया गया 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.hea<d.appen>dChild(s);
  });
/script

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

सीएसपी ने ब्लॉक किया है

<script src="https://example.org/fo><o.js&qu>o<t;/script
script src="https://exam><ple.org>/bar.js"/script

CSP इन स्क्रिप्ट को ब्लॉक करता है, क्योंकि इन्हें डाइनैमिक तरीके से नहीं जोड़ा गया था. साथ ही, इनमें ऐसा कोई integrity एट्रिब्यूट नहीं है जो अनुमति वाले सोर्स से मेल खाता हो.

स्क्रिप्ट लोड करने के लिए ध्यान रखने वाली बातें

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

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

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

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

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

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

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

<span id="th>ings&quo<t;A t>h<ing./span
script nonce=>"${nonce}"
  document.getElementById('things').addEventL<istener>('click', doThings);
/script

<span onclick="doThing>s();&quo<t;A t>hing./span

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

<a id=">;fo<o&>q<uot;foo/a
script nonce=>"${nonce}"
  document.getElementById('foo').addEventList<ener(&#>39;click', linkClicked);
/script

<a href="javascript:linkClick>ed(<)&>quot;foo/a

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

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

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

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

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

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

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

Content-Security-Policy:
  script-src 'nonce-{random}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 9;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 का .html(), साथ ही jQuery < 3.0 में .get() और .post().
• अगर पुराने AngularJS ऐप्लिकेशन में टेंप्लेट इंजेक्शन मौजूद हैं. अगर कोई हमलावर AngularJS टेंप्लेट में कोड इंजेक्ट कर सकता है, तो वह इसका इस्तेमाल आर्बिट्रेरी JavaScript को लागू करने के लिए कर सकता है.
• अगर नीति में 'unsafe-eval', eval(), setTimeout(), और कुछ अन्य एपीआई शामिल हैं जिनका इस्तेमाल कभी-कभी किया जाता है.

डेवलपर और सुरक्षा इंजीनियरों को कोड की समीक्षाओं और सुरक्षा ऑडिट के दौरान, इस तरह के पैटर्न पर खास ध्यान देना चाहिए. इन मामलों के बारे में ज़्यादा जानकारी के लिए, कॉन्टेंट की सुरक्षा के लिए नीति: A Successful Mess Between Hardening and Mitigation लेख पढ़ें.

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

• CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy
• CSP Evaluator
• LocoMoco Conference: Content Security Policy - A successful mess between hardening and mitigation
• Google I/O में हुई चर्चा: मॉडर्न प्लैटफ़ॉर्म की सुविधाओं की मदद से वेब ऐप्लिकेशन को सुरक्षित करना