Defaults.Exposed › सुधार › Content-Security-Policy (CSP)

Content-Security-Policy (CSP) को कैसे ठीक करें

एक Content Security Policy एक सुरक्षा नियम है जो आपकी वेबसाइट हर विज़िटर के ब्राउज़र को देती है, जो उसे बताती है कि कौन सा कोड चलने की अनुमति है। इसके बिना, यदि कुछ भी दुर्भावनापूर्ण कभी किसी पेज पर आ जाता है — एक टिप्पणी बॉक्स, एक हैक किए गए प्लगइन, या एक तृतीय-पक्ष स्क्रिप्ट के माध्यम से — ब्राउज़र इसे स्वतंत्र रूप से चलाएगा, जिसमें कोड भी शामिल है जो चुपचाप आपके ग्राहकों के कार्ड नंबर और पासवर्ड को टाइप करते समय स्किम करता है, पैडलॉक अभी भी दिखाते हुए।

आपके व्यवसाय के लिए मुख्य बात: यदि आपकी साइट से कभी छेड़छाड़ की जाती है, तो दुर्भावनापूर्ण कोड आपके ग्राहकों के भुगतान-कार्ड और लॉगिन विवरण को आपके अपने चेकआउट से सीधे पढ़ सकता है जबकि सब कुछ पूरी तरह सामान्य दिखता है — आपको चार्जबैक, धोखाधड़ी के दावे, एक रिपोर्ट करने योग्य डेटा उल्लंघन, और एक जाँच विफलता के साथ छोड़ता है जिसे बड़े क्लाइंट की सुरक्षा टीम किसी सौदे को रोकने या मारने के लिए उपयोग करती है।

यह आपको क्या खर्च कर सकता है

छिपा हुआ कोड आपके एक पेज पर चुपचाप हर कार्ड नंबर और पासवर्ड की प्रतिलिपि बनाता है जो आपके ग्राहक चेकआउट पर दर्ज करते हैं, इसे एक हमलावर को रियल टाइम में भेजता है जबकि आपकी साइट पूरी तरह सामान्य दिखती और काम करती है।
एक घोटालेबाज आपकी वास्तविक वेबसाइट पर एक नकली 'यहाँ भुगतान करें' फ़ॉर्म लगाता है जो भुगतान अपने खाते में कैप्चर करता है; ग्राहकों को लगता है कि उन्होंने आपको भुगतान किया, जब सामान नहीं आता तो आपको दोष देते हैं।
एक बड़े क्लाइंट की सुरक्षा टीम आपकी साइट स्कैन करती है, देखती है कि यह बुनियादी सुरक्षा बंद है, और इसे फ्लैग करती है — जब तक आप साबित नहीं कर सकते कि यह ठीक है तब तक अनुबंध रोक देती है।
एक गायब मानक सुरक्षा उपाय पर आधारित उल्लंघन एक रिपोर्ट करने योग्य घटना बन जाता है: नियामक प्रश्न, ग्राहक सूचनाएं, और एक प्रतिष्ठा हानि।

यह क्यों मायने रखता है। पैडलॉक यह साबित करता है कि आपकी साइट का कनेक्शन निजी है, लेकिन एक बार विज़िटर पेज पर होने पर यह नियंत्रित नहीं करता कि क्या कोड चलता है। एक Content Security Policy वह सुरक्षा है जो करती है — यह ब्राउज़रों को किसी भी स्क्रिप्ट को अनदेखा करने के लिए कहती है जो किसी स्रोत से नहीं आई जिस पर आप भरोसा करते हैं। यह आपके स्कोरकार्ड पर एक ग्रेड की गई जाँच है, जो वास्तविक अंकों के योग्य है।

यह क्या है, सरल शब्दों में

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

एक Content Security Policy (अक्सर CSP के रूप में संक्षिप्त) नियमों की एक छोटी सूची है जिसे आपकी वेबसाइट हर पेज से जोड़ती है, ब्राउज़र को बताती है: “केवल इन स्रोतों से कोड चलाओ जिन्हें मैंने मंजूरी दी है, और बाकी सब कुछ अस्वीकार करो।” यह एक नाइटक्लब जो सभी को अंदर जाने देता है और एक गेस्ट लिस्ट वाले के बीच का अंतर है।

