HTTP सिक्योरिटी हेडर जाँच
हर हेडर क्या करता है, आपका असल में क्या कहता है, और कौन-सी लाइन जोड़नी है। कोई ग्रेड नहीं।
अगर आप शुरुआत कर रहे हैं तो कहाँ से शुरू करें
ये हेडर न बराबर क़ीमती हैं और न तैनात करने में बराबर जोखिम वाले। नीचे वह क्रम है जो कुछ तोड़ने की सबसे कम संभावना पर सबसे ज़्यादा सुरक्षा देता है:
| हेडर | क्या रोकता है | कुछ टूटने का जोखिम |
|---|---|---|
Strict-Transport-Security | पहली विज़िट पर HTTPS का डाउनग्रेड | कोई नहीं, अगर आप पहले से सिर्फ़ HTTPS पर हैं |
X-Content-Type-Options | अपलोड की गई फ़ाइलों का MIME सूँघना | व्यवहार में कोई नहीं |
Referrer-Policy | URL का तीसरे पक्षों तक रिसना | कम — एनालिटिक्स की एट्रिब्यूशन पर असर पड़ सकता है |
X-Frame-Options / frame-ancestors | क्लिकजैकिंग | कम, बशर्ते कोई जायज़ तरीक़े से आपको एम्बेड न कर रहा हो |
Permissions-Policy | एम्बेड किए फ़्रेम का कैमरा या लोकेशन माँगना | कम |
Content-Security-Policy | इंजेक्ट की गई स्क्रिप्ट का चलना | ऊँचा। पहले रिपोर्ट-ओनली इस्तेमाल कीजिए। |
आख़िरी पंक्ति ही सबसे ज़्यादा मायने रखती है और वही असली मेहनत माँगती है। उसके ऊपर का सब कुछ एक दोपहर का काम है।
HSTS, और उसके भीतर वह एक अपरिवर्तनीय फ़ैसला
Strict-Transport-Security ब्राउज़र से कहता है कि अगले max-age सेकंड तक इस होस्ट के लिए HTTPS ही इस्तेमाल करे, चाहे कुछ भी हो। यह एक सँकरी पर असली खाई बंद करता है: example.com टाइप करने वाला आगंतुक आपके रीडायरेक्ट से पहले एक सादा रिक्वेस्ट भेजता है, और उसे बीच में पकड़ा जा सकता है।
Strict-Transport-Security: max-age=31536000; includeSubDomainsincludeSubDomains दिखने से ज़्यादा मायने रखता है। इसके बिना HTTP पर परोसा जाने वाला कोई सबडोमेन अब भी मूल डोमेन के लिए कुकी सेट कर सकता है। इसके साथ हर सबडोमेन को सिर्फ़ HTTPS पर होना ही पड़ेगा, वरना वह पहुँच से बाहर हो जाएगा — इसलिए जोड़ने से पहले जाँच लीजिए।
preload निर्देश ही वह फ़ैसला है जिस पर ठीक से सोचना चाहिए। यह आपके डोमेन को ब्राउज़रों के साथ आने वाली प्रीलोड सूचियों में पका देता है, ताकि पहली रिक्वेस्ट होने से भी पहले HTTPS लागू हो जाए। और यह व्यावहारिक रूप से अपरिवर्तनीय भी है: हटवाने के लिए सूची के रखवालों से अनुरोध करना पड़ता है और फिर ब्राउज़र रिलीज़ के फैलने का इंतज़ार, यानी महीने। जब आप निश्चिंत हों तो यह उम्दा है; और यूँ ही जोड़ देने के लिए बुरी चीज़।
CSP: रिपोर्ट-ओनली कोई विकल्प नहीं है
Content-Security-Policy यहाँ का इकलौता हेडर है जो इंजेक्ट की गई स्क्रिप्ट को चलने से रोकता है, और इकलौता जो आपकी साइट गिरा भी सकता है। दोनों बातें एक ही गुण से निकलती हैं: यह तय करता है कि क्या-क्या लोड हो सकता है।
इसे किसी कलेक्टर के साथ रिपोर्ट-ओनली मोड में तैनात कीजिए और कुछ हफ़्ते असली ट्रैफ़िक पर छोड़ दीजिए। जो मिलेगा वह वह नहीं होगा जिसकी उम्मीद कोड पढ़कर बनी थी — कोई भूला हुआ फ़ॉन्ट होस्ट निकलेगा, कोई पेमेंट iframe, और अक्सर CDN के किनारे पर इंजेक्ट की गई ऐसी स्क्रिप्ट जो कहीं किसी सोर्स फ़ाइल में है ही नहीं। आख़िरी श्रेणी ही वह है जिसे उजागर करने के लिए रिपोर्ट-ओनली मौजूद है।
Content-Security-Policy-Report-Only: default-src 'self';
script-src 'self'; object-src 'none'; base-uri 'self';
report-uri /csp-reportदो चीज़ें ज़्यादातर फ़ायदा मिटा देती हैं। script-src में 'unsafe-inline' ठीक उसी इंजेक्ट की गई इनलाइन स्क्रिप्ट को इजाज़त दे देता है जिसे रोकने के लिए नीति बनी थी — इसका रास्ता nonce या हैश हैं। और 'unsafe-eval' eval तथा उसके रिश्तेदारों को फिर से चालू कर देता है, जिनकी कुछ पुराने फ़्रेमवर्क बिल्ड को अब भी ज़रूरत है। चेकर दोनों को «ग़ायब» नहीं, «कमज़ोर करने वाला» बताता है, क्योंकि इनके साथ भी नीति कुछ काम की चीज़ कर रही होती है; बस मुख्य काम नहीं कर रही होती।
वे हेडर जिनकी सलाह की मियाद चुक गई
- `X-XSS-Protection` — यह ब्राउज़र के एक ऐसे फ़िल्टर को नियंत्रित करता था जो हर बड़े ब्राउज़र से हटाया जा चुका है, और अपने ज़माने में जिसे घुमाकर पेज तोड़े जा सकते थे। 2026 में यह सेट करने लायक़ हेडर नहीं है।
- `Expect-CT` — अप्रचलित। Certificate Transparency अब बिना शर्त लागू होती है, इसलिए यह हेडर कुछ करता ही नहीं।
- `Feature-Policy` — इसका नाम बदलकर
Permissions-Policyहो चुका है, और वाक्य-रचना भी अलग है। सिर्फ़ नया नाम माना जाता है। - `Public-Key-Pins` — ब्राउज़रों से हटाया जा चुका है, और ठीक ही हटाया गया। इसमें एक ग़लती आपके डोमेन को पूरी पिन-अवधि के लिए बेकार कर देती थी, और उबरने का कोई रास्ता नहीं होता था।
यह क्या नहीं जाँचता
एक पेज, एक रिस्पॉन्स। यह रीडायरेक्ट पीछा करने के बाद आख़िरी रिस्पॉन्स के हेडर पढ़ता है और वहीं रुक जाता है। यह साइट क्रॉल नहीं करता, जावास्क्रिप्ट नहीं चलाता, आपकी TLS सेटिंग नहीं परखता और कुकी फ़्लैग नहीं देखता — और एक ही साइट के अलग-अलग पाथ बिलकुल अलग हेडर भेज सकते हैं, इसलिए होमपेज जाँचना आपको होमपेज के बारे में बताता है।
ख़ास तौर पर TLS सेटिंग के लिए Qualys SSL Labs जमा-जमाया और विस्तृत औज़ार है। और सर्टिफ़िकेट के लिए यह वाला पढ़ता है कि होस्ट असल में क्या पेश करता है।
हेडर से जुड़े सवाल
यहाँ कोई स्कोर या ग्रेड क्यों नहीं है?
क्योंकि ग्रेड ही वह इकलौता नतीजा है जिस पर कोई कुछ कर नहीं सकता। यह जान लेना कि आपको C मिला है, यह नहीं बताता कि कौन-सा हेडर ग़ायब है, वह आपकी साइट के लिए क्यों मायने रखता है, या क्या सेट करना है — उल्टे यह हेडर इसलिए जुड़वाता है कि अक्षर ऊपर सरक जाए, न कि समस्या हल हो। सख़्त CSP वाली और Permissions-Policy से रहित साइट उस साइट से कहीं बेहतर हालत में है जिसके छह हेडर ढीले मानों पर सेट हैं, और यह बात कोई एक अक्षर कह ही नहीं सकता। इसलिए यहाँ हर हेडर अलग से बताया जाता है, आप जो मान सचमुच भेजते हैं उसे परखा जाता है, और जोड़ने लायक़ पंक्ति आपको दे दी जाती है।
मुझे पहले कौन-सा हेडर जोड़ना चाहिए?
Strict-Transport-Security, अगर आप पहले से सिर्फ़ HTTPS पर हैं। यह एक पंक्ति है, जो चल रहा है उसे तोड़ नहीं सकती, और पहली विज़िट वाली डाउनग्रेड खिड़की बंद कर देती है। उसके बाद रिपोर्ट-ओनली मोड में Content-Security-Policy — दाँत असल में उसी के हैं, और रिपोर्ट-ओनली आपको कुछ भी लागू करने से पहले यह पता लगाने देता है कि आपकी साइट असल में लोड क्या करती है। X-Content-Type-Options: nosniff भी मुफ़्त है और बस चालू रहना चाहिए।
क्या Content-Security-Policy मेरी साइट तोड़ देगी?
आसानी से तोड़ सकती है, इसीलिए रिपोर्ट-ओनली मोड मौजूद है। एक कलेक्टर के साथ Content-Security-Policy-Report-Only तैनात कीजिए, उसे कुछ हफ़्ते असली ट्रैफ़िक पर छोड़िए, और जो वह रिपोर्ट करे उसे पढ़िए — आपको ऐसे संसाधन मिलेंगे जिन्हें आप भूल चुके थे, और अक्सर वे चीज़ें भी जो CDN या एनालिटिक्स प्रदाता किनारे पर जोड़ देते हैं और जो किसी सोर्स फ़ाइल में दिखती ही नहीं। लागू तभी कीजिए जब रिपोर्टें शांत हो जाएँ। कोडबेस पढ़कर लिखी गई नीति को सीधे लागू कर देना — चेकआउट गिराने का यही जाना-पहचाना तरीक़ा है।
क्या X-XSS-Protection सेट करना सार्थक है?
नहीं। यह ब्राउज़र के एक XSS फ़िल्टर को नियंत्रित करता था जो हर बड़े ब्राउज़र से हटाया जा चुका है — Chrome ने 2019 में हटाया — और अपने ज़माने में वह फ़िल्टर ख़ुद कमज़ोरियाँ पैदा करता था, क्योंकि उसे इस तरह घुमाया जा सकता था कि वह उन पेजों को तोड़ दे जिनमें कोई ख़ामी थी ही नहीं। अगर कोई स्कैनर ज़िद करे तो उसे 0 पर सेट करना समझ आता है; उसे 1; mode=block पर सेट करना बरसों पहले चुक चुकी सलाह दोहराना है। इसकी जगह Content-Security-Policy ने ली है।
CSP है तो क्या X-Frame-Options की अब भी ज़रूरत है?
नहीं, बशर्ते आपकी CSP frame-ancestors सेट करती हो, जो हर मौजूदा ब्राउज़र में उसकी जगह ले लेती है। यह चेकर इसे पहचानता है और जब frame-ancestors अपना काम कर रही हो तो X-Frame-Options को ग़ायब बताकर रिपोर्ट नहीं करता। दोनों रखने में कुछ ख़र्च नहीं होता, पर मदद सिर्फ़ इतने पुराने ब्राउज़रों में मिलती है कि तब तक आपके सामने शायद इससे बड़ी समस्याएँ होंगी।
क्या किसी हेडर का न होना यह बताता है कि मुझमें कमज़ोरी है?
नहीं। सुरक्षा हेडर गहराई में रक्षा हैं — वे किसी कमज़ोरी का नुक़सान सीमित करते हैं, कमज़ोरी बनाते या मिटाते नहीं। बिना CSP वाली साइट XSS के लिए भेद्य नहीं हो जाती; भेद्य वह साइट है जिसमें XSS की ख़ामी है, और CSP वह चीज़ है जो उस ख़ामी को पूरे क़ब्ज़े में बदलने से रोकती है। हेडर जोड़ना सार्थक भी है और सस्ता भी, पर यह आउटपुट एन्कोडिंग, इनपुट वैलिडेशन और निर्भरताओं को अद्यतन रखने का विकल्प नहीं है।
अंतिम समीक्षा । कुछ पुराना पड़ा हुआ मिला? हमें बताइए.