Secure Infrastructure • Verification • Operations
Secure Infrastructure • Verification • Operations
AUTHSETU • सुरक्षा आणि डिजिटल इंटेलिजन्स • २०२६
वेबसाइटकडून प्रतिसाद मिळताना HTTP response headers नावाची लहान metadata माहितीही परत येते. काही headers ब्राउझरचे वर्तन नियंत्रित करतात; तर काही तंत्रज्ञान किंवा ऑपरेशनल तपशील उघड करतात. यांमधून वेबसाइटच्या configuration चा उपयोगी, पण मर्यादित, बाह्य अंदाज मिळू शकतो.
सुरक्षेशी संबंधित headers काय सांगू शकतात?
HSTS — Strict-Transport-Security
Policy मिळाल्यानंतर ठरावीक काळ HTTPS वापरण्यास compatible browsers ना सांगू शकते. याची उपस्थिती transport hardening चा संकेत आहे; अनुपस्थितीचा अर्थ प्रत्यक्ष HTTP/HTTPS वर्तन आणि deployment गरजांसह तपासावा.
Content-Security-Policy (CSP)
पृष्ठाला scripts, styles, frames आणि इतर resources कुठून लोड करता येतील हे ठरवते. योग्यरीत्या तयार केलेली policy काही browser-side injection आणि content-loading जोखीम कमी करू शकते. Header आहे एवढ्याने 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
ब्राउझर requests सोबत किती referrer माहिती पाठवतो हे नियंत्रित करते. Policy निवडताना privacy आणि analytics सारख्या गरजांचा समतोल ठेवावा.
Permissions-Policy
पृष्ठे आणि frames साठी camera, microphone किंवा geolocation सारख्या browser capabilities मर्यादित करू शकते. योग्य policy वेबसाइटच्या प्रत्यक्ष features वर अवलंबून असते.
Server / X-Powered-By
Server, framework, runtime किंवा hosting बद्दल माहिती उघड होऊ शकते. ही माहिती सार्वजनिकपणे दाखवण्याची गरज आहे का ते मालकाने तपासावे. माहिती उघड होणे म्हणजे software exploitable आहे याचा पुरावा नाही.
उपस्थिती पुरेशी नाही—अनुपस्थितीही पुरेशी नाही
| निरीक्षण | वाजवी अर्थ | यावरून काय सिद्ध होत नाही |
|---|---|---|
| HSTS दिसले | तपासलेल्या endpoint वर transport-hardening control दिले जात आहे. | संपूर्ण वेबसाइट सुरक्षित आहे. |
| CSP दिसले | Browser content policy उपलब्ध आहे. | Policy योग्य आहे किंवा प्रत्येक संबंधित हल्ला रोखते. |
| CSP दिसले नाही | Browser-policy hardening योग्य आहे का ते तपासा. | वेबसाइट vulnerable किंवा compromised आहे. |
| Server version उघड झाली | तंत्रज्ञान ओळखण्यासाठी उपयोगी माहिती दिसत आहे. | ते software exploit करता येते. |
| अनेक headers अनुपस्थित | Browser-security baseline अधिक मजबूत करण्याची संधी असू शकते. | हल्ला किंवा data theft झाले आहे. |
| अनेक headers उपस्थित | काही defensive controls दिसत आहेत. | सर्व controls योग्यरीत्या configured आहेत. |
सप्टेंबर २०२६ च्या पुनरावलोकनात काय दिसले?
CDS/AuthSetu च्या normalized V5 dataset मध्ये ९२ अधिकृत public-facing targets आणि ९,९७७ normalized observations समाविष्ट होते. ५० targets (५४.३%) वर HSTS आणि ४५ targets (४८.९%) वर CSP नोंदले गेले. हे आकडे फक्त त्या तपासलेल्या dataset चे आहेत; भारतातील सर्व लघु व्यवसायांच्या वेबसाइट्सचे प्रतिनिधिक आकडे नाहीत.
मूळ अहवालांत headers ची चांगली आणि अपूर्ण अशी दोन्ही स्थिती आढळली. म्हणून headers चे अर्थ लावताना संदर्भ आणि प्रत्येक endpoint ची पडताळणी आवश्यक आहे; केवळ “सुरक्षित/असुरक्षित” असा शिक्का पुरेसा नाही.
Automated reports मध्ये मतभेद का होऊ शकतात?
Redirects, CDN किंवा proxy चे वर्तन, caching, user-agent मधील फरक, निवडलेला endpoint, parser normalization आणि live configuration मधील बदल यांमुळे scanners आणि parsers वेगवेगळे निष्कर्ष देऊ शकतात. या पुनरावलोकनात आधीच्या V4 extraction आणि नंतरच्या V5 normalization मध्ये प्रत्येक header किंवा technology field बाबत एकमत नव्हते. त्यामुळे मतभेद लपवून त्यांना vulnerabilities म्हणून मांडण्याऐवजी ते स्पष्ट नोंदवले जातात.
Headers तपासण्याची व्यावहारिक प्रक्रिया
- अचूक endpoint आणि request context निश्चित करा.
- Status code, redirect chain आणि response headers नोंदवा.
- दिनांक, वेळ आणि संबंधित request conditions नोंदवा.
- Security controls, technology disclosure आणि operational metadata वेगवेगळे ठेवा.
- Header आहे का एवढेच नव्हे, तर त्याचे actual value तपासा.
- योग्य असल्यास संबंधित endpoints ची तुलना करा.
- TLS, cookies, DNS, technology आणि application पुराव्याशी निष्कर्ष जुळवा.
- प्रत्येक बाब observed, inferred, unverified किंवा conflicting अशी वर्गीकृत करा.
- पुराव्याने काय सिद्ध होत नाही ते स्पष्ट लिहा.
- जोखमीच्या प्रमाणात पडताळणी किंवा remediation सुचवा.
व्यवसायासाठी हे का महत्त्वाचे आहे?
- विश्वास: सुसंगत browser-security configuration डिजिटल पायाभूत सुविधांकडे जाणीवपूर्वक लक्ष दिल्याचे दर्शवते.
- Exposure: अनावश्यक server/runtime माहिती सार्वजनिक निरीक्षकांना platform fingerprinting मध्ये मदत करू शकते.
- सुरक्षा: योग्य headers काही browser-side जोखीम कमी करून defence-in-depth मजबूत करू शकतात.
- Governance: नोंदवलेला baseline redesign, migration किंवा platform बदलांनंतर configuration drift ओळखण्यास मदत करतो.
व्यावसायिक निष्कर्ष कसा लिहावा?
कमकुवत मांडणी: “Security headers नाहीत, म्हणून तुमची वेबसाइट अत्यंत असुरक्षित आहे.”
Headers म्हणजे penetration test नाही
Header review हा बाहेरून मिळालेला passive पुरावा आहे. Penetration test ही अधिक सखोल, अधिकृत सुरक्षा तपासणी असते आणि त्यात vulnerabilities व application behaviour ची नियंत्रित पडताळणी असू शकते. एका प्रक्रियेला दुसरी म्हणून सादर करू नका. तपासणीची खोली प्रणालीची जोखीम आणि स्पष्ट अधिकृततेनुसार ठरवावी.
संबंधित वाचन
वेबसाइट सुरक्षा निरीक्षणांचा अर्थ समजून घ्यायचा आहे?
AuthSetu सार्वजनिक स्रोतांवर आधारित trust आणि exposure intelligence वर लक्ष केंद्रित करते. CDS वेबसाइट configuration तपासण्यात आणि निष्कर्ष व्यावहारिक भाषेत समजावण्यात मदत करू शकते. अधिक सखोल तपासणीसाठी स्पष्ट आणि अधिकृत scope आवश्यक आहे.
व्याप्ती आणि मर्यादा: Header observations विशिष्ट endpoint आणि तपासणीच्या वेळेपुरते असतात. CDN, proxies, redirects, caches आणि application logic परिणाम बदलू शकतात. Automated extraction controls ओळखण्यात चुकू शकते. Header असणे किंवा नसणे यावरून vulnerability, compromise, malware, data theft किंवा दुर्भावनापूर्ण हेतू सिद्ध होत नाही.