The OWASP Secure Headers Project maintains a widely cited baseline of response headers that harden a site against common attacks: Content-Security-Policy restricts which scripts and resources a page may load, Strict-Transport-Security (HSTS) forces the browser to only ever connect over HTTPS for that domain, and X-Content-Type-Options: nosniff stops the browser from guessing a file's type and executing something it shouldn't.
Request headers vs. response headers
Request headers (like Accept, User-Agent, Cookie) the browser sends to the server, describing itself and its expectations. Response headers (Content-Type, Set-Cookie, Cache-Control) the server sends back, describing the returned data and instructions for the browser.
Why Content-Type matters
The Content-Type header tells the browser how to interpret the response body: as an HTML page, JSON data, an image, or a file to download. Without the right value here, a browser might try to render JSON as plain text, or fail to handle HTML correctly.
How Cache-Control governs caching
Values like max-age=3600 or no-cache tell the browser and any intermediate proxies how long a cached copy of a resource can be used before requesting it again from the server. Misconfiguring this header is a common reason users end up seeing a stale version of a site.
Why you'd need this
- Diagnosing why a browser is rendering an API response incorrectly.
- Auditing which of the OWASP-recommended security headers a site is actually sending, and which are missing.
- Confirming a site is served over HTTPS — a hard requirement for the Web Crypto API this site's own hash and JWT tools depend on.
Why a header sometimes shows up more than once
The HTTP spec allows some headers to repeat within a single response — the most common example is multiple Set-Cookie lines, one per cookie. For most other headers, repeated values are officially equivalent to a single header with values joined by commas, but Set-Cookie is a deliberate exception, since a comma is a normal character inside cookie values.