सुरक्षा हेडर, समझाए गए
सुरक्षा हेडर HTTP प्रतिक्रिया में एक पंक्ति है जो बदल देती है कि आगंतुक का ब्राउज़र आपकी पेज के साथ क्या कर सकता है: केवल नामित स्रोतों से स्क्रिप्ट चलाना, फिर कभी सादा HTTP न बोलना, फ़्रेम में रखे जाने से इनकार करना, सामग्री प्रकारों का अनुमान लगाने से इनकार करना। इनमें से किसी को भी कोड, लाइब्रेरी या पुनरारंभ की ज़रूरत नहीं है — और फिर भी अधिकांश वेबसाइटें इनमें से बहुत कम या कोई नहीं भेजती हैं, और इसीलिए जब कोई स्कैनर जाँचता है तो अधिकांश वेबसाइटें F पाती हैं। यह लेख हेडर-दर-हेडर बताता है कि प्रत्येक वास्तव में क्या रोकता है, F की महामारी को समझाता है, और वह सुधार क्रम देता है जो प्रति घंटे के काम पर सबसे अधिक सुरक्षा वापस लाता है। अपनी साइट का फ़ैसला देखने के लिए, पहले सुरक्षा हेडर जाँच चलाएँ और अपने परिणाम खुले रखकर पढ़ें।
हेडर ब्राउज़र के लिए निर्देश हैं, सर्वर का कवच नहीं
इससे शुरू करें कि हेडर क्या नहीं है। सुरक्षा हेडर आपके ऐप्लिकेशन को पैच नहीं करता, आपके ट्रैफ़िक को छानता नहीं, और किसी को प्रमाणित नहीं करता। यह एक घोषणा है जो सर्वर किसी प्रतिक्रिया में जोड़ता है, और ब्राउज़र — आगंतुक का ब्राउज़र, आगंतुक की मशीन पर — उसी क्षण से उसे लागू करता है। यह तब तक कमज़ोर लगता है जब तक आप यह न देखें कि कितने हमले ब्राउज़र द्वारा हमलावर की ओर से किए जाते हैं: किसी के टिप्पणी फ़ील्ड में इंजेक्ट की गई स्क्रिप्ट को चलाना, आपके लॉगिन पेज को किसी शत्रुतापूर्ण साइट पर अदृश्य फ़्रेम के भीतर लोड करना, अपलोड की गई टेक्स्ट फ़ाइल को HTML मानना क्योंकि उसकी सामग्री स्क्रिप्ट-जैसी लगी। हेडर वह तरीका है जिससे सर्वर ब्राउज़र को पहले से बता देता है कि इनमें से कौन-सी चालें इस साइट पर कभी वैध नहीं हैं।
वे गहराई-में-रक्षा भी हैं, और उन्हें उसी तरह पढ़ा जाना चाहिए। इस क्षेत्र के मानक संदर्भ हैं MDN HTTP दस्तावेज़, जो प्रत्येक हेडर के सिंटैक्स और अर्थ को निर्दिष्ट करता है, और OWASP Secure Headers Project, जिसके अनुशंसित मानों की ओर OWASP Web सुरक्षा परीक्षण मार्गदर्शिका का परीक्षण मार्गदर्शन इशारा करता है। कोई भी स्रोत यह वादा नहीं करता कि हेडर किसी साइट को सुरक्षित बना देंगे। वे कुछ संकरा और सत्य वादा करते हैं: हेडर सेट होने पर, ब्राउज़र द्वारा किए जाने वाले हमलों के पूरे वर्ग काम करना बंद कर देते हैं, यहाँ तक कि जब कोई ऐप्लिकेशन बग हमलावर को पैर जमाने की जगह दे दे।
प्रत्येक हेडर वास्तव में क्या रोकता है
Content-Security-Policy इंजेक्ट की गई स्क्रिप्टों को चलने से रोकती है।XSS और उसके संबंधियों — स्क्रिप्ट लिए हुए संग्रहीत टिप्पणी, समझौता किए गए तृतीय-पक्ष टैग के माध्यम से इंजेक्ट की गई स्किमिंग स्क्रिप्ट — सभी को ब्राउज़र द्वारा ऐसा कोड चलाना पड़ता है जिसका साइट ने कभी इरादा नहीं किया। CSP एक अनुमति-सूची है: script-src उन मूलों को नाम देती है जहाँ से स्क्रिप्ट आ सकती हैं, और बाकी सब, जिसमें इनलाइन स्क्रिप्ट और हमलावर के सर्वर से लोड की गई कोई भी चीज़ शामिल है, अस्वीकार कर दिया जाता है। इसके कमज़ोर रूप प्रसिद्ध हैं: 'unsafe-inline' वाली नीति हर इनलाइन स्क्रिप्ट को चलने देती है, जिसमें इंजेक्ट की गई भी शामिल है, और इसीलिए जांचकर्ता ऐसी नीति को अच्छा नहीं, कमज़ोर मानता है। CSP तैनात करने में सबसे भारी हेडर है और सबसे अधिक रोकने वाला भी।
Strict-Transport-Security डाउनग्रेड को रोकती है।पहली बार जब कोई आगंतुक बिना स्कीम के आपका डोमेन टाइप करता है, या किसी पुराने http:// लिंक का अनुसरण करता है, वह अनुरोध नेटवर्क को सादे रूप में पार करता है, जहाँ उसे छीना, पुनर्निर्देशित या पढ़ा जा सकता है — सत्र कुकी समेत। HSTS ब्राउज़र को कहती है: अगले max-age सेकंडों के लिए, इस होस्ट के हर http:// URL को कुछ भी मशीन छोड़ने से पहले https:// में फिर से लिखो, और प्रमाणपत्र-त्रुटि के क्लिक-थ्रू को अस्वीकार करो। एक ईमानदार सीमा: HSTS केवल उन आगंतुकों की रक्षा करती है जिनके ब्राउज़रों ने हेडर को पहले ही एक बार देखा हो (ब्राउज़रों में निर्मित प्रीलोड सूचियाँ ठीक उसी पहली-यात्रा खाई को बंद करने के लिए मौजूद हैं), और इसे तभी सम्मानित किया जाता है जब यह स्वयं HTTPS पर आए।
फ़्रेम सुरक्षा क्लिकजैकिंग को रोकती है।यदि आपके पेज फ़्रेम में रखे जा सकते हैं, तो कोई शत्रुतापूर्ण साइट आपके असली इंटरफ़ेस को अपने बटनों की पारदर्शी परत के नीचे बिछा सकती है और क्लिकों की फ़सल काट सकती है — पीड़ित एक हानिरहित दिखने वाला पेज देखता है और एक स्थानांतरण को मंज़ूरी दे देता है। CSP निर्देश frame-ancestors (और उसकी बड़ी बहन, X-Frame-Options: DENY या SAMEORIGIN) नाम देती है कि कौन आपको फ़्रेम में रख सकता है; बाकी सबको खाली फ़्रेम मिलता है। X-Content-Type-Options: nosniff एक शांत चाल को रोकती है: ब्राउज़र ऐतिहासिक रूप से घोषित Content-Type का फिर से अनुमान लगाते थे और फ़ाइलों को स्क्रिप्ट या HTML के रूप में चला देते थे जब सामग्री वैसी लगती थी, जिससे कोई मासूम अपलोड संग्रहीत XSS में बदल जाता था। nosniff अनुमान ख़त्म कर देती है — घोषित प्रकार ही प्रकार है।
Referrer-Policy URL रिसाव को रोकती है।जब कोई आगंतुक आपके पेज से किसी अन्य साइट पर क्लिक करता है, ब्राउज़र ऐतिहासिक रूप से आपके पेज का पूरा URL Referer के रूप में भेजता था — जिसमें बैठे कोई भी पासवर्ड-रीसेट टोकन, खोज शब्द या रिकॉर्ड ID शामिल थे। strict-origin-when-cross-origin या उससे सख़्त नीति क्रॉस-साइट केवल मूल भेजती है और डाउनग्रेड-प्रवण http लक्ष्यों को कुछ नहीं। Permissions-Policy सुविधा दुरुपयोग को रोकती है: यह घोषणा करती है कि कौन-सी शक्तिशाली ब्राउज़र क्षमताएँ — कैमरा, माइक्रोफ़ोन, भौगोलिक स्थान, भुगतान हैंडलर — यह साइट बिल्कुल उपयोग कर सकती है, ताकि कोई इंजेक्ट किया गया फ़्रेम या स्क्रिप्ट आपके नाम पर उन्हें चुपचाप न माँग सके। और बोनस हेडर, Cross-Origin-Opener-Policy, आपके पेज और अन्य-मूल पॉपअप के बीच की window.opener कड़ी को काट देती है, आपके ब्राउज़िंग संदर्भ को उन पेजों से अलग करती है जो उसे जाँचने की कोशिश कर सकते हैं।
इतनी सारी साइटें F क्यों पाती हैं
क्योंकि किसी का भी डिफ़ॉल्ट ये हेडर नहीं भेजता। एक स्टॉक वेब सर्वर, एक स्टॉक फ़्रेमवर्क ढाँचा, एक स्टॉक स्थिर होस्ट: प्रत्येक अधिक से अधिक छह में से एक या दो के साथ प्रतिक्रियाएँ भेजता है, और दो सबसे मूल्यवान — CSP और Permissions-Policy — को विशिष्ट साइट के बारे में निर्णयों की ज़रूरत होती है, इसलिए कोई डिफ़ॉल्ट उन्हें सुरक्षित रूप से साथ नहीं भेज सकता। फिर ज़िम्मेदारी तीन तरीकों से बँट जाती है: फ़्रेमवर्क टीम मानती है कि सर्वर हेडर जोड़ता है, सर्वर टीम मानती है कि फ़्रेमवर्क जोड़ता है, और सामने वाला CDN वैसे भी जो चाहे फिर से लिख देता है। हेडर चुपचाप खाई में गिर जाते हैं, क्योंकि उनके बिना कुछ भी दिखाई देने योग्य टूटता नहीं। F वाली साइट आमतौर पर A वाली साइट जैसी ही दिखती और काम करती है; अंतर केवल उस दिन दिखता है जब किसी हमले को ब्राउज़र के सहयोग की ज़रूरत पड़ती है।
प्रकाशित संख्याएँ उस कहानी से मेल खाती हैं। 2026-11-04 के साप्ताहिक टूल-स्कैन सारांश में रिपोर्ट किए गए, एक स्कैनर के प्रकाशित नमूने ने पाया कि स्कैन की गई साइटों में से 65% को F मिला और 51% ने कोई Content-Security-Policy बिल्कुल नहीं भेजी। इन्हें वही मानें जो ये हैं — एक स्कैनर का नमूना, किसी तीसरे पक्ष द्वारा प्रकाशित, पूरे वेब का माप नहीं और हमारा अपना डेटा नहीं — लेकिन दिशा हर संचालक के अनुभव से पुष्ट होती है: हेडर वह दुर्लभ सुरक्षा नियंत्रण हैं जिनकी अनुपस्थिति सांख्यिकीय मानक है। और यही उस आँकड़े में छिपी अच्छी ख़बर भी है: बार ज़मीन पर है, और उसे पार करना इंजीनियरिंग नहीं, कॉन्फ़िगरेशन है।
सुधार क्रम, प्रति घंटे प्रभाव के अनुसार
उस क्रम में काम करें जिसे सुरक्षा हेडर जाँच स्पष्ट करती है। पहले, एक-पंक्ति वाले: X-Content-Type-Options: nosniff, फ़्रेम सुरक्षा, और एक समझदार Referrer-Policy — सौ में से पैंतीस अंक, कुछ मिनटों का काम, और सामान्य साइट पर वस्तुतः शून्य टूटने का जोखिम। दूसरा, HSTS — और बीस अंक — लेकिन केवल यह सत्यापित करने के बाद कि हर पेज, सबडोमेन और विरासती पुनर्निर्देश सचमुच HTTPS पर काम करता है, क्योंकि लंबे max-age को वापस नहीं भेजा जा सकता। तीसरा, Permissions-Policy: वे सुविधाएँ सूचीबद्ध करें जिनका आपकी साइट वास्तव में उपयोग करती है, बाकी बंद कर दें; एक सावधान पंक्ति के लिए दस अंक।
अंत में, और धीरे-धीरे, CSP।इसके 35 अंक सबसे बड़ा एकल खंड हैं और एकमात्र सुधार है जो आपकी अपनी साइट को गिरा सकता है। पहले इसे रिपोर्टिंग एंडपॉइंट के साथ Content-Security-Policy-Report-Only के रूप में तैनात करें, एक सप्ताह की उल्लंघन रिपोर्ट पढ़ें, जिन इनलाइन स्क्रिप्टों और इवेंट हैंडलरों को यह चिह्नित करे उन्हें फिर से लिखें — या MDN मार्गदर्शन की सिफ़ारिश के अनुसार nonce अपनाएँ — और केवल तभी लागू करने पर स्विच करें जब रिपोर्ट शांत हो जाएँ। जब भी आप अन्य-मूल पॉपअप प्रवाहों पर निर्भर न हों, Cross-Origin-Opener-Policy: same-origin जोड़ें; यह हमारी तालिका में अंकित नहीं है लेकिन सस्ता अलगाव है। फिर जाँच फिर से चलाएँ और पुष्टि करें कि मूल पर जोड़े गए हेडर सचमुच सामने वाले CDN और प्रॉक्सियों से बचकर निकले।
हेडर क्या नहीं कर सकते
वे छेद को ठीक नहीं कर सकते, केवल यह छोटा कर सकते हैं कि हमलावर उसके माध्यम से क्या कर सकता है। CSP उस टिप्पणी फ़ील्ड को ठीक नहीं करती जो अपने इनपुट को एस्केप करने में विफल रही; यह इंजेक्ट किए गए पेलोड को चलने से इनकार करवा देती है। HSTS टूटी हुई प्रमाणपत्र शृंखला को ठीक नहीं करती — वह SSL ग्रेडर का क्षेत्र है — और कोई हेडर पैचिंग, बैकअप या पहुँच नियंत्रण का विकल्प नहीं है। एक परिपूर्ण हेडर ग्रेड को उस इमारत के अच्छी तरह बंद दरवाज़े के रूप में पढ़ें जिसकी अन्य मंज़िलों को अब भी अपनी जाँचों की ज़रूरत है, जिसके लिए वेबसाइट स्वास्थ्य जाँच है।
उन्हें सेट करके भुलाया भी नहीं जा सकता। पिछले वर्ष की साइट के लिए लिखी गई CSP इस वर्ष के भुगतान विजेट को चुपचाप रोक देती है — या, और बुरा, जल्दबाज़ी में * से ढीली कर दी जाती है और कुछ भी अर्थ रखना बंद कर देती है। हेडर समूह को अपने बाकी कॉन्फ़िगरेशन की तरह मानें: संस्करणित, साइट बदलने पर समीक्षित, और हर प्लेटफ़ॉर्म बदलाव के बाद फिर जाँचा गया। जाँच में दस सेकंड लगते हैं; जब भी आपके पेजों के सामने वाला स्टैक बदले, उसे चलाएँ, और F की महामारी किसी और का आँकड़ा बनी रहेगी।