वेबसाइट के सिक्योरिटी हेडर कैसे चेक करें

किसी वेबसाइट के सिक्योरिटी हेडर चेक करने के लिए पेज को HTTPS पर खोलें और छह रिस्पॉन्स हेडर पढ़ें: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (या CSP का frame-ancestors), X-Content-Type-Options, Referrer-Policy और Permissions-Policy, साथ में हर Set-Cookie के फ़्लैग। कोई हेडर न होना हमेशा कमज़ोरी नहीं है, और हेडर होना अपने आप में सुरक्षा की गारंटी नहीं है: असली बात उसकी वैल्यू है। हमारा फ़्री HTTP हेडर लुकअप किसी भी URL के सारे हेडर कुछ सेकंड में दिखा देता है, बिना अकाउंट बनाए।

इस गाइड के सारे नतीजे 3 नवंबर 2026 को हमारे टूल से GitHub, BBC और example.com पर किए गए असली टेस्ट से हैं। नियम MDN, HSTS प्रीलोड लिस्ट की आधिकारिक शर्तों और RFC 6797 से लिए गए हैं, जिन्हें उसी दिन जाँचा गया।

URL तैयार है? पूरा पता, https:// समेत, फ़्री HTTP हेडर लुकअप में पेस्ट करें और नीचे की लिस्ट पढ़ते समय नतीजा खुला रखें।

छह ज़रूरी हेडर और उनकी सही वैल्यू

एक हेडर जिसकी अब चिंता छोड़ सकते हैं: X-XSS-Protection। MDN चेतावनी देता है कि यह वैसे सुरक्षित साइटों में भी XSS कमज़ोरी पैदा कर सकता है, और इसकी जगह Content-Security-Policy की सलाह देता है। इसीलिए GitHub x-xss-protection: 0 भेजता है, यानी पुराना फ़िल्टर जान-बूझकर बंद।

सिक्योरिटी हेडर स्टेप बाय स्टेप कैसे चेक करें

1. वही URL लें जिस पर लोग पहुँचते हैं

पूरा पता स्कीम के साथ लिखें: https://github.com/, सिर्फ़ github.com नहीं। सिर्फ़ डोमेन डालने पर हमारे टूल ने नतीजे की जगह "फ़ील्ड ज़रूरी है" वाला मैसेज दिखाया, क्योंकि उसे स्कीम से ही पता चलता है कि क्या माँगना है। होमपेज के साथ लॉगिन, फ़ॉर्म और पेमेंट पेज भी जाँचें: ये अक्सर किसी दूसरे ऐप से आते हैं और इनके हेडर अलग होते हैं।

2. लुकअप चलाएँ

HTTP हेडर लुकअप खोलें, URL पेस्ट करें और बटन दबाएँ। रिक्वेस्ट हमारे सर्वर से जाती है, इसलिए आपको वही दिखता है जो किसी भी विज़िटर को मिलता है, बीच में आपके ब्राउज़र के एक्सटेंशन या कैश नहीं आते। टूल फ़्री है और अकाउंट नहीं माँगता; बिना साइन-अप रोज़ 5 लुकअप मिलते हैं, और फ़्री अकाउंट (कोई स्पैम नहीं) यह लिमिट हटा देता है।

3. सही हॉप पहचानें

टूल रीडायरेक्ट फ़ॉलो करता है और हर हॉप के हेडर एक ही टेबल में दिखाता है। पहली लाइन में सिर्फ़ पहले रिस्पॉन्स का स्टेटस होता है। http://github.com चेक करने पर टेबल HTTP/1.1 301 Moved Permanently और Location: https://github.com/ से शुरू हुई, और उसके बाद का सब कुछ फ़ाइनल HTTPS पेज का था। नियम: आख़िरी Location लाइन के नीचे जो है, वही उस पेज के हेडर हैं जो लोग देखते हैं। साफ़ टेबल के लिए सीधे फ़ाइनल HTTPS URL चेक करें, और हर हॉप का स्टेटस कोड देखने के लिए URL रीडायरेक्ट चेकर इस्तेमाल करें।

4. हर हेडर को टेबल से मिलाएँ

ऊपर की छह लाइनें एक-एक करके देखें। जो नहीं है उसे नोट करें, फिर जो है उसकी वैल्यू पढ़ें, क्योंकि कमज़ोर वैल्यू गायब हेडर से ज़्यादा आम समस्या है।

5. कुकी के फ़्लैग पढ़ें

पेज की सारी Set-Cookie लाइनें एक ही पंक्ति में साथ दिखती हैं। सेशन कुकी पर Secure, HttpOnly और कोई SameSite वैल्यू होनी चाहिए। एनालिटिक्स कुकी जान-बूझकर HttpOnly के बिना हो सकती है, क्योंकि स्क्रिप्ट को उसे पढ़ना होता है।

