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

Lukas Weichselbaum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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