Secure Infrastructure • Verification • Operations
Secure Infrastructure • Verification • Operations
AUTHSETU • सुरक्षा और डिजिटल इंटेलिजेंस • 2026
वेबसाइट से response मिलने पर HTTP response headers नाम की छोटी metadata जानकारी भी लौटती है। कुछ headers ब्राउज़र के व्यवहार को निर्देशित करते हैं; दूसरे तकनीक या संचालन संबंधी जानकारी उजागर करते हैं। ये मिलकर वेबसाइट configuration का उपयोगी, लेकिन सीमित, बाहरी दृश्य देते हैं।
Security-related headers क्या बता सकते हैं?
HSTS — Strict-Transport-Security
Policy मिलने के बाद compatible browsers को निर्धारित अवधि तक HTTPS इस्तेमाल करने के लिए कह सकता है। इसकी मौजूदगी transport hardening का संकेत है; इसकी अनुपस्थिति को वास्तविक HTTP/HTTPS व्यवहार और deployment की ज़रूरतों के साथ समझना चाहिए।
Content-Security-Policy (CSP)
यह तय करता है कि पेज scripts, styles, frames और अन्य resources कहाँ से लोड कर सकता है। सही ढंग से बनाई गई policy कुछ browser-side injection और content-loading जोखिम कम कर सकती है। केवल मौजूद होना policy के मज़बूत होने का प्रमाण नहीं है।
X-Content-Type-Options
आम तौर पर इस्तेमाल किया जाने वाला nosniff मान MIME-type sniffing को सीमित करता है। यह browser-side hardening का एक उपाय है, पूरी application सुरक्षा नहीं।
X-Frame-Options / CSP frame controls
यह सीमित कर सकते हैं कि पेज को frames में embed किया जा सकता है या नहीं, और clickjacking जोखिम घटाने में मदद कर सकते हैं। Header जाँचने से यह साबित नहीं होता कि हर पेज और workflow का आकलन हुआ है।
Referrer-Policy
यह नियंत्रित करता है कि browser requests के साथ कितनी referrer जानकारी भेजे। Policy में privacy और analytics जैसी संचालन संबंधी ज़रूरतों का संतुलन होना चाहिए।
Permissions-Policy
पेज और frames के लिए camera, microphone या geolocation जैसी browser capabilities सीमित कर सकता है। उचित policy वेबसाइट के वास्तविक features पर निर्भर करती है।
Server / X-Powered-By
Server, framework, runtime या hosting की जानकारी उजागर हो सकती है। मालिक को देखना चाहिए कि क्या यह जानकारी सार्वजनिक होना आवश्यक है। जानकारी उजागर होने से यह साबित नहीं होता कि software exploit किया जा सकता है।
मौजूद होना पर्याप्त नहीं—अनुपस्थित होना भी पर्याप्त नहीं
| Observation | उचित व्याख्या | इससे क्या साबित नहीं होता |
|---|---|---|
| HSTS मिला | जाँचे गए endpoint पर transport-hardening control दिया जा रहा है। | पूरी वेबसाइट सुरक्षित है। |
| CSP मिला | Browser content policy मौजूद है। | Policy सही बनी है या हर संबंधित हमले को रोकती है। |
| CSP नहीं मिला | देखें कि browser-policy hardening की ज़रूरत है या नहीं। | वेबसाइट vulnerable या compromised है। |
| Server version उजागर | Technology fingerprinting की जानकारी सार्वजनिक है। | उजागर software exploitable है। |
| कई headers अनुपस्थित | Browser-security baseline को बेहतर बनाने का अवसर हो सकता है। | हमला या data theft हुआ है। |
| कई headers मौजूद | कुछ defensive controls दिखाई दे रहे हैं। | सभी controls सही configured हैं। |
सितंबर 2026 की समीक्षा में क्या सामने आया?
CDS/AuthSetu के normalized V5 dataset में 92 अधिकृत public-facing targets और 9,977 normalized observations शामिल थे। 50 targets (54.3%) पर HSTS और 45 targets (48.9%) पर CSP दर्ज हुआ। ये आँकड़े केवल उसी reviewed dataset के हैं; ये भारत की सभी small-business websites के प्रतिनिधि आँकड़े नहीं हैं।
रिपोर्टों में बेहतर और अधूरे—दोनों प्रकार के header configurations दिखे। इसलिए headers का अर्थ समझने के लिए संदर्भ और endpoint-level verification ज़रूरी है, न कि केवल “secure/insecure” का लेबल।
Automated header reports में अंतर क्यों हो सकता है?
Redirects, CDN या proxy व्यवहार, caching, user-agent के अंतर, चुने गए endpoint, parser normalization और live configuration में बदलाव के कारण scanners और parsers के परिणाम अलग हो सकते हैं। इस समीक्षा में पहले के V4 extraction और बाद के V5 normalization में हर header या technology field पर सहमति नहीं थी। इसलिए ऐसे मतभेदों को छिपाकर vulnerability घोषित करने के बजाय स्पष्ट रूप से दर्ज किया जाता है।
Header review की व्यावहारिक प्रक्रिया
- सटीक endpoint और request context तय करें।
- Status code, redirect chain और response headers दर्ज करें।
- तारीख, समय और संबंधित request conditions लिखें।
- Security controls, technology disclosure और operational metadata अलग रखें।
- केवल header की मौजूदगी नहीं, उसके वास्तविक values जाँचें।
- जहाँ उचित हो, संबंधित endpoints की तुलना करें।
- TLS, cookies, DNS, technology और application evidence के साथ निष्कर्ष मिलाएँ।
- हर बिंदु को observed, inferred, unverified या conflicting के रूप में वर्गीकृत करें।
- बताएँ कि प्रमाण से क्या साबित नहीं होता।
- जोखिम के अनुपात में verification या remediation सुझाएँ।
व्यवसाय के लिए यह क्यों मायने रखता है?
- विश्वास: एकसमान browser-security configuration डिजिटल infrastructure पर सोच-समझकर काम करने का संकेत देती है।
- Exposure: अनावश्यक server/runtime disclosure सार्वजनिक निरीक्षकों को platform fingerprinting में मदद कर सकता है।
- सुरक्षा: उचित headers कुछ browser-side जोखिम घटाकर defence-in-depth को मज़बूत कर सकते हैं।
- Governance: दर्ज baseline से redesign, migration या platform changes के बाद configuration drift पहचानना आसान होता है।
एक professional finding कैसी होनी चाहिए?
कमज़ोर कथन: “Security headers नहीं हैं, इसलिए आपकी वेबसाइट की सुरक्षा बहुत खराब है।”
Headers, penetration test नहीं हैं
Header review बाहरी passive evidence है। Penetration test अधिक गहरा, अधिकृत security assessment है जिसमें vulnerabilities और application behaviour का नियंत्रित validation शामिल हो सकता है। एक को दूसरे के रूप में प्रस्तुत न करें। जाँच की गहराई system के जोखिम और स्पष्ट authorization के अनुरूप होनी चाहिए।
संबंधित लेख
वेबसाइट सुरक्षा observations समझने में मदद चाहिए?
AuthSetu सार्वजनिक स्रोतों पर आधारित trust और exposure intelligence पर केंद्रित है। CDS वेबसाइट configuration की समीक्षा करने और निष्कर्षों को व्यावहारिक भाषा में समझाने में मदद कर सकता है। किसी भी गहरे assessment के लिए सहमत और अधिकृत scope ज़रूरी है।
दायरा और सीमाएँ: Header observations केवल जाँचे गए endpoint और समय से संबंधित हैं। CDN, proxies, redirects, caches और application logic परिणाम बदल सकते हैं। Automated extraction controls को पहचानने में चूक सकता है या गलत वर्गीकृत कर सकता है। Header का होना या न होना vulnerability, compromise, malware, data theft या दुर्भावनापूर्ण इरादे को साबित नहीं करता।