इससे आपको क्या नुकसान हो सकता है

यह अमूर्त नहीं है। जो हमला Content Security Policy रोकती है — कोड को पेज में इंजेक्ट किया जाता है जो आपके ग्राहकों से डेटा चुराता है — कुछ रिकॉर्ड पर सबसे बड़े कार्ड-स्किमिंग उल्लंघनों के पीछे है।

अदृश्य चेकआउट स्किमर। एक हमलावर एक कमजोर प्लगइन के माध्यम से आपके चेकआउट पेज पर कुछ कोड की लाइनें डाल देता है। आपके ग्राहकों का हर कार्ड नंबर, नाम, और CVV कॉपी होकर रियल टाइम में हमलावर को भेजा जाता है। आपकी साइट पूरी तरह दिखती और काम करती है; पैडलॉक वहाँ है। आपको हफ्तों बाद पता चलता है।
नकली भुगतान फ़ॉर्म। एक घोटालेबाज आपकी वास्तविक वेबसाइट पर एक विश्वसनीय “यहाँ भुगतान करें” बॉक्स इंजेक्ट करता है।
खोया हुआ अनुबंध। एक बड़े संभावित ग्राहक की सुरक्षा टीम विक्रेता उचित परिश्रम के हिस्से के रूप में आपकी साइट का एक स्वचालित स्कैन चलाती है। एक गायब Content Security Policy तुरंत उच्च-गंभीरता अंतराल के रूप में दिखाई देती है।
रिपोर्ट करने योग्य उल्लंघन। जब एक डेटा उल्लंघन एक गायब, मानक, मुफ्त सुरक्षा उपाय पर वापस आता है, तो यह बुरे भाग्य नहीं बल्कि लापरवाही की तरह दिखना शुरू होता है।
समझौता किया गया विज्ञापन या विजेट। यदि किसी तृतीय-पक्ष स्क्रिप्ट प्रदाता का उल्लंघन किया जाता है, तो दुर्भावनापूर्ण कोड सीधे आपके पेजों पर सवारी करता है।

यह वास्तव में क्या है (विवरण)

एक Content Security Policy एक एकल HTTP प्रतिक्रिया हेडर के रूप में वितरित की जाती है। इसका मूल्य निर्देशों का एक सेट है, प्रत्येक एक प्रकार की सामग्री और इसके लिए अनुमत स्रोतों का नामकरण करता है। उदाहरण के लिए:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

“अच्छा” कैसा दिखता है। एक मजबूत नीति:

एक प्रतिबंधात्मक आधार रेखा सेट करती है (default-src 'self') और केवल विशिष्ट विश्वसनीय तृतीय पक्षों के लिए इसे चौड़ा करती है।
लूपहोल से बचती है। स्क्रिप्ट के लिए 'unsafe-inline' या 'unsafe-eval' उपयोग नहीं करती।
frame-ancestors 'self' के साथ फ्रेमिंग बंद करती है और object-src 'none' के साथ लेगेसी प्लगइन को अक्षम करती है।
लागू करना, रिपोर्ट-केवल नहीं। एक Content-Security-Policy-Report-Only हेडर केवल देखता है; यह शून्य रनटाइम सुरक्षा प्रदान करता है।

इसे कैसे ठीक करें (मुफ्त, ~1–2 घंटे)

इसे अपने IT व्यक्ति या जो भी आपकी वेबसाइट चलाता है उसे सौंपें — ठीक करना बिल्कुल मुफ्त है।

रिपोर्ट-केवल मोड में शुरू करें — अभी लागू न करें। एक Content-Security-Policy-Report-Only प्रतिक्रिया हेडर जोड़ें।
अपनी साइट वास्तव में क्या उपयोग करती है उससे नीति बनाएं। रिपोर्ट की समीक्षा करें।
लूपहोल से बचें जो पूरे बिंदु को विफल करते हैं। स्क्रिप्ट के लिए 'unsafe-inline' और 'unsafe-eval' से दूर रहें।
फ्रेमिंग और प्लगइन बंद करें। frame-ancestors 'self' और object-src 'none' जोड़ें।
रिपोर्ट-केवल से लागू करने पर स्विच करें। हेडर नाम को Content-Security-Policy-Report-Only से Content-Security-Policy में बदलें।

