HTTP Header Analyzer

HTTP response headers dictate how web browsers execute scripts, isolate frames, cache assets, and enforce transport encryption. This free, client-side HTTP Header Analyzer audits your response headers against modern OWASP security standards, uncovers dangerous server and runtime version leaks, analyzes Cache-Control efficiency, and validates cookie flags. Everything runs strictly in your browser—your server headers and session tokens are never transmitted to external servers.

# Configure your headers in Step 1 to generate tailored hardening snippets

Understanding HTTP Response Headers and Modern Web Security

Every time a client requests a URL, the web server or reverse proxy returns a structured set of HTTP response headers before transmitting the document body. Defined formally across RFC 9110 (HTTP Semantics) and RFC 9111 (HTTP Caching), these key-value pairs govern how browsers process, render, isolate, and cache web applications.

While HTML markup instructs the browser on what visual elements to render, HTTP headers dictate the underlying security boundaries and execution privileges. Modern security mitigations—including frame sandboxing against clickjacking, script execution constraints against Cross-Site Scripting (XSS), automatic protocol upgrades against Man-in-the-Middle (MitM) attacks, and strict cross-origin isolation—rely exclusively on valid response headers.

Deploying production websites without strict security headers is akin to constructing a high-security facility and leaving the front doors unlocked. Automated malicious scanners constantly crawl the public web searching for missing headers, unconfigured cookie flags, and exposed version banners to execute targeted exploits.

The OWASP Recommended Security Headers Checklist

The Open Web Application Security Project (OWASP) maintains the Secure Headers Project to establish defensible baselines for web applications. The following comparison table outlines the essential security headers, their recommended baseline configurations, and the threat vectors they neutralize:

How the HTTP Header Analyzer Scoring Engine Works

Rather than providing an arbitrary pass/fail result, this analyzer scores responses on an objective 100-point scale divided into four architectural pillars:

1. Security Posture (40 Points Max): Evaluates HSTS duration (10 pts), Content Security Policy strength (12 pts), MIME-type sniffing defense (5 pts), clickjacking restrictions (5 pts), Referrer-Policy privacy (4 pts), and hardware Permissions-Policy (4 pts). Deductions are applied for permissive directives like 'unsafe-inline' or 'unsafe-eval'.
2. Information Disclosure & Fingerprinting (15 Points Max): Assesses server and framework metadata leakage. Starts at 15 points; deducts 6 points if the Server header exposes precise software version numbers (e.g. Apache/2.4.41 (Ubuntu)), 6 points for active X-Powered-By banners (e.g. PHP/7.4.30), and 3 points for framework version headers like X-AspNet-Version.
3. Caching & CDN Delivery (25 Points Max): Analyzes Cache-Control syntax and directive hygiene (10 pts), conditional validation tokens such as ETag or Last-Modified (8 pts), and payload compression like Brotli (br), Zstandard (zstd), or Gzip (7 pts). Conflicting directives (such as pairing no-store with public, max-age) are flagged.
4. Cookie & Transport Security (20 Points Max): Audits Set-Cookie headers for the three critical defense attributes: Secure (prevents unencrypted plaintext transmission), HttpOnly (blocks JavaScript DOM access via document.cookie), and SameSite=Lax or SameSite=Strict (prevents Cross-Site Request Forgery). Stateless endpoints without cookies receive full credit. Validates proper Content-Type and charset declarations.

Eliminating Information Leakage and Server Fingerprinting

One of the most frequent findings in enterprise security audits is unnecessary server banner leakage. When a web server emits Server: Apache/2.4.41 (Ubuntu) mod_ssl/2.4.41 OpenSSL/1.1.1f or X-Powered-By: Express, it grants automated adversaries immediate reconnaissance data.

Automated exploit engines, such as Shodan, Censys, and Metasploit, continuously index the web by filtering for specific server version strings with known CVEs (Common Vulnerabilities and Exposures). When a newly disclosed zero-day or remote code execution flaw strikes a specific patch release, servers broadcasting their exact version become immediate targets.

