मुफ़्त CSP हेडर जनरेटर
अपनी वेबसाइट के लिए Content Security Policy हेडर बनाएँ। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में काम करता है, बिना साइन-अप के।
अपडेट किया गया
CSP Generator
Build Content Security Policy headers interactively with presets, directive builder, nonce support, and strictness scoring.
CSP Builder
Directives
default-srcFallback for other fetch directives
script-srcValid sources for JavaScript
style-srcValid sources for stylesheets
img-srcValid sources for images
font-srcValid sources for fonts
connect-srcValid targets for fetch, XHR, WebSocket
object-srcValid sources for plugins (Flash, etc.)
frame-ancestorsValid parents that can embed this page
अक्सर पूछे जाने वाले प्रश्न
CSP जनरेटर क्या है?
CSP जनरेटर एक मुफ़्त ऑनलाइन टूल है जो आपकी वेबसाइट को XSS, clickjacking और अन्य इंजेक्शन हमलों से सुरक्षित रखने के लिए Content Security Policy हेडर बनाता है।
क्या CSP जनरेटर मुफ़्त है?
हाँ, यह पूरी तरह से मुफ़्त है और इसके लिए किसी पंजीकरण की आवश्यकता नहीं है। सारा नीति निर्माण आपके ब्राउज़र में क्लाइंट-साइड पर ही होता है।
मुझे Content Security Policy की आवश्यकता क्यों है?
एक CSP ब्राउज़रों को बताती है कि कौन-से कंटेंट स्रोत भरोसेमंद हैं, जिससे दुर्भावनापूर्ण स्क्रिप्ट अवरुद्ध हो जाती हैं और आपकी वेबसाइट पर cross-site scripting (XSS) हमलों का जोखिम कम हो जाता है।
क्या इस टूल के साथ मेरा डेटा सुरक्षित है?
बिल्कुल। CSP हेडर जनरेटर सब कुछ आपके ब्राउज़र में क्लाइंट-साइड पर ही प्रोसेस करता है। कोई भी डेटा किसी सर्वर पर अपलोड या संग्रहीत नहीं किया जाता। आपकी सामग्री हर समय आपके डिवाइस पर निजी बनी रहती है।
क्या CSP हेडर जनरेटर मोबाइल डिवाइस पर काम करता है?
हाँ, CSP हेडर जनरेटर पूरी तरह से रिस्पॉन्सिव है और स्मार्टफ़ोन तथा टैबलेट पर काम करता है। आप इसे किसी भी आधुनिक वेब ब्राउज़र वाले डिवाइस पर इस्तेमाल कर सकते हैं -- किसी ऐप को डाउनलोड करने की ज़रूरत नहीं।
क्या इस टूल का उपयोग करने के लिए मुझे खाता बनाना होगा?
किसी खाते या पंजीकरण की आवश्यकता नहीं है। बस अपने ब्राउज़र में CSP हेडर जनरेटर खोलें और तुरंत इसका उपयोग शुरू करें। कोई साइन-अप बाधा या उपयोग प्रतिबंध नहीं है।
मैं CSP हेडर जनरेटर का उपयोग कैसे करूँ?
बस दिए गए फ़ील्ड में अपना इनपुट दर्ज करें, अपनी पसंद के अनुसार सेटिंग्स समायोजित करें, और टूल इसे तुरंत प्रोसेस कर देगा। इसके बाद आप परिणाम को अपने क्लिपबोर्ड पर कॉपी कर सकते हैं या डाउनलोड कर सकते हैं।
कौन-कौन से ब्राउज़र समर्थित हैं?
CSP हेडर जनरेटर Chrome, Firefox, Safari, Edge और Opera सहित सभी आधुनिक ब्राउज़रों में काम करता है। सर्वोत्तम अनुभव के लिए, अपने पसंदीदा ब्राउज़र के नवीनतम संस्करण का उपयोग करें।
CSP में 'self', 'none', और 'unsafe-inline' के बीच क्या अंतर है?
ये CSP सोर्स कीवर्ड हैं जो ब्राउज़र को बताते हैं कि कोई डायरेक्टिव किस कंटेंट की अनुमति देता है। 'self' सिर्फ आपके अपने ओरिजिन (समान scheme, host, और port) से रिसोर्स लोड करने की अनुमति देता है, इसलिए script-src में 'self' सेट करने पर आपकी अपनी स्क्रिप्ट तो चलती हैं लेकिन थर्ड-पार्टी स्क्रिप्ट ब्लॉक हो जाती हैं। 'none' सबसे सख्त वैल्यू है: यह उस डायरेक्टिव के लिए हर स्रोत को ब्लॉक कर देता है, यही वजह है कि object-src 'none' एक आम हार्डनिंग कदम है। 'unsafe-inline' आपके HTML में सीधे लिखी इनलाइन स्क्रिप्ट और स्टाइल को फिर से चालू कर देता है, और 'unsafe-eval', eval() आधारित कोड की अनुमति देता है; दोनों सुविधाजनक हैं लेकिन वही XSS का रास्ता फिर से खोल देते हैं जिसे बंद करने के लिए CSP बनाया गया है, इसलिए जहां संभव हो वहां nonce या hash का इस्तेमाल करें। यह जेनरेटर आपको इन कीवर्ड को सीधे हर डायरेक्टिव पर क्लिक करने देता है और दिखाता है कि हर विकल्प आपके स्ट्रिक्टनेस स्कोर को कैसे बदलता है, ताकि पॉलिसी बनाते समय आप सुरक्षा का ट्रेड-ऑफ साफ देख सकें।
मेरी Content Security Policy HTML meta टैग में काम क्यों नहीं करती?
जब CSP को असली HTTP रिस्पॉन्स हेडर की बजाय HTML meta टैग के ज़रिए डिलीवर किया जाता है, तो कुछ डायरेक्टिव को बस अनदेखा कर दिया जाता है। frame-ancestors डायरेक्टिव, जो यह नियंत्रित करके क्लिकजैकिंग रोकता है कि आपके पेज को कौन एम्बेड कर सकता है, सिर्फ हेडर के रूप में काम करता है क्योंकि फ्रेमिंग का फैसला दस्तावेज़ के meta टैग पढ़ने से पहले ही हो जाता है। उल्लंघन रिपोर्ट इकट्ठा करने वाला report-uri डायरेक्टिव और sandbox डायरेक्टिव भी इसी वजह से meta फ़ॉर्म में अनदेखे कर दिए जाते हैं। इसलिए अगर आपके एंटी-क्लिकजैकिंग या रिपोर्टिंग नियम कुछ भी नहीं कर रहे लगते हैं, तो अक्सर यही वजह होती है। जहां भी आपके पास सर्वर कॉन्फ़िगरेशन का नियंत्रण हो, वहां HTTP हेडर को प्राथमिकता दें। यह टूल अपने Output व्यू में ठीक यही सीमा दिखाता है और कच्चा Content-Security-Policy हेडर, साथ ही Nginx, Apache, Express.js और Next.js के लिए तुरंत पेस्ट करने लायक कॉन्फ़िग ब्लॉक देता है ताकि आप इसे सही तरीके से डिप्लॉय कर सकें।
किसी खास इनलाइन स्क्रिप्ट को सुरक्षित रूप से अनुमति देने के लिए CSP nonce का उपयोग कैसे करें?
nonce एक रैंडम, सिंगल-यूज़ टोकन है जो 'unsafe-inline' का रास्ता खोले बिना आपको किसी एक खास इनलाइन स्क्रिप्ट पर भरोसा करने देता है। आप अपने script-src डायरेक्टिव में 'nonce-{random}' वैल्यू जोड़ते हैं, फिर जिस script टैग को अनुमति देनी है उस पर मिलता-जुलता nonce एट्रिब्यूट लगाते हैं, जैसे <script nonce="{random}">। ब्राउज़र सिर्फ वही इनलाइन स्क्रिप्ट चलाता है जिसमें बिल्कुल वही टोकन हो और बाकी हर इंजेक्ट की गई स्क्रिप्ट ब्लॉक कर देता है, इसलिए जो हमलावर उस वैल्यू का अंदाज़ा नहीं लगा सकता वह अपना पेलोड चला नहीं सकता। सबसे ज़रूरी नियम यह है कि nonce को हर पेज लोड पर नए सिरे से जनरेट किया जाना चाहिए, कभी हार्ड-कोड या दोबारा इस्तेमाल नहीं किया जाना चाहिए। यह जेनरेटर ब्राउज़र के crypto.getRandomValues() API से एक क्रिप्टोग्राफ़िक रूप से मज़बूत nonce बनाता है और आपको फ़ॉर्मेट किया हुआ 'nonce-...' स्ट्रिंग देता है ताकि आप इसे अपनी पॉलिसी और script टैग दोनों में कॉपी कर सकें।
report-only मोड और CSP को लागू करने (enforce करने) में क्या अंतर है?
बहुत सख्त पॉलिसी चुपचाप वैध स्क्रिप्ट, स्टाइल या API कॉल को ब्लॉक कर सकती है, इसलिए CSP को सीधे enforcement में डिप्लॉय करना जोखिम भरा है। report-only मोड यह समस्या हल करता है। पॉलिसी को Content-Security-Policy की बजाय Content-Security-Policy-Report-Only हेडर के रूप में भेजने पर ब्राउज़र कुछ भी ब्लॉक नहीं करता; वह सिर्फ हर उस उल्लंघन को लॉग करता है जो उसने कराया होता, और उसका विवरण आपके report-uri एंडपॉइंट पर भेजता है। इससे आप असली ट्रैफ़िक देख सकते हैं, यह पता लगा सकते हैं कि कौन से रिसोर्स पॉलिसी से टकरा रहे हैं, और किसी यूज़र को टूटा हुआ पेज दिखने से पहले ही नियम ठीक कर सकते हैं। मानक और सुरक्षित तरीका यह है कि पहले report-only में डिप्लॉय करें, जब तक रिपोर्ट शांत न हो जाएं तब तक निगरानी करें, फिर enforcing हेडर पर स्विच करें। इस टूल के बिल्डर से पॉलिसी बनाएं और उसे ट्यून करें, और enforcement पर जाने से पहले खास URL को अपने डायरेक्टिव के खिलाफ जांचने के लिए Test व्यू का इस्तेमाल करें।
WordPress या सिंगल-पेज ऐप के लिए मुझे कौन-सा CSP प्रीसेट अपनाना चाहिए?
शुरुआत से पॉलिसी बनाने की बजाय एक समझदारी भरी बेसलाइन चुनना तेज़ और ज़्यादा सुरक्षित है, और सही शुरुआती बिंदु आपके स्टैक पर निर्भर करता है। WordPress प्रीसेट ज़्यादा उदार है क्योंकि थीम और प्लगइन अक्सर इनलाइन स्क्रिप्ट और स्टाइल इंजेक्ट करते हैं, इसलिए यह 'unsafe-inline' और YouTube व Vimeo जैसे आम एम्बेड सोर्स को अनुमति देता है ताकि डैशबोर्ड और फ्रंट एंड टूटने न पाएं। SPA प्रीसेट React, Vue, या Angular बिल्ड्स के लिए उपयुक्त है: यह script-src को 'self' पर सख्त रखता है, blob वर्कर्स के लिए worker-src जोड़ता है, और आपके API व WebSocket एंडपॉइंट के लिए connect-src खोलता है। इसके अलावा Strict, Moderate, और Relaxed प्रीसेट भी हैं जो पूरी तरह कड़े से लेकर ढीले तक की रेंज को कवर करते हैं। इस टूल में सबसे नज़दीकी प्रीसेट लागू करें, फिर अपने असली थर्ड-पार्टी डोमेन के अनुसार अलग-अलग डायरेक्टिव को घटाएं या बढ़ाएं, जबकि लाइव स्ट्रिक्टनेस स्कोर आपको एक कड़ी पॉलिसी की तरफ़ मार्गदर्शन करता रहे।
संबंधित टूल
मुफ़्त हैश वेरिफ़ायर ऑनलाइन
हैश चेकसम की तुलना करके फ़ाइल की अखंडता सत्यापित करें। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में, बिना साइन-अप के।
मुफ़्त सिक्योरिटी हेडर विश्लेषक
वेबसाइट के सिक्योरिटी हेडर जाँचें और सुधार के सुझाव पाएँ। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में काम करता है, बिना साइन-अप के।
मुफ़्त एन्क्रिप्शन/डिक्रिप्शन टूल
AES, DES और अन्य एल्गोरिद्म से टेक्स्ट एन्क्रिप्ट और डिक्रिप्ट करें। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में काम करता है, बिना साइन-अप के।
मुफ़्त HMAC जनरेटर ऑनलाइन
कई हैशिंग एल्गोरिद्म का उपयोग करके API प्रमाणीकरण के लिए HMAC हस्ताक्षर बनाएँ। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में काम करता है, बिना साइन-अप के।
CSP हेडर जेनरेटर के बारे में
CSP हेडर जेनरेटर एक फ्री टूल है जो Content Security Policy बनाने में मदद करता है — यह वह HTTP रिस्पॉन्स हेडर है जो ब्राउज़र को बताता है कि आपके पेज पर स्क्रिप्ट, स्टाइल, इमेज, फ़ॉन्ट और अन्य रिसोर्स किन स्रोतों से लोड किए जा सकते हैं। एक सही ढंग से बनाई गई पॉलिसी cross-site scripting (XSS) के खिलाफ सबसे मज़बूत सुरक्षाओं में से एक है, क्योंकि यह ब्राउज़र को ऐसी इंजेक्ट की गई या थर्ड-पार्टी स्क्रिप्ट चलाने से रोकती है जिन्हें आपने कभी अनुमति नहीं दी। यह टूल वेब डेवलपर्स, साइट ओनर्स और सिक्योरिटी इंजीनियर्स के लिए बनाया गया है जो सिंटैक्स रटे बिना एक सही पॉलिसी चाहते हैं।
सब कुछ आपके ब्राउज़र में ही होता है। न कोई साइन-अप, न कोई अपलोड, और सर्वर पर कुछ भी नहीं भेजा जाता — आप अपनी ही डिवाइस पर पॉलिसी तैयार करते हैं और नतीजा कॉपी कर लेते हैं। यह क्लाइंट-साइड डिज़ाइन यह भी सुनिश्चित करता है कि पेज लोड होते ही टूल इस्तेमाल के लिए तैयार हो जाए।
डायरेक्टिव-दर-डायरेक्टिव पॉलिसी बनाएं
आप हर एक तरह के रिसोर्स को नियंत्रित करने वाले अलग-अलग डायरेक्टिव से मिलकर पॉलिसी बनाते हैं। यह बिल्डर CSP Level 1 से 3 तक के 15 डायरेक्टिव सपोर्ट करता है, जिनमें default-src, script-src, style-src, img-src, font-src, connect-src, frame-ancestors, base-uri, form-action, और worker-src व manifest-src जैसे नए जोड़े गए डायरेक्टिव शामिल हैं। हर डायरेक्टिव के लिए आप सोर्स वैल्यू जोड़ते हैं — या तो 'self', 'none', data:, या https: जैसे सामान्य सुझावों पर क्लिक करके, या खुद कोई कस्टम ओरिजिन टाइप करके। अगर आप किसी भरोसेमंद बेसलाइन से शुरुआत करना चाहते हैं, तो पांच प्रीसेट बस एक क्लिक दूर हैं: Strict, Moderate, Relaxed, WordPress, और SPA।
खास इनलाइन स्क्रिप्ट को सुरक्षित तरीके से अनुमति देने के लिए, यह टूल ब्राउज़र के crypto.getRandomValues() API का उपयोग करके एक क्रिप्टोग्राफ़िक नॉन्स (nonce) भी जनरेट करता है, जिसे आप सीधे अपनी पॉलिसी और <script> टैग दोनों में इस्तेमाल कर सकते हैं।
काम करते-करते स्ट्रिक्टनेस स्कोर देखें
100 में से एक लाइव स्ट्रिक्टनेस स्कोर बताता है कि आपकी पॉलिसी कितनी कड़ी है। यह उन विकल्पों को सबसे ज़्यादा अंक देता है जो सबसे मायने रखते हैं: एक प्रतिबंधित default-src, 'unsafe-inline' और 'unsafe-eval' से मुक्त script-src, object-src 'none', स्पष्ट रूप से परिभाषित frame-ancestors, और उल्लंघन रिपोर्ट इकट्ठा करने के लिए report-uri। इन कीवर्ड को समझना ज़रूरी है:
'self'सिर्फ आपके अपने ओरिजिन से रिसोर्स को अनुमति देता है।'none'उस डायरेक्टिव के लिए हर स्रोत को ब्लॉक कर देता है।'unsafe-inline'और'unsafe-eval'इनलाइन औरeval()आधारित कोड का रास्ता फिर से खोल देते हैं — यह सुविधाजनक तो है, लेकिन CSP जो सुरक्षा देने के लिए बना है उसे कमज़ोर कर देता है।'strict-dynamic', नॉन्स और हैश खास स्क्रिप्ट पर भरोसा करने का आधुनिक और ज़्यादा सुरक्षित तरीका है।
यह स्कोर एक जल्दी लगने वाला अंदाज़ा है, कोई गारंटी नहीं, इसलिए इसे लागू करने से पहले असली पेजों पर अपनी पॉलिसी ज़रूर टेस्ट करें।
जिस फ़ॉर्मेट में डिप्लॉय करना है, उसी में आउटपुट कॉपी करें
एक बार जब पॉलिसी आपकी पसंद के अनुसार बन जाए, तो Output व्यू आपको तुरंत पेस्ट करने लायक स्निपेट देता है: कच्चा Content-Security-Policy: HTTP हेडर, एक HTML <meta> टैग, और Nginx, Apache, Express.js व Next.js के लिए सर्वर कॉन्फ़िग ब्लॉक। टूल एक याद दिलाने वाली बात भी दिखाता है: कुछ डायरेक्टिव — frame-ancestors, report-uri, और sandbox — सिर्फ असली HTTP हेडर के रूप में काम करते हैं और meta टैग के अंदर अनदेखा कर दिए जाते हैं, इसलिए जहां भी आपके पास सर्वर कॉन्फ़िगरेशन का नियंत्रण हो, हेडर को प्राथमिकता दें।
लागू करने से पहले टेस्ट करें
CSP से जुड़ी गड़बड़ियां आसानी से हो जाती हैं, क्योंकि बहुत ज़्यादा कड़ी पॉलिसी चुपचाप वैध रिसोर्स को भी ब्लॉक कर देती है। Test व्यू में आप एक URL पेस्ट कर सकते हैं — जैसे कोई CDN स्क्रिप्ट या एनालिटिक्स एंडपॉइंट — और देख सकते हैं कि आपकी मौजूदा पॉलिसी उसे डायरेक्टिव-दर-डायरेक्टिव अनुमति देगी या ब्लॉक करेगी। सामान्य उल्लंघन के कई उदाहरण भी दिखाए जाते हैं, जिनमें इनलाइन स्क्रिप्ट और इनलाइन स्टाइल से लेकर frame-ancestors द्वारा पकड़े गए क्लिकजैकिंग प्रयास तक शामिल हैं, और हर एक के साथ उसका समाधान भी दिया गया है। एक सुरक्षित रोलआउट तरीका यह है कि पहले report-only मोड में डिप्लॉय करें, देखें कि क्या-क्या ट्रिगर हो रहा है, और जब रिपोर्ट शांत हो जाएं तभी एनफ़ोर्समेंट पर स्विच करें।
ऊपर अपनी पॉलिसी बनाएं, स्ट्रिक्टनेस स्कोर को बढ़ते हुए देखें, और इसे उसी फ़ॉर्मेट में कॉपी करें जो आपके स्टैक से मेल खाता हो।