जहाँ आप हेडर सेट करते हैं वह आपके प्लेटफॉर्म पर निर्भर करता है:
- Cloudflare: Rules → Transform Rules → Modify Response Header → Content-Security-Policy सेट करें।
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config): Content-Security-Policy नामक एक कस्टम HTTP प्रतिक्रिया हेडर जोड़ें।
नीति की पुष्टि करने के लिए अपना डोमेन फिर से जाँचें।

सामान्य गलतियाँ

रिपोर्ट-केवल पर रुकना। सबसे सामान्य त्रुटि: रिपोर्ट-केवल कुछ भी ब्लॉक नहीं करता।
“बस काम करने के लिए” 'unsafe-inline' की ओर पहुँचना।
वाइल्डकार्ड उपयोग करना। script-src में एक बेयर * स्क्रिप्ट को कहीं से भी अनुमति देता है।
तृतीय-पक्ष स्रोत भूलना।
इसे केवल होमपेज पर सेट करना। नीति को हर पेज कवर करने की जरूरत है।
इसे पैडलॉक के प्रतिस्थापन के रूप में मानना।

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

मैं तकनीकी नहीं हूँ — क्या मैं इसे स्वयं संभाल सकता हूँ?

आपको विवरण समझने की जरूरत नहीं है। यह एक सेटिंग है जो जो भी आपकी वेबसाइट या होस्टिंग चलाता है उसके द्वारा जोड़ी जाती है। नीचे 'इसे कैसे ठीक करें' अनुभाग उन्हें सौंपें। यह मुफ्त है; एक सावधानी यह है कि इसे पहले एक देखो-केवल परीक्षण में सावधानी से लागू किया जाना चाहिए।

मेरे पास पहले से पैडलॉक और एक SSL सर्टिफिकेट है — क्या मेरी साइट सुरक्षित नहीं है?

पैडलॉक आपके पेज की डिलीवरी सुरक्षित करता है; यह यह नहीं तय करता कि उसके अंदर क्या चलता है। एक Content Security Policy वह लेयर है जो पहले स्थान पर क्या चलने की अनुमति है उसे सीमित करती है।

क्या इसे चालू करने से मेरी साइट टूट सकती है?

यह कर सकता है यदि इसे एक बार में आक्रामक रूप से चालू किया जाए। इसीलिए मानक दृष्टिकोण पहले 'रिपोर्ट-केवल' परीक्षण मोड में शुरू करना है जो ब्लॉक किए बिना देखता है, जो भी फ्लैग करता है उसे ठीक करता है, और केवल तभी इसे लागू करता है।

हमने इसे 'रिपोर्ट-केवल' मोड में पहले से रखा — क्या हम कवर हैं?

नहीं, और यह सुरक्षा की सबसे सामान्य झूठी भावना है। रिपोर्ट-केवल मोड देखता और लॉग करता है, लेकिन कुछ भी ब्लॉक नहीं करता — विज़िटर को शून्य वास्तविक सुरक्षा मिलती है। आप केवल तभी सुरक्षित हैं जब आप लागू मोड पर स्विच करते हैं।

क्या यह हमारे स्कोर को प्रभावित करता है, या यह केवल सलाहकार है?

यह आपके स्कोर को प्रभावित करता है। Content Security Policy जाँच ग्रेड की गई है और Web Security श्रेणी में 25 अंक तक योग्य है।

हमारे डेवलपर ने एक नीति जोड़ी लेकिन स्कोर अभी भी कम है — क्यों?

एक नीति मौजूद हो सकती है और फिर भी कमजोर हो सकती है। सबसे सामान्य अपराधी स्क्रिप्ट के लिए 'unsafe-inline' और 'unsafe-eval', या वाइल्डकार्ड स्रोत जैसे लूपहोल हैं।