कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी) से यह पक्का करने में मदद मिलती है कि पेज पर लोड होने वाले किसी भी कॉन्टेंट पर साइट के मालिक को भरोसा है. सीएसपी, क्रॉस-साइट स्क्रिप्टिंग (XSS) के हमलों को कम करते हैं, क्योंकि वे हमलावरों की ओर से डाली गई असुरक्षित स्क्रिप्ट को ब्लॉक कर सकते हैं. हालांकि, अगर सीएसपी ज़रूरत के मुताबिक नहीं है, तो इससे बचने के लिए उसे आसानी से बायपास किया जा सकता है. ज़्यादा जानकारी के लिए, कॉन्टेंट की सुरक्षा के बारे में सख्त नीति (सीएसपी) की मदद से, क्रॉस-साइट स्क्रिप्टिंग (XSS) को कम करना लेख पढ़ें. लाइटहाउस, मुख्य दस्तावेज़ पर लागू सीएसपी इकट्ठा करता है. साथ ही, अगर उन्हें बायपास किया जा सकता है, तो सीएसपी इवैलुएटर से समस्याओं की जानकारी देता है.

बायपास न किए जा सकने वाले सीएसपी के लिए ज़रूरी तरीके
नीचे दिए गए तरीकों को लागू करें, ताकि आपके सीएसपी को बायपास न किया जाए. अगर सीएसपी को बायपास किया जा सकता है, तो लाइटहाउस ज़्यादा गंभीर चेतावनी देगा.
सीएसपी, XSS को टारगेट करता है
XSS को टारगेट करने के लिए, सीएसपी में script-src
, object-src
, और base-uri
डायरेक्टिव शामिल होने चाहिए. सीएसपी में सिंटैक्स की गड़बड़ियां भी नहीं होनी चाहिए.
script-src
और object-src
, किसी पेज को असुरक्षित स्क्रिप्ट और असुरक्षित प्लगिन से सुरक्षित करते हैं. इसके अलावा, script-src
और object-src
जैसे कई डायरेक्टिव की जगह पर एक नीति को कॉन्फ़िगर करने के लिए, default-src
का इस्तेमाल किया जा सकता है.
base-uri
बिना अनुमति वाले <base>
टैग डालने से रोकता है. इसका इस्तेमाल, सभी मिलते-जुलते यूआरएल (जैसे कि स्क्रिप्ट) को उस डोमेन पर रीडायरेक्ट करने के लिए किया जा सकता है जिसे कोई हमलावर कंट्रोल करता है.
अनुमति वाली सूची से बाहर होने से बचने के लिए, सीएसपी नॉन्स या हैश का इस्तेमाल करता है
जो सीएसपी, script-src
के लिए अनुमति वाली सूची को कॉन्फ़िगर करता है वह यह मानकर चलता है कि किसी भरोसेमंद डोमेन से मिलने वाले सभी रिस्पॉन्स सुरक्षित हैं और उन्हें स्क्रिप्ट के तौर पर एक्ज़ीक्यूट किया जा सकता है. हालांकि, यह अनुमान आधुनिक ऐप्लिकेशन पर लागू नहीं होता है; कुछ सामान्य और आसान पैटर्न, जैसे कि JSONP इंटरफ़ेस दिखाना और AngularJS लाइब्रेरी की कॉपी होस्ट करना, हमलावरों को सीएसपी की सीमाओं से बचने में मदद करते हैं.
मुमकिन है कि ऐप्लिकेशन के लेखकों को साफ़ तौर पर जानकारी न हो. हालांकि, अनुमति वाले script-src
में से ज़्यादातर सूचियों को गच्चा देने का काम, XSS गड़बड़ी वाला कोई हमलावर कर सकता है. साथ ही, यह स्क्रिप्ट इंजेक्शन के लिए बहुत कम सुरक्षा देता है. वहीं दूसरी ओर, नॉन-आधारित और हैश-आधारित तरीकों में ये समस्याएं नहीं होतीं. साथ ही, इनसे ज़्यादा सुरक्षित नीति को अपनाना और बनाए रखना आसान हो जाता है.
उदाहरण के लिए, यह कोड किसी भरोसेमंद डोमेन पर होस्ट किए गए JSONP एंडपॉइंट का इस्तेमाल करता है, ताकि किसी हमलावर से कंट्रोल की जाने वाली स्क्रिप्ट को इंजेक्ट किया जा सके:
सीएसपी:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
बायपास से बचने के लिए, सीएसपी को नॉन्स या हैश का इस्तेमाल करके और 'strict-डाइनैमिक' का इस्तेमाल करके स्क्रिप्ट को अलग-अलग अनुमति देनी चाहिए अनुमति नहीं है.
सुरक्षित सीएसपी के लिए अतिरिक्त सुझाव
बेहतर सुरक्षा और साथ काम करने के लिए, यहां दिए गए तरीके अपनाएं. अगर सीएसपी किसी एक सुझाव का पालन नहीं करता है, तो लाइटहाउस से मध्यम गंभीरता वाली चेतावनी दिखेगी.
सीएसपी रिपोर्टिंग को कॉन्फ़िगर करें
रिपोर्टिंग डेस्टिनेशन कॉन्फ़िगर करने से, किसी भी गड़बड़ी पर नज़र रखने में मदद मिलेगी. report-uri
या report-to
डायरेक्टिव का इस्तेमाल करके, रिपोर्टिंग डेस्टिनेशन सेट किया जा सकता है. फ़िलहाल, report-to
सभी मॉडर्न ब्राउज़र पर काम नहीं करता. इसलिए, आपको दोनों या सिर्फ़ report-uri
का इस्तेमाल करने का सुझाव दिया जाता है.
अगर कोई कॉन्टेंट, सीएसपी का उल्लंघन करता है, तो ब्राउज़र कॉन्फ़िगर किए गए डेस्टिनेशन पर रिपोर्ट भेजेगा. पक्का करें कि आपके पास इस डेस्टिनेशन पर, इन रिपोर्ट को मैनेज करने वाला ऐप्लिकेशन कॉन्फ़िगर किया गया हो.
एचटीटीपी हेडर में सीएसपी के बारे में जानकारी दें
सीएसपी को इस तरह के मेटा टैग में तय किया जा सकता है:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
हालांकि, अगर हो सके, तो आपको एचटीटीपी रिस्पॉन्स हेडर में सीएसपी तय करना चाहिए. मेटा टैग से पहले लगाया गया इंजेक्शन, सीएसपी को बायपास कर देगा. इसके अलावा, मेटा टैग सीएसपी में frame-ancestors
, sandbox
, और रिपोर्टिंग की सुविधा काम नहीं करती.
पक्का करें कि सीएसपी, पुराने सिस्टम के साथ काम करता हो
सभी ब्राउज़र सीएसपी नॉन्स/हैश के साथ काम नहीं करते हैं. इसलिए, नीतियों का पालन न करने वाले ब्राउज़र के लिए unsafe-inline
को फ़ॉलबैक के तौर पर जोड़ने का सुझाव दिया जाता है. अगर ब्राउज़र नॉन्स/हैश के साथ काम करता है, तो unsafe-inline
को अनदेखा कर दिया जाएगा.
इसी तरह, strict-dynamic
सभी ब्राउज़र पर काम नहीं करता. हमारा सुझाव है कि नीति का पालन न करने वाले सभी ब्राउज़र के लिए, अनुमति वाली सूची को फ़ॉलबैक के तौर पर सेट करें. strict-dynamic
के साथ काम करने वाले ब्राउज़र में अनुमति वाली सूची को अनदेखा कर दिया जाएगा.
सख्त सीएसपी कैसे बनाएं
यहां नॉन्स-आधारित नीति के साथ सख्त सीएसपी का इस्तेमाल करने का एक उदाहरण दिया गया है.
सीएसपी:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
हर बार पेज लोड होने पर, random123
कोई भी base64 स्ट्रिंग जनरेट करने वाला सर्वर-साइड होगा. unsafe-inline
और https:
को नॉन्स और strict-dynamic
की वजह से, मॉडर्न ब्राउज़र में अनदेखा किया जाता है. सख्त सीएसपी का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, स्ट्रिक्ट सीएसपी गाइड देखें.
लाइटहाउस और सीएसपी इवैलुएटर का इस्तेमाल करके, संभावित बायपास के लिए सीएसपी की जांच की जा सकती है. अगर आपको मौजूदा पेजों में मौजूद डेटा में छेड़छाड़ किए बिना नए सीएसपी की जांच करनी है, तो Content-Security-Policy-Report-Only
को हेडर के नाम के तौर पर इस्तेमाल करके, 'रिपोर्ट-ओनली मोड' में सीएसपी की वैल्यू तय करें. इससे, report-to
और report-uri
के साथ कॉन्फ़िगर किए गए सभी रिपोर्टिंग डेस्टिनेशन पर सीएसपी के उल्लंघन की जानकारी भेजी जाएगी. हालांकि, इससे सीएसपी लागू नहीं होगा.