डेवलपर / सुरक्षा नीति
CSP जनरेटर: Content Security Policies बनाएं और उनका विश्लेषण करें
स्रोत सूचियों, nonce और hash placeholders, रिपोर्टिंग डायरेक्टिव और सामान्य प्रीसेट के साथ Content-Security-Policy header बनाएं। चेतावनियां देखें और HTTP, meta, nginx, Apache या static _headers आउटपुट कॉपी करें।
CSP जनरेटर: Content Security Policies बनाएं और उनका विश्लेषण करें: यह स्थानीय रूप से policy बनाता है और unsafe-inline, unsafe-eval, व्यापक sources, duplicate directives और deployment placeholders को चिह्नित करता है। parser अज्ञात directives को सुरक्षित रखता है और दोहराए गए directive की पहली occurrence का उपयोग करता है। यह एक समय में एक policy का विश्लेषण करता है और protected page को लोड नहीं करता। यह आपके ब्राउज़र में 100% स्थानीय रूप से चलता है और सर्वर पर कोई फ़ाइल अपलोड नहीं होती।
- श्रेणी
- डेवलपर टूल्स
- रन
- आपके ब्राउज़र में
- लागत
- मुफ़्त · साइन अप की ज़रूरत नहीं
- उपलब्धता
- इस्तेमाल के लिए तैयार
पूरी तरह आपके ब्राउज़र में चलता है
Presets मौजूदा नीति को बदल देते हैं। पहले report-only header के साथ परीक्षण करें। Nonce placeholder के लिए server integration ज़रूरी है; static header नया nonce generate नहीं कर सकता।
script-src · strict-dynamic के लिए मान्य nonce या hash ज़रूरी है और यह supporting browsers में host allowlists को ओवरराइड करता है।
script-src · Deployment से पहले nonce और hash placeholders बदलें। हर response के लिए नया, अप्रत्याशित nonce generate करें।
Meta नीतियाँ frame-ancestors या sandbox लागू नहीं कर सकतीं, report-uri का उपयोग नहीं कर सकतीं या report-only नीति भेज नहीं सकतीं। रिपोर्टिंग directives यहाँ शामिल नहीं हैं।
यह syntax और risk review है, security audit नहीं। अज्ञात या गलत तरीके से बने source expressions का browser testing ज़रूरी है। Additional policies एक साथ लागू होती हैं और पहले की policy को शिथिल नहीं कर सकतीं। बनाई गई _headers file static responses के लिए है; dynamic responses के लिए अपनी header configuration चाहिए।
Policy syntax और delivery
W3C Content Security Policy Level 3: https://www.w3.org/TR/CSP3/ . Directives को semicolons और values को whitespace से अलग किया जाता है। Meta delivery में HTTP response header की तुलना में कम क्षमताएँ होती हैं।
Nonces, hashes और deployment
MDN Content Security Policy guide: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP . strict-dynamic किसी nonce- या hash-authorised script का भरोसा, उसके द्वारा लोड की गई scripts को देता है और supporting browsers में host allowlists को ओवरराइड करता है। विश्वसनीय script के व्यवहार का audit करें और अंतिम policy का परीक्षण करें।
इस्तेमाल करने का तरीका
- कोई प्रीसेट चुनें या मौजूदा policy पेस्ट करें।
- डायरेक्टिव सक्षम करें और space-separated मान संपादित करें; चेतावनियां देखें।
- आउटपुट फ़ॉर्मैट चुनें, उसे कॉपी करें और अपनी साइट के resources पर टेस्ट करें।
गोपनीयता और सीमाएँ
आपकी policy आपके ब्राउज़र में रहती है। किसी वेबसाइट से संपर्क नहीं किया जाता।
संबंधित टूल्स
अक्सर पूछे जाने वाले सवाल
क्या मैं nonce placeholder को जैसा है वैसा इस्तेमाल कर सकता हूं?
नहीं। हर response के लिए एक अप्रत्याशित nonce बनाएं और trusted scripts में उसका matching value डालें। एक fixed static header nonce generate नहीं कर सकता। Hash placeholders को इच्छित content के वास्तविक hash से बदलें।
Meta policy क्या नहीं कर सकती?
यह frame-ancestors या sandbox को लागू नहीं कर सकती, report-uri का उपयोग नहीं कर सकती और report-only policy deliver नहीं कर सकती। Generated meta output में reporting directives शामिल नहीं होते और इसे document head में जल्दी रखना ज़रूरी है।
क्या report-to reporting endpoint बनाता है?
नहीं। यह एक ऐसे group का नाम देता है जिसके लिए अलग Reporting-Endpoints response header की ज़रूरत होती है। report-uri पुराना है; browser support अलग-अलग हो सकता है। यह टूल reports नहीं भेजता।
क्या presets के मेरी वेबसाइट के साथ काम करने की गारंटी है?
नहीं। शुरुआत report-only HTTP delivery से करें और अपनी साइट के लिए ज़रूरी resources जांचें। Existing policies नई policy के साथ combine होती हैं; दूसरी policy पहले से लागू restriction को कम नहीं कर सकती। Static _headers delivery dynamically generated responses को cover नहीं करती।
मुफ़्त टूल · आपके ब्राउज़र में बार चलता है · अकाउंट की ज़रूरत नहीं