Suppression is straightforward. In Nginx, adding server_tokens off; eliminates version numbers. In Apache, setting ServerTokens Prod and ServerSignature Off reduces the banner to generic Apache branding. Stripping X-Powered-By in application runtimes (such as app.disable('x-powered-by') in Node.js Express or expose_php = Off in php.ini) completely eradicates framework fingerprints.

Mastering Cache-Control and CDN Edge Delivery

Caching efficiency directly impacts Core Web Vitals, page speed, and infrastructure hosting costs. However, poor header syntax frequently leads to either stale data bugs or catastrophic origin server overload. Key directives defined under RFC 9111 include:

• max-age=<seconds>: Directs browser caches how long an asset is considered fresh before revalidation is required.
• s-maxage=<seconds>: Overrides max-age specifically for shared caches, including edge CDNs (Cloudflare, Fastly, CloudFront) and reverse proxies.
• stale-while-revalidate=<seconds>: Instructs clients to serve a cached response immediately while asynchronously fetching a fresh version in the background, eliminating blocking roundtrips.
• immutable: Informs clients that the resource body will never change during its valid lifetime, preventing conditional 304 revalidation checks when users refresh the page. Essential for versioned static assets (e.g. app.8f9b2c.js).
• no-cache vs no-store: A common misconception is that no-cache prevents storage. In reality, no-cache allows storage but forces validation with the origin before every reuse. no-store instructs all caches to never write the response to disk or memory.

Cookie Security: The Holy Trinity of Secure, HttpOnly, and SameSite

Session cookies are the primary authentication currency of modern web applications. If an attacker intercepts or steals an active session cookie, they assume the victim's identity without ever needing passwords or two-factor authentication tokens.

Hardening cookies requires three complementary attributes:

1. Secure: Ensures the browser will only transmit the cookie over encrypted HTTPS connections. This prevents eavesdropping over public Wi-Fi or local networks.
2. HttpOnly: Blocks client-side JavaScript APIs (including document.cookie) from reading or writing the cookie. If an attacker manages to exploit a Cross-Site Scripting (XSS) vulnerability, the HttpOnly flag prevents their script from stealing the authentication token.
3. SameSite (Strict or Lax): Dictates whether the cookie is transmitted along with cross-site requests. SameSite=Strict withholds the cookie on all cross-origin requests, including third-party link clicks. SameSite=Lax (the browser default) permits cookie transmission on safe top-level navigations while blocking it on cross-origin image requests or POST form submissions, mitigating Cross-Site Request Forgery (CSRF).

Production Server Hardening Configuration Guides

To eliminate security header deficiencies, apply the following production configurations tailored to your web server or reverse proxy:

1. Nginx Configuration (nginx.conf)

Add the following directives inside your server { ... } or http { ... } configuration block:

# Suppress server tokens and framework leaks
server_tokens off;
fastcgi_hide_header X-Powered-By;
proxy_hide_header X-Powered-By;

# Enforce HTTPS Transport Security (HSTS)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Prevent MIME-type sniffing
add_header X-Content-Type-Options "nosniff" always;

# Mitigate clickjacking (superseded by CSP frame-ancestors)
add_header X-Frame-Options "DENY" always;

# Restrict sensitive referrer data
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Restrict device hardware APIs
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# Content Security Policy (Adjust domains to match your CDN and analytics)
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';" always;

2. Apache Configuration (.htaccess or httpd.conf)

Ensure mod_headers is enabled, and place the following inside your root .htaccess or virtual host file:

# Suppress Apache signature
ServerSignature Off
ServerTokens Prod

<IfModule mod_headers.c>
    # HSTS (31536000s = 1 year)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    # MIME sniffing prevention
    Header always set X-Content-Type-Options "nosniff"

    # Clickjacking protection
    Header always set X-Frame-Options "DENY"

    # Referrer privacy
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Hardware permissions
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

    # Baseline Content Security Policy
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';"

    # Strip backend leak tokens
    Header unset X-Powered-By
    Header always unset X-Powered-By
