HTTP Header Analyzer — Check Security, CORS & Cache Headers

HTTP headers quietly control caching, browser security, redirects, content types, cookies, CORS, and API behavior. Reading them well helps you debug production issues faster and catch missing security protections before they become real problems.

What are HTTP headers?

HTTP headers are key-value metadata sent with requests and responses. They tell browsers and clients how to handle content, how long to cache it, which origins can access it, and which security rules should apply.

HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=3600
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

A single missing or misconfigured header can create confusing bugs: stale assets, blocked API calls, mixed content warnings, broken downloads, or avoidable browser security risk.

Security headers worth checking

• Strict-Transport-Security — tells browsers to use HTTPS for future requests.
• Content-Security-Policy — limits where scripts, images, frames, and styles can load from.
• X-Content-Type-Options — prevents MIME sniffing with nosniff.
• X-Frame-Options or CSP frame-ancestors — reduces clickjacking risk.
• Referrer-Policy — controls how much URL information is sent to other sites.
• Permissions-Policy — limits browser features such as camera, microphone, or geolocation.

CORS and caching checks

CORS headers decide whether browser JavaScript can read a response from another origin. Cache headers decide how long browsers and CDNs reuse a response. These two areas often cause issues that are hard to reproduce locally.

• Access-Control-Allow-Origin should be specific for private APIs.
• Access-Control-Allow-Credentials should not be paired casually with wildcard origins.
• Cache-Control should match the content type: immutable for versioned assets, short or no-store for private data.
• Vary should include headers that affect the response, such as Origin or Accept-Encoding.

How to analyze headers using inspectly.dev

1. Open inspectly.dev/headers
2. Paste raw response headers from your browser devtools, terminal, CDN, or API client
3. Click Analyze
4. Review the security grade, missing headers, caching behavior, CORS notes, and parsed raw output
5. Copy the suggestions into your framework, reverse proxy, or CDN config

Common header problems

• Missing HSTS — HTTPS works today, but browsers are not told to keep using it.
• Weak CSP — overly broad sources such as * or unsafe inline scripts reduce protection.
• Wrong content type — JSON, images, PDFs, and downloads should declare the expected MIME type.
• Private data cached publicly — user-specific pages should avoid CDN or shared browser cache leaks.
• CORS wildcard on authenticated APIs — broad access can create avoidable exposure.

Frequently asked questions

Can headers alone make a site secure?

No. Headers are one layer. They reduce browser-side risk, but you still need safe authentication, authorization, input validation, dependency hygiene, and server-side controls.

Where do I get raw headers?

Browser devtools, curl -I, API clients, CDN logs, and reverse proxy debug tools can all show response headers.

Should every site use the same CSP?

No. A Content Security Policy must match the scripts, styles, images, frames, and third-party services your site actually uses.