Secure Infrastructure • Verification • Operations
Secure Infrastructure • Verification • Operations
AUTHSETU • SECURITY & DIGITAL INTELLIGENCE • 2026
HTTP response headers are small pieces of metadata returned with a website response. Some guide browser behaviour; others disclose technology or operational details. Together, they provide a useful—but limited—external view of a website’s configuration.
What security-related headers can tell you
HSTS — Strict-Transport-Security
Can tell compatible browsers to use HTTPS for a specified period after they receive the policy. Its presence is a transport-hardening signal; its absence must be interpreted alongside actual HTTP/HTTPS behaviour and deployment needs.
Content-Security-Policy (CSP)
Defines where a page may load scripts, styles, frames and other resources from. A carefully designed policy can reduce certain browser-side injection and content-loading risks. Presence alone does not show that the policy is strong.
X-Content-Type-Options
The commonly used nosniff value limits MIME-type sniffing. It is one useful browser-side hardening control, not a complete application defence.
X-Frame-Options / CSP frame controls
Can restrict whether pages may be embedded in frames and help reduce clickjacking exposure. A header check does not prove that every page and workflow has been assessed.
Referrer-Policy
Controls how much referrer information browsers send with requests. The policy should balance privacy and operational needs such as analytics.
Permissions-Policy
Can restrict selected browser capabilities, such as camera, microphone or geolocation, for pages and frames. The appropriate policy depends on the website’s actual features.
Server / X-Powered-By
May disclose server, framework, runtime or hosting details. Owners can review whether this information is necessary. Disclosure alone does not prove that the software is exploitable.
Presence is not enough—and absence is not enough
| Observation | Reasonable interpretation | What it does not prove |
|---|---|---|
| HSTS observed | A transport-hardening control is being served at the tested endpoint. | The entire website is secure. |
| CSP observed | A browser content policy is present. | The policy is correctly designed or blocks every relevant attack. |
| CSP not observed | Review whether browser-policy hardening is appropriate. | The site is vulnerable or compromised. |
| Server version disclosed | Technology fingerprinting information is exposed. | The disclosed software is exploitable. |
| Several headers absent | The browser-security baseline may have hardening opportunities. | An attack or data theft has occurred. |
| Multiple headers present | Several defensive controls are observable. | All controls are correctly configured. |
What our September 2026 review showed
The CDS/AuthSetu normalized V5 dataset covered 92 authorized public-facing targets and 9,977 normalized observations. HSTS was observed on 50 targets (54.3%) and CSP on 45 targets (48.9%). These figures describe only that reviewed dataset; they are not representative statistics for all Indian small-business websites.
The underlying reports included both positive and incomplete header postures. That is why header interpretation requires context and endpoint-level verification rather than a simple “secure/insecure” label.
Why automated header reports can disagree
Scanners and parsers may differ because of redirects, CDN or proxy behaviour, caching, user-agent differences, endpoint selection, parser normalization and changes in live configuration. In this review, earlier V4 extraction and later V5 normalization did not agree on every header or technology field. The benchmark therefore preserves parser-dependent discrepancies instead of silently converting them into vulnerabilities.
A practical header-review workflow
- Define the exact endpoint and request context.
- Capture status code, redirect chain and response headers.
- Record date, time and relevant request conditions.
- Separate security controls from technology disclosures and operational metadata.
- Inspect actual header values—not only whether a header exists.
- Compare related endpoints where appropriate.
- Correlate findings with TLS, cookies, DNS, technology and application evidence.
- Classify each item as observed, inferred, unverified or conflicting.
- State what the evidence does not prove.
- Recommend proportionate validation or remediation.
Why this matters to a business
- Trust: Consistent browser-security configuration supports a deliberate digital-infrastructure posture.
- Exposure: Unnecessary server/runtime disclosure may help public observers fingerprint a platform.
- Security: Appropriate headers can reduce specific browser-side risks and strengthen defence-in-depth.
- Governance: A recorded baseline helps teams detect configuration drift after redesigns, migrations or platform changes.
What a professional finding should sound like
Weak: “Your website has terrible security because security headers are missing.”
Headers are not a penetration test
A header review is passive external evidence. A penetration test is a deeper, authorized security assessment that may include controlled validation of vulnerabilities and application behaviour. Do not represent one as the other. The assessment depth should match the system’s risk and explicit authorization.
Related reading
Need help interpreting website security observations?
AuthSetu focuses on public-source trust and exposure intelligence. CDS can help review website configuration and explain findings in practical terms. Any deeper assessment must have an agreed and authorized scope.
Scope and limitations: Header observations are specific to the endpoint and time tested. CDNs, proxies, redirects, caches and application logic can affect results. Automated extraction can miss or misclassify controls. Presence or absence of a header does not establish vulnerability, compromise, malware, data theft or malicious intent.