HTTP Header Analyzer
Parse and inspect HTTP request/response headers for security flags.
HTTP Header Analyzer
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The HTTP Header Analyzer parses a raw set of HTTP request or response headers and inspects them for security-relevant configuration: whether CORS is set up correctly, whether caching directives are present and sensible, whether security headers like HSTS and Content-Security-Policy exist at all, and whether anything looks misconfigured or missing relative to common best practice. Headers carry most of the metadata that governs how a browser or client actually treats a request or response, but they're easy to overlook when debugging, since a status code alone doesn't reveal anything about them.
- This matters because a surprising number of real-world security and behavior issues live entirely in header configuration rather than application logic: a missing Content-Security-Policy leaves an application more exposed to XSS; an overly permissive Access-Control-Allow-Origin can expose an API to requests from any origin; a missing or misconfigured Cache-Control header can cause sensitive responses to be cached somewhere they shouldn't be. None of these show up as an error — they're silent misconfigurations that only become visible when someone specifically inspects the headers.
- This tool is a reference and inspection aid, not a live network scanner — you paste in headers you've already captured (from browser dev tools, a curl -I command, or a proxy log) and it explains what each one does and flags anything that looks off, rather than making the request itself.
How It Works
- You paste a raw header block — either a full set of response headers or request headers — into the input.
- The tool parses each header name and value into a structured list.
- Each recognized header is annotated with what it does and, where relevant, whether its current value follows common best practice (for example, whether Cache-Control on a response containing sensitive data actually includes no-store, or whether Access-Control-Allow-Origin is scoped to a specific origin rather than a wildcard).
- Security-relevant headers that are expected but absent (such as Strict-Transport-Security or Content-Security-Policy on an HTTPS response) are flagged as missing, since an absence is often as significant as a misconfigured value.
Usage
- Capture the headers you want to inspect — from browser dev tools' Network tab, a curl -I or curl -v command, or a proxy/logging tool.
- Paste the raw header block into the analyzer.
- Review the parsed, annotated list: what each header does, and any flags for missing or potentially misconfigured security-relevant headers.
- Cross-reference flagged issues against your actual security requirements — not every flagged item is necessarily wrong for your specific context, but each is worth a deliberate decision rather than an accidental default.
Examples
- Analyzing a set of response headers and finding no Content-Security-Policy header present at all, flagging it as a missing defense-in-depth layer against XSS.
- Debugging a CORS error by finding Access-Control-Allow-Origin is set to a specific origin that doesn't match the one actually making the request.
- Reviewing Cache-Control: public, max-age=3600 on a response that contains user-specific data, flagging it as a likely misconfiguration since that response probably shouldn't be cached by shared/public caches.
- Confirming Strict-Transport-Security is present with a reasonable max-age on a production HTTPS response, verifying the site correctly enforces future HTTPS-only connections to browsers that have seen it.
Real-World Use Cases
- Reviewing a service's response headers for missing or misconfigured security headers (CSP, HSTS, X-Content-Type-Options) as part of a security review.
- Debugging a CORS failure by inspecting the actual Access-Control-* headers a server returned, rather than guessing from the browser's error message alone.
- Investigating unexpected caching behavior by checking exactly what Cache-Control, ETag, and related headers a response actually sent.
- Understanding an unfamiliar header seen in a request or response by looking up what it does and why it might be present.
Best Practices
- Treat a flagged missing security header as a prompt to make a deliberate decision, not an automatic requirement — some headers matter more for some applications (a public read-only API has different needs than a session-authenticated dashboard).
- Check both request and response headers when debugging an integration issue — CORS failures specifically require looking at what the browser sent in its preflight request alongside what the server actually returned.
- Re-check header configuration after any change to a reverse proxy, CDN, or load balancer in front of your application — these layers frequently add, strip, or override headers your application code sets, silently changing behavior.
- Scope CORS headers as narrowly as your application actually requires — a wildcard Access-Control-Allow-Origin is convenient during development but usually too permissive for a production API handling authenticated requests.
Common Mistakes
- Assuming a missing security header is an oversight rather than checking whether it was deliberately omitted for a documented reason — flag it, but verify before assuming it's simply wrong.
- Debugging a CORS error purely from the browser's console message without actually inspecting the real request and response headers, missing the specific header mismatch causing the failure.
- Setting Cache-Control headers based on convenience rather than actual data sensitivity, resulting in either unwanted caching of sensitive responses or unwanted freshness checks on genuinely static content.
- Not re-verifying headers after introducing a CDN or reverse proxy, assuming the application's own header configuration is still what's actually reaching the client unchanged.
Limitations
- This tool analyzes headers you provide; it does not make live requests to fetch them itself, so the analysis is only as current as when you captured the headers.
- Best-practice flags reflect common, general security guidance — they are not a substitute for a security review tailored to your application's specific threat model and requirements.
- It recognizes and annotates widely-used standard and security-relevant headers; highly custom or vendor-specific headers may be listed without a detailed annotation if they fall outside common conventions.
Technical Reference Guide
- HTTP header syntax and semantics are defined by RFC 9110 (HTTP Semantics), which superseded RFC 7231.
- Content-Security-Policy is defined by the W3C CSP specification; Strict-Transport-Security (HSTS) is defined by RFC 6797.
- CORS (Cross-Origin Resource Sharing) and the Access-Control-* headers it relies on are defined by the WHATWG Fetch standard, not a dedicated IETF RFC.
FAQ
Why would a missing security header matter if my site works fine without it?
Security headers are defense-in-depth — a site can function normally while still being more exposed than necessary to attacks like XSS or clickjacking that these headers specifically mitigate. 'It works' and 'it's appropriately hardened' are different questions.
Why is my CORS request still failing even though I set Access-Control-Allow-Origin?
CORS has several other requirements depending on the request type — preflight requests need Access-Control-Allow-Methods and Access-Control-Allow-Headers to cover what the actual request uses, and credentialed requests need Access-Control-Allow-Credentials plus a non-wildcard origin. Inspect the full header set, not just one value.
Is a wildcard Access-Control-Allow-Origin always wrong?
Not always — it's appropriate for genuinely public, unauthenticated APIs. It becomes a real problem specifically when combined with credentialed requests or when the response contains data that shouldn't be readable from arbitrary origins.
What does Cache-Control: no-store actually prevent?
It tells any cache — browser, proxy, or CDN — not to store the response at all, appropriate for responses containing sensitive or user-specific data that should never be retained anywhere after the response is delivered.
Does this tool check my live website's actual headers?
No — it analyzes whatever headers you paste in, captured from a tool like your browser's dev tools or curl. It doesn't make network requests itself.
Why do headers sometimes differ between what my application sets and what I see in the browser?
A reverse proxy, CDN, or load balancer in front of your application can add, remove, or override headers before they reach the client — always inspect headers at the point closest to what the end user actually receives when debugging a discrepancy.
Part of this Developer Hub
This utility is part of our comprehensive HTTP & Web Protocols topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the API & Web Engineering Lab workshop for complementary engineering workflows.
View all API & Web Engineering Lab tools