उदाहरण 1: GitHub, मज़बूत बेसलाइन

https://github.com/ के लुकअप ने HTTP/2 200 और ये सिक्योरिटी लाइनें दिखाईं (CSP छोटी की गई):

strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com ...

• CSP default-src 'none' से शुरू होती है: कोई डायरेक्टिव इजाज़त न दे तो कुछ लोड नहीं होता। यही सबसे सख़्त शुरुआत है और नई साइट के लिए इसी को अपनाएँ।
• Referrer-Policy एक लिस्ट है। MDN इसे फ़ॉलबैक बताता है: ब्राउज़र आख़िरी वैल्यू लेता है जिसे वह समझता है, इसलिए आज के ब्राउज़र strict-origin-when-cross-origin लागू करते हैं।
• हर कुकी पर उसके काम के हिसाब से फ़्लैग हैं। _gh_sess और logged_in पर HttpOnly; secure; SameSite=Lax है; _octo पर secure; SameSite=Lax है पर HttpOnly नहीं, जो स्क्रिप्ट से पढ़ी जाने वाली वैल्यू के लिए ठीक है।

Permissions-Policy नहीं है। बहुत अच्छी तरह चलाई जाने वाली साइटें भी सब कुछ नहीं भेजतीं, इसलिए लिस्ट को गाइड मानें, नंबर नहीं।

उदाहरण 2: BBC, हेडर हैं पर कमज़ोर

https://www.bbc.com/ के लुकअप में दिखा:

referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000; preload

सरसरी नज़र में छह में से चार। ध्यान से पढ़ें तो दो असली समस्याएँ निकलती हैं:

• रेफ़रर पॉलिसी ब्राउज़र के डिफ़ॉल्ट से भी कमज़ोर है। MDN के मुताबिक़ कोई पॉलिसी न हो तो ब्राउज़र strict-origin-when-cross-origin इस्तेमाल करते हैं, और no-referrer-when-downgrade पहले का डिफ़ॉल्ट था। पुरानी वैल्यू सेट करने से ब्राउज़र पूरा URL, पाथ और पैरामीटर समेत, हर दूसरी HTTPS साइट को भेजता है; हेडर न होता तो सिर्फ़ डोमेन जाता।
• HSTS हेडर प्रीलोड माँगता है पर शर्तें पूरी नहीं करता। hstspreload.org बेस डोमेन पर preload के साथ includeSubDomains और कम से कम एक साल का max-age माँगता है। हमने https://bbc.com/ भी चेक किया: यह www पर 301 देता है और वही max-age=31536000; preload भेजता है, बिना includeSubDomains।

Content-Security-Policy भी नहीं है। विज्ञापनों और ढेरों थर्ड-पार्टी स्क्रिप्ट वाले पेज पर यही सबसे बड़ी कमी है, और इसे ठीक करना भी सबसे मुश्किल है।

उदाहरण 3: example.com, कुछ भी नहीं

https://example.com/ ने HTTP/2 200 दिया, जिसमें तारीख़, कंटेंट टाइप, server: cloudflare, कैश की लाइनें थीं और एक भी सिक्योरिटी हेडर नहीं। हमारे सर्वर से http:// पर माँगने पर इसने HTTPS पर रीडायरेक्ट किए बिना HTTP/1.1 200 OK दिया। असली साइट पर यह सबसे पहले ठीक करने वाली चीज़ होती; पर बिना लॉगिन, कुकी या फ़ॉर्म वाले स्टैटिक डॉक्यूमेंटेशन पेज पर जोखिम कम है। यही संदर्भ का नियम है: किसी जानकारी वाले पेज पर CSP न होना और किसी ऑनलाइन स्टोर के चेकआउट पर CSP न होना, एक बात नहीं है।

वे गलतियाँ जो जाँच को भ्रामक बना देती हैं

