Toolypet
सुरक्षा उपकरण/CSP बिल्डर

CSP बिल्डर

Content-Security-Policy हेडर दृश्य रूप से बनाएं

प्रीसेट

डायरेक्टिव

Default fallback for other directives

Controls allowed JavaScript sources

Controls allowed CSS sources

Controls allowed image sources

Controls allowed font sources

Controls allowed fetch/XHR/WebSocket targets

Controls allowed iframe sources

Controls allowed plugin sources (Flash, etc.)

Restricts URLs for <base> element

Restricts form submission targets

Controls who can embed this page

Upgrade HTTP to HTTPS automatically

विकल्प

सक्षम होने पर, उल्लंघन रिपोर्ट किए जाते हैं लेकिन ब्लॉक नहीं किए जाते। परीक्षण के लिए उपयोगी।

जनरेट किया गया CSP हेडर

Content-Security-Policy: default-src 'self'

कार्यान्वयन उदाहरण

add_header Content-Security-Policy "default-src 'self'";
Header set Content-Security-Policy "default-src 'self'"
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

CSP बिल्डर गाइड

अपनी वेबसाइट की सुरक्षा के लिए Content-Security-Policy हेडर बनाना सीखें

Content-Security-Policy क्या है?

Content-Security-Policy (CSP) एक HTTP रिस्पॉन्स हेडर है जो क्रॉस-साइट स्क्रिप्टिंग (XSS), क्लिकजैकिंग और अन्य कोड इंजेक्शन हमलों को रोकने में मदद करता है। यह आपको निर्दिष्ट करने की अनुमति देता है कि आपकी वेबसाइट पर कौन से स्रोतों से सामग्री लोड की जा सकती है, स्क्रिप्ट, स्टाइल, इमेज और अन्य संसाधनों पर विस्तृत नियंत्रण प्रदान करता है।

कैसे उपयोग करें

  1. शुरुआती बिंदु के रूप में एक प्रीसेट (सख्त, मध्यम, या ढीला) चुनें
  2. अपनी आवश्यकताओं के आधार पर व्यक्तिगत डायरेक्टिव सक्षम और कॉन्फ़िगर करें
  3. सुरक्षा चेतावनियों की समीक्षा करें और तदनुसार सेटिंग्स समायोजित करें
  4. जनरेट किए गए हेडर को कॉपी करें और अपने वेब सर्वर कॉन्फ़िगरेशन में जोड़ें

सर्वोत्तम प्रथाएं

अक्सर पूछे जाने वाले प्रश्न

अगर मैं CSP बहुत सख्त सेट करूं तो क्या होगा?

यदि आपका CSP बहुत सख्त है, तो वैध संसाधन ब्लॉक हो सकते हैं, जिससे आपकी वेबसाइट की कार्यक्षमता टूट सकती है। इसलिए केवल रिपोर्ट मोड से शुरू करने की सिफारिश की जाती है। इस मोड में, उल्लंघन आपके सर्वर को रिपोर्ट किए जाते हैं (यदि आप report-uri कॉन्फ़िगर करते हैं) लेकिन वास्तव में ब्लॉक नहीं किए जाते, जिससे आप नीति लागू करने से पहले समस्याओं की पहचान कर सकते हैं।

'self' और 'none' में क्या अंतर है?

'self' केवल आपकी वेबसाइट के समान मूल (समान प्रोटोकॉल, होस्ट और पोर्ट) से सामग्री की अनुमति देता है। 'none' उस प्रकार की सभी सामग्री को ब्लॉक करता है। उदाहरण के लिए, object-src 'none' सभी प्लगइन (Flash, Java, आदि) को लोड होने से रोकता है, जो एक सुरक्षा सर्वोत्तम प्रथा है।

'unsafe-inline' को खतरनाक क्यों माना जाता है?

'unsafe-inline' इनलाइन स्क्रिप्ट और स्टाइल की अनुमति देता है, जो CSP की अधिकांश XSS सुरक्षा को निष्क्रिय कर देता है। HTML इंजेक्ट करने में सक्षम हमलावर इनलाइन स्क्रिप्ट भी इंजेक्ट कर सकते हैं। इसके बजाय, इंजेक्ट किए गए को ब्लॉक करते हुए विशिष्ट इनलाइन स्क्रिप्ट की अनुमति देने के लिए nonce (script-src 'nonce-random123') या hash (script-src 'sha256-...') का उपयोग करें।

Google Analytics या अन्य तृतीय-पक्ष स्क्रिप्ट को कैसे अनुमति दें?

अपने script-src डायरेक्टिव में विशिष्ट डोमेन जोड़ें। Google Analytics के लिए, आपको इसकी आवश्यकता हो सकती है: script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com। API कॉल के लिए connect-src और ट्रैकिंग पिक्सल के लिए img-src में भी उनके डोमेन जोड़ें।

क्या CSP अन्य सुरक्षा हेडर को बदल सकता है?

नहीं, CSP अन्य सुरक्षा हेडर का पूरक है। आपको यह भी उपयोग करना चाहिए: X-Content-Type-Options: nosniff, X-Frame-Options (हालांकि CSP में frame-ancestors इसे बदल सकता है), X-XSS-Protection, Strict-Transport-Security (HSTS), और Referrer-Policy। प्रत्येक हेडर विभिन्न सुरक्षा चिंताओं को संबोधित करता है।