</IfModule>

3. Caddy Configuration (Caddyfile)

Caddy automatically handles TLS and HTTPS redirection, but custom security headers should be declared explicitly in your site block:

example.com {
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
        Permissions-Policy "camera=(), microphone=(), geolocation=()"
        Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';"
        -Server
        -X-Powered-By
    }
    reverse_proxy localhost:3000
}

Frequently Asked Questions

Why can't this analyzer fetch headers directly from a URL like other online tools?

Modern web browsers enforce strict Cross-Origin Resource Sharing (CORS) security policies that forbid client-side scripts from reading arbitrary headers from third-party websites without preflight permission. Online tools that fetch headers by URL route your requests through backend proxy servers, which can log your domain, IP address, and private response cookies. This analyzer runs entirely in your local browser sandbox—your session tokens, internal staging URLs, and staging headers remain private on your machine.

What is the difference between X-Frame-Options and CSP frame-ancestors?

X-Frame-Options is a legacy header introduced by Microsoft Internet Explorer in 2008 to mitigate clickjacking by restricting whether a page can be rendered inside an <iframe>, <frame>, or <object>. While widely supported, it only supports crude DENY and SAMEORIGIN directives. The W3C Content Security Policy Level 2 introduced frame-ancestors, which offers granular control by allowing multiple authorized parent origins (e.g., frame-ancestors 'self' https://partner.example.com). Modern browsers prioritize frame-ancestors over X-Frame-Options, though deploying both ensures complete backward compatibility.

Why does HSTS require 31,536,000 seconds (1 year) for preloading?

The Chrome HSTS Preload list (shared by Chrome, Firefox, Safari, and Edge) requires a minimum max-age of 31,536,000 seconds (one full year), accompanied by the includeSubDomains and preload directives. This stringent requirement ensures that once hardcoded into browser source trees, clients will never attempt an insecure HTTP connection to your domain, eliminating the vulnerable initial plain-HTTP redirect.

How do I test Content-Security-Policy without breaking my website?

Deploying a strict CSP on an existing web application can inadvertently block legitimate analytics, fonts, or third-party scripts. To prevent outages, deploy the Content-Security-Policy-Report-Only header first. In report-only mode, the browser logs violations to your designated report-uri or report-to endpoint without actually blocking script execution. Once you review violation logs and refine directives, switch to the enforcing Content-Security-Policy header.

How should Cache-Control differ between static assets and dynamic HTML?

Static assets that incorporate content hashes in their filenames (such as bundle.a8f92c.js or style.99b2a1.css) should use aggressive caching: Cache-Control: public, max-age=31536000, immutable. Because any file modification results in a new URL, browsers can safely cache the file for a year without checking the origin. Conversely, HTML documents should never be cached permanently; they should use Cache-Control: no-cache or Cache-Control: public, max-age=0, must-revalidate alongside an ETag to ensure users always receive the newest HTML referring to the newest asset bundles.

What is the security risk of having Access-Control-Allow-Origin: * with credentials?

If a server responds with Access-Control-Allow-Origin: * while also specifying Access-Control-Allow-Credentials: true, modern browsers will outright reject the response as a violation of the Fetch specification. If this were permitted, any malicious website visited by an authenticated user could make cross-origin requests, include the user's private session cookies, and read the confidential response data.

Related Developer & Security Tools

• User-Agent Parser — Inspect and decode client device capabilities, browser engines, and operating system tokens.
• SSL Expiry Checker — Audit TLS certificate validity dates, issuer authority, and automated renewal timelines.
• DNS & Port Lookup Helper — Query standard networking records and verify open port security postures.
• .htaccess Redirect Generator — Generate clean Apache redirect rules and canonical HTTPS rewrites.
• Sending Domain Readiness Checklist — Verify SPF, DKIM, DMARC, and DNS records to protect email deliverability.
• Cold Email & Outreach Services — Comprehensive B2B outreach infrastructure, deliverability audits, and technical domain configuration.