• HTTP रीडायरेक्ट पर भेजा गया HSTS गिना नहीं जाता। MDN और RFC 6797 के अनुसार ब्राउज़र बिना एन्क्रिप्शन वाले HTTP पर मिला Strict-Transport-Security नज़रअंदाज़ करते हैं। GitHub का http:// हॉप सिर्फ़ 301 और Location भेजता है; हेडर HTTPS पेज के साथ आता है, और यही सही है।
• HTTP से HTTPS पर 302 चलता है, पर 301 ज़्यादा साफ़ है। http://www.bbc.com/ ने 302 Found दिया और http://github.com/ ने 301। दोनों HTTPS तक पहुँचाते हैं; अगली विज़िट पर पहली असुरक्षित रिक्वेस्ट HSTS ही हटाता है। फ़र्क़ हमारी गाइड रीडायरेक्ट 301 है या 302 कैसे पता करें में समझाया गया है।
• Content-Security-Policy-Report-Only कुछ ब्लॉक नहीं करता। यह सिर्फ़ रिपोर्ट करता है: साइट पॉलिसी टेस्ट कर रही है, उससे सुरक्षित नहीं है।
• CDN हेडर जोड़ या हटा सकता है। अगर आपका सर्वर कोई हेडर सेट करता है पर लुकअप में नहीं दिखता, तो ऐप को दोष देने से पहले CDN के नियम देखें।
• मेटा टैग हेडर नहीं है। <meta http-equiv> से लगाई गई CSP हेडर लुकअप में नहीं दिखती और frame-ancestors सपोर्ट नहीं करती। HTML में क्या है, यह मेटा टैग चेकर से देखें।
• अच्छे हेडर साइट के भरोसेमंद होने का सबूत नहीं हैं। फ़िशिंग पेज भी परफ़ेक्ट हेडर भेज सकता है। किसी अनजान साइट को परखने के लिए हमारी गाइड वेबसाइट असली है या फ़र्ज़ी कैसे पता करें देखें और SSL लुकअप से सर्टिफ़िकेट जाँचें।

अपनी साइट के लिए एक समझदार शुरुआत

सिर्फ़ HTTPS पर चलने वाली आम साइट के लिए यह एक सुरक्षित पहला वर्ज़न है। इसे पहले स्टेजिंग कॉपी पर टेस्ट करें और CSP को पहले Report-Only के रूप में लगाएँ:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'

includeSubDomains तभी जोड़ें जब हर सबडोमेन HTTPS पर चलता हो, और preload तब तक न लगाएँ जब तक पक्का न हो, क्योंकि प्रीलोड लिस्ट से निकलने में बहुत समय लगता है। फिर URL को दोबारा फ़्री हेडर लुकअप में चलाएँ और पक्का करें कि हर लाइन ठीक वैसी ही पहुँची।

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

सिक्योरिटी हेडर फ़्री में कैसे चेक करें?

पूरा URL, https:// समेत, My Botsy के HTTP हेडर लुकअप में पेस्ट करें। यह सारे रिस्पॉन्स हेडर कुछ सेकंड में, बिना अकाउंट दिखाता है। टर्मिनल में URL के साथ curl -sI भी चला सकते हैं, या ब्राउज़र के डेवलपर टूल्स में Network टैब खोलकर पेज की रिक्वेस्ट पर क्लिक कर सकते हैं।

हर वेबसाइट पर कौन से सिक्योरिटी हेडर होने चाहिए?

Strict-Transport-Security, Content-Security-Policy, nosniff वाला X-Content-Type-Options, एक Referrer-Policy, और X-Frame-Options या frame-ancestors से iframe में दिखाए जाने से सुरक्षा। थर्ड-पार्टी कंटेंट एम्बेड करते हों तो Permissions-Policy भी। X-XSS-Protection पुराना हो चुका है: 0 रखें या न भेजें।

लुकअप पहले 301 क्यों दिखाता है?

क्योंकि यह रीडायरेक्ट फ़ॉलो करता है और सारे हॉप एक टेबल में दिखाता है; पहली लाइन पहले रिस्पॉन्स का स्टेटस है। आख़िरी Location लाइन के बाद वाले हेडर फ़ाइनल पेज के हैं। साफ़ नतीजे के लिए सीधे फ़ाइनल HTTPS URL चेक करें।

क्या Content-Security-Policy के बिना साइट असुरक्षित है?

ज़रूरी नहीं। कोई स्क्रिप्ट घुसा दे तो CSP नुक़सान को सीमित करती है। बिना लॉगिन, फ़ॉर्म या थर्ड-पार्टी स्क्रिप्ट वाले स्टैटिक पेज के पास बचाने को कम है; पर CSP के बिना लॉगिन या चेकआउट पेज में असली कमी है।

क्या सर्वर एक्सेस के बिना सिक्योरिटी हेडर जोड़ सकते हैं?

अक्सर हाँ। Cloudflare जैसे CDN नियमों से रिस्पॉन्स हेडर जोड़ने देते हैं, और कई होस्टिंग कंपनियाँ .htaccess या कंट्रोल पैनल में इन्हें सेट करने देती हैं। CSP मेटा टैग में भी जा सकती है, पर frame-ancestors सिर्फ़ असली हेडर के रूप में काम करता है।

क्या सिक्योरिटी हेडर से SEO में मदद मिलती है?

इनका काम विज़िटर की सुरक्षा है, रैंकिंग नहीं, इसलिए ट्रैफ़िक में उछाल की उम्मीद न रखें। ये भरोसा और एकरूपता देते हैं: HSTS लौटने वाले विज़िटर को HTTPS पर रखता है, और HTTP से HTTPS का साफ़ रीडायरेक्ट सर्च इंजन को हर पेज का एक ही वर्ज़न दिखाता है।