Content Security Policy बिल्डर

एक HTTP हेडर जो यह नियंत्रित करता है कि ब्राउज़र कौन-से संसाधन लोड कर सकता है, जिससे XSS और डेटा इंजेक्शन हमले रोके जाते हैं।

लागू मोड उल्लंघनों को रोकता है। केवल-रिपोर्ट मोड उन्हें अनुमति देता है लेकिन रिपोर्ट करता है — लागू करने से पहले परीक्षण के लिए उपयोगी।

unsafe-inline शोषण योग्य इनलाइन स्क्रिप्ट की अनुमति देता है। unsafe-eval डायनामिक कोड निष्पादन को सक्षम करता है। दोनों CSP सुरक्षा को काफ़ी कमज़ोर कर देते हैं।

हाँ, Content Security Policy Builder 100% मुफ़्त है — बिना किसी पंजीकरण, छिपे शुल्क या उपयोग सीमा के। सारी प्रोसेसिंग आपके ब्राउज़र में स्थानीय रूप से होती है, जिससे पूर्ण गोपनीयता सुनिश्चित होती है।

हाँ, Content Security Policy Builder पूरी तरह रिस्पॉन्सिव है और स्मार्टफ़ोन तथा टैबलेट पर काम करता है। आप इसे आधुनिक वेब ब्राउज़र वाले किसी भी डिवाइस पर इस्तेमाल कर सकते हैं — किसी ऐप डाउनलोड की ज़रूरत नहीं।

किसी खाते या पंजीकरण की आवश्यकता नहीं है। बस अपने ब्राउज़र में Content Security Policy Builder खोलें और तुरंत इसका उपयोग शुरू करें। कोई साइन-अप बाधा या उपयोग की सीमा नहीं है।

बस दिए गए फ़ील्ड में अपना इनपुट दर्ज करें, अपनी पसंद के अनुसार कोई भी सेटिंग समायोजित करें, और टूल इसे तुरंत संसाधित कर देगा। फिर आप परिणाम को क्लिपबोर्ड पर कॉपी कर सकते हैं या डाउनलोड कर सकते हैं।

Content Security Policy Builder Chrome, Firefox, Safari, Edge और Opera सहित सभी आधुनिक ब्राउज़र में काम करता है। सर्वोत्तम अनुभव के लिए, अपने पसंदीदा ब्राउज़र के नवीनतम संस्करण का उपयोग करें।

default-src एक फॉलबैक डायरेक्टिव है: यह हर उस रिसोर्स टाइप के लिए अनुमति-प्राप्त सोर्स तय करता है जिसे आपने स्पष्ट रूप से कॉन्फ़िगर नहीं किया है, इसलिए इसे 'none' या 'self' पर लॉक करने से एक deny-by-default बेसलाइन बनती है। script-src एक खास ओवरराइड है जो सिर्फ यह तय करता है कि JavaScript कहां से लोड हो सकती है, और स्क्रिप्ट्स के मामले में यह default-src पर प्राथमिकता रखता है। चूंकि स्क्रिप्ट्स क्रॉस-साइट स्क्रिप्टिंग का मुख्य ज़रिया हैं, इसलिए भले ही default-src पहले से प्रतिबंधात्मक हो, फिर भी आपको लगभग हमेशा एक टाइट script-src चाहिए होता है — उदाहरण के लिए default-src 'self' के साथ एक अलग script-src 'self' जिसमें nonce जोड़ा गया हो। style-src, img-src, और connect-src जैसी बाकी per-type डायरेक्टिव्स भी इसी तरह काम करती हैं, एक रिसोर्स टाइप को संकुचित करती हैं जबकि default-src बाकी को कवर करता है। यह बिल्डर आपको default-src एक बार सेट करने और सिर्फ ज़रूरत पड़ने पर अलग-अलग डायरेक्टिव्स ओवरराइड करने देता है।

Nginx में आप server या location ब्लॉक के अंदर add_header Content-Security-Policy "आपकी पॉलिसी यहां" always; जोड़ते हैं; always फ्लैग यह सुनिश्चित करता है कि हेडर 404 जैसे एरर रिस्पॉन्स पर भी भेजा जाए। Apache में आप संबंधित VirtualHost या .htaccess के अंदर Header set Content-Security-Policy "आपकी पॉलिसी यहां" इस्तेमाल करते हैं, और mod_headers इनेबल होना चाहिए। दोनों मामलों में वैल्यू पूरी डायरेक्टिव स्ट्रिंग होती है, और असर के लिए आपको सर्वर रीलोड करना पड़ता है। हाथ से सिंटैक्स बिल्कुल सही करना गलती-प्रवण होता है, इसलिए यह बिल्डर आपके कॉन्फ़िगर की गई पॉलिसी से Nginx, Apache, Express.js, और Next.js के लिए तैयार कॉपी-पेस्ट स्निपेट्स जनरेट करता है। अपनी डायरेक्टिव्स विज़ुअली बनाएं, अपना सर्वर चुनें, और जनरेट हुए ब्लॉक को सीधे अपने कॉन्फ़िग में पेस्ट करें।

