OnSumo Tools

HTTP Header Security Analyzer

This tool parses HTTP request and response headers and explains each field in plain English. Paste a raw header block and the tool identifies every header name, shows its value, and tells you what it controls - caching, security, content type, CORS, cookies, and more. Nothing is sent to a server. The tool is free, requires no login, and works offline once the page loads.

A

Security grade A

Score 60 / 60

Grade is based on header presence and values. CSP effectiveness depends on policy details beyond this tool's scope.

Header checks

  • Strict-Transport-Securitypass

    max-age=31536000; includeSubDomains

    HSTS is set with a one-year max-age and includeSubDomains.

  • Content-Security-Policypass

    default-src 'self'; script-src 'self'; style-src 'self'

    CSP is present and script-src avoids unsafe-inline and unsafe-eval.

  • X-Frame-Optionspass

    DENY

    X-Frame-Options is set to DENY.

  • X-Content-Type-Optionspass

    nosniff

    nosniff blocks MIME type sniffing.

  • Referrer-Policypass

    strict-origin-when-cross-origin

    strict-origin-when-cross-origin limits referrer leakage.

  • Permissions-Policypass

    geolocation=(), microphone=(), camera=()

    Permissions-Policy restricts browser capabilities.

CSP policy template

Content-Security-Policy: default-src 'self'; base-uri 'self'; frame-ancestors 'none'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; upgrade-insecure-requests

Header analysis runs in your browser. Pasted headers stay on your device unless you choose to fetch a URL.

How this tool works

The HTTP header analyzer fetches response headers from a public URL and evaluates each security-relevant header against current best-practice recommendations. For each header the tool assigns a pass, warn, or fail rating with an explanation. Strict-Transport-Security (HSTS) should include max-age of at least 31,536,000 seconds and the includeSubDomains directive; a missing or short-TTL HSTS allows protocol downgrade attacks. Content-Security-Policy should restrict script-src, style-src, and connect-src to trusted origins and avoid unsafe-inline and unsafe-eval, which negate XSS protection. X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing responses. X-Frame-Options (or CSP frame-ancestors) prevents clickjacking. Referrer-Policy controls how much URL information is shared with third parties on link clicks. Permissions-Policy restricts browser feature access (camera, microphone, geolocation). Key assumption: the analysis reflects headers returned at fetch time. CDN edge nodes may return different headers than the origin server, and some security headers are intentionally absent on unauthenticated responses. Edge case: a Content-Security-Policy that is too restrictive breaks legitimate page functionality -- a broken CSP is worse than no CSP if it blocks required scripts or styles. The tool links each CSP directive to documentation and highlights the specific directive causing a violation when unsafe-inline is present, rather than flagging the entire policy as failed.

Worked example

Before launch you copy response headers from staging. You see WARN on CSP because script-src still allows unsafe-inline, then paste the recommended CSP template into your server config.

Frequently asked questions

  • What headers are most important for security?

    The six headers that have the biggest security impact are: Strict-Transport-Security (enforces HTTPS), Content-Security-Policy (prevents XSS), X-Content-Type-Options: nosniff (prevents MIME sniffing), X-Frame-Options or CSP frame-ancestors (prevents clickjacking), Referrer-Policy (controls what URL is sent in the Referer header), and Permissions-Policy (restricts access to browser APIs like camera and microphone). The tool flags if any of these are absent.

  • What does Cache-Control: no-cache vs no-store mean?

    no-cache means the browser can store a cached copy but must revalidate it with the server before using it (sending If-None-Match or If-Modified-Since). The server can then return 304 Not Modified, saving the response body download. no-store means the browser must not store any copy at all, in memory or on disk. Use no-store for responses containing credentials, tokens, or personally identifiable information. Use no-cache for content that changes frequently but is safe to cache.

  • What is the Vary header and why does it matter for CDNs?

    The Vary header tells caches which request headers affect the response content. For example, Vary: Accept-Encoding means the server may send different content to a client that accepts gzip vs one that does not. The CDN must maintain separate cache entries for each variation. A common mistake is returning a CORS header but not including Vary: Origin, which causes CDNs to cache the first CORS response and serve it to all subsequent requestors regardless of their origin.

  • What does a missing Content-Type header mean?

    Without a Content-Type header, the browser must guess the content type by examining the response body (MIME sniffing). This can be a security risk: a file uploaded by an attacker and served without a content type might be executed as JavaScript or HTML if the browser guesses wrong. Always send an explicit Content-Type, and pair it with X-Content-Type-Options: nosniff to prevent the browser from overriding your declared type.

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

    X-Frame-Options is an older header with two values: DENY (never allow framing) and SAMEORIGIN (only allow framing from the same origin). Content-Security-Policy: frame-ancestors is the modern equivalent and is more flexible: it accepts a list of specific origins. CSP frame-ancestors overrides X-Frame-Options in modern browsers. For new deployments, use CSP; keep X-Frame-Options as a fallback for older browsers.

  • Why does the tool show my ETag as weak?

    ETags come in two forms: strong (\\\"abc123\\\") and weak (W/\\\"abc123\\\"). A strong ETag means the response body is byte-for-byte identical to the cached version. A weak ETag means the responses are semantically equivalent but may differ in minor ways (like whitespace). Weak ETags cannot be used with range requests. The tool flags weak ETags so you know whether your caching strategy supports byte-range requests.