CSP दो तरीकों से भेजी जा सकती है: एक Content-Security-Policy HTTP रिस्पॉन्स हेडर के रूप में, या पेज के head में एक HTML <meta http-equiv="Content-Security-Policy"> टैग के रूप में। meta-टैग तरीका तब सुविधाजनक होता है जब आप सर्वर कॉन्फ़िग एडिट नहीं कर सकते, लेकिन स्पेसिफिकेशन जानबूझकर उस संदर्भ में कुछ खास डायरेक्टिव्स को नज़रअंदाज़ करती है। frame-ancestors, report-uri, report-to, और sandbox सिर्फ तभी काम करते हैं जब असल HTTP हेडर के रूप में भेजे जाएं, क्योंकि इन्हें पेज रेंडर होने से पहले पता होना ज़रूरी है या ये रिस्पॉन्स-लेवल रिपोर्टिंग से जुड़े होते हैं। अगर क्लिकजैकिंग से सुरक्षा आपके लिए मायने रखती है, तो frame-ancestors हेडर से ही आना चाहिए, meta टैग से नहीं। यह बिल्डर आपको हेडर और meta आउटपुट फॉर्मेट के बीच स्विच करने देता है और चेतावनी देता है कि meta मोड में कौन-सी डायरेक्टिव्स छूट जाती हैं, ताकि आप ऐसी पॉलिसी न भेजें जो चुपचाप अपनी एंटी-क्लिकजैकिंग सुरक्षा खो दे।

हर बदलाव के साथ 100 में से एक स्ट्रिक्टनेस स्कोर दोबारा कैलकुलेट होता है, जो Weak, Fair, Good, या Excellent में ग्रेड होता है। यह स्कोर सिर्फ पॉलिसी के होने भर से नहीं, बल्कि सच में सुरक्षा देने वाले चुनावों से मिलता है। सबसे ज़्यादा पॉइंट्स आपको एक प्रतिबंधात्मक default-src ('none', 'self' से बेहतर है), unsafe-inline या unsafe-eval कीवर्ड्स से मुक्त script-src, object-src 'none', और परिभाषित frame-ancestors के लिए मिलते हैं। base-uri, form-action, एक साफ-सुथरा style-src, और दूसरी संकुचित करने वाली डायरेक्टिव्स जोड़ने से नंबर और बढ़ता है, जबकि wildcard सोर्स और unsafe कीवर्ड्स इसे नीचे रखते हैं। रिपोर्ट-ओनली मोड इनेबल करने से स्कोर थोड़ा कम हो जाता है, क्योंकि रिपोर्ट-ओनली हेडर एनफोर्समेंट लागू करने तक कोई असल ब्लॉकिंग नहीं करता। Analysis टैब बताता है कि आपके स्कोर के पीछे बिल्कुल क्या वजह है, ताकि आप देख सकें कि Good से Excellent तक जाने के लिए किन कमज़ोरियों को ठीक करना है।

nonce एक रैंडम टोकन है जिसे आपका सर्वर हर पेज लोड पर जनरेट करता है और इसे CSP में तथा हर भरोसेमंद <script> टैग पर लगाता है; ब्राउज़र सिर्फ मैचिंग nonce वाली स्क्रिप्ट्स ही चलाता है। hash भी ऐसे ही काम करता है लेकिन यह किसी खास इनलाइन स्क्रिप्ट को उसके sha256 फिंगरप्रिंट से पहचानता है, जिसमें per-request टोकन की ज़रूरत नहीं होती। दोनों आपको ज़रूरी इनलाइन स्क्रिप्ट्स रखते हुए 'unsafe-inline' हटाने देते हैं, जो वरना किसी भी इंजेक्ट की गई इनलाइन स्क्रिप्ट को चलने देकर आपकी XSS सुरक्षा को बेकार कर देता है। nonce को 'strict-dynamic' के साथ जोड़ने से भरोसेमंद स्क्रिप्ट्स हर डोमेन को व्हाइटलिस्ट किए बिना अपनी खुद की डिपेंडेंसी लोड कर पाती हैं। यह बिल्डर nonce और sha256 प्लेसहोल्डर सोर्स वैल्यू शामिल करता है और unsafe-inline से nonce- या hash-आधारित तरीके पर स्विच करने की सलाह देता है। यहां nonce प्लेसहोल्डर के साथ script-src कॉन्फ़िगर करें, फिर अपने सर्वर पर असली टोकन जोड़ें।