How do I get the response headers to paste in?

Open your browser developer tools, go to the network tab, select the request and copy the response headers. Alternatively run curl with the -I flag for a HEAD request, or -i to include headers with the body. Either output pastes in directly.

Which security headers should every site have?

Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options or CSP frame-ancestors, Referrer-Policy and Permissions-Policy. The analyser lists whichever of these your response is missing, which is usually a short and actionable list.

What max-age should HSTS use?

At least one year, 31536000 seconds, which is what preload lists require. A short max-age leaves a window in which a first visit over plain HTTP can be intercepted. Start shorter while testing if you are cautious, then raise it once you are confident every subdomain serves HTTPS correctly.

Why does it warn about my Set-Cookie header?

Because one of the three protective attributes is missing. HttpOnly keeps the cookie away from JavaScript, so an XSS bug cannot steal a session. Secure prevents it being sent over plain HTTP. SameSite limits its use in cross-site requests, which mitigates CSRF. For a session cookie all three should be present.

What is the wildcard and credentials problem in CORS?

Access-Control-Allow-Origin set to an asterisk cannot be combined with Access-Control-Allow-Credentials set to true. Browsers reject the response outright, because the combination would let any site on the internet make authenticated requests as the logged-in user. Name the specific origin instead.

Should I remove the Server and X-Powered-By headers?

Reducing them is worthwhile. They are not a vulnerability by themselves, but publishing your exact framework and version tells an attacker which known issues to try first. Removing X-Powered-By entirely and making Server generic costs nothing and removes free reconnaissance.

What does Vary actually do?

It tells caches which request headers change the response, so they can key their cache correctly. A response that differs by Accept-Encoding without a corresponding Vary can result in a compressed body being served to a client that did not ask for one. Vary on Accept-Encoding is almost always correct; Vary on Cookie effectively disables shared caching.

Is X-XSS-Protection still useful?

No. The browser filters it controlled have been removed, and in some cases they introduced vulnerabilities of their own. Current guidance is to omit it and rely on Content-Security-Policy, which addresses the same class of attack properly.

Does it check request headers too?

It recognises some request headers such as Authorization and Cookie when they appear, but the analysis is oriented towards response headers, which is where the security and caching decisions live. Paste a response for the most useful output.

Are the headers I paste sent to a server?

No. The analysis runs entirely in your browser, so headers containing session cookies, tokens and internal hostnames stay on your machine.

HTTP Header Analyzer – Check Security, CORS and Cache

HTTP Header Analyzer

// RESPONSE HEADERS

Status lineHTTP/1.1 200 OK

// HEADERS (18)

DateSERVER

Sat, 26 Apr 2026 12:00:00 GMT

When the server generated the response.

Content-TypeCONTENT

application/json; charset=utf-8

The media type of the response body. Specifying a charset is recommended.

application/json
charset=utf-8

Content-LengthCONTENT

1234

The size of the response body in bytes.

Cache-ControlCACHE

public, max-age=3600

Controls caching behaviour with directives such as public, private, max-age, no-store, no-cache and must-revalidate.

public
max-age=3600

Strict-Transport-SecuritySECURITY

max-age=31536000; includeSubDomains; preload

Forces HTTPS and stops the browser making plain HTTP requests. max-age sets how long, in seconds, the browser remembers this.

max-age=31536000
includeSubDomains
preload

Content-Security-PolicySECURITY

default-src 'self'; script-src 'self' 'unsafe-inline'

Restricts where scripts, styles, images and other resources may be loaded from. The single most effective header against XSS.

default-src 'self'
script-src 'self' 'unsafe-inline'

X-Content-Type-OptionsSECURITY

nosniff

Disables MIME sniffing. It should always be set to "nosniff".

X-Frame-OptionsSECURITY

DENY

Restricts embedding in an iframe, mitigating clickjacking. DENY or SAMEORIGIN are the sensible values.

Referrer-PolicySECURITY

strict-origin-when-cross-origin

Controls how much of the referring URL is sent with requests. strict-origin-when-cross-origin is the usual recommendation.

Permissions-PolicySECURITY

geolocation=(), camera=()

Controls which browser features, such as camera, microphone and geolocation, the page may use.

geolocation=()
camera=()

Access-Control-Allow-OriginCORS

https://app.example.com

Which origin may read the response cross-origin. An asterisk allows all; a URL restricts it to one.

Access-Control-Allow-CredentialsCORS

true

Permits requests carrying cookies or authorisation. When true, Allow-Origin cannot be an asterisk.

Set-Cookie

session=abc123; Path=/; Secure; HttpOnly; SameSite=Strict

Sets a cookie. Check for the Secure, HttpOnly and SameSite attributes.

session=abc123
Path=/
Secure
HttpOnly
SameSite=Strict

ETagCACHE

"33a64df5"

A version identifier for the resource, used with If-None-Match for conditional requests.

VaryCACHE

Accept-Encoding, Origin

Which request headers form part of the cache key. Accept-Encoding and Accept are the common ones.

Accept-Encoding
Origin

X-RateLimit-LimitRATE

1000

The maximum number of requests allowed per window. A de facto standard rather than a specified one.

X-RateLimit-RemainingRATE

998

How many requests remain in the current window.

ServerSERVER

nginx

Information about the server software. Including the version leaks information an attacker can use.

// HTTP Header Analyzer: Features

What it checks

The analyser recognises around sixty headers across security, CORS, caching, cookies, content, connection, authentication, rate limiting, tracing and server identification, explaining what each one does. On top of that it runs specific checks: whether HSTS has a sufficient max-age, whether X-Content-Type-Options is nosniff, whether cookies carry Secure, HttpOnly and SameSite, whether Content-Type declares a charset, and whether the CORS configuration contains the wildcard-with-credentials combination browsers reject.

The security headers that matter most

Six are worth having on essentially any site. Strict-Transport-Security forces HTTPS. Content-Security-Policy is the most effective mitigation for cross-site scripting. X-Content-Type-Options stops MIME sniffing. X-Frame-Options, or the CSP frame-ancestors directive, prevents clickjacking. Referrer-Policy limits what leaks to other sites. Permissions-Policy turns off browser features the page does not need. The analyser lists whichever of these are missing. To write a Content-Security-Policy rather than diagnose one, the CSP Generator builds it from a form.

Cookie flags are where real problems hide

A session cookie without HttpOnly can be read by any injected script, which turns an XSS bug into a full account takeover. Without Secure it can travel over plain HTTP. Without SameSite it participates in cross-site requests, which is the basis of CSRF. These three attributes are trivial to set and their absence is common, so each one is checked and reported individually with the cookie name.

What the headers tell you about caching

Cache-Control, ETag, Last-Modified, Expires, Age and Vary together determine whether a response is reused and for how long. Reading them in one place explains a great many puzzling behaviours: why a deploy did not appear for users, why a personalised page was served to the wrong person, why a CDN is not caching something you expected it to. A missing Vary on a response that differs by Accept-Encoding is a classic cause of corrupted content.

Headers carrying a session cookie stay local

The analysis runs entirely in your browser, so headers from a staging environment, an internal API or a production response containing a session cookie can all be pasted without leaving your machine. To build a CORS configuration rather than diagnose one, the CORS Header Generator produces the headers from a form.

// HTTP Header Analyzer: FAQ

How do I get the response headers to paste in?: Open your browser developer tools, go to the network tab, select the request and copy the response headers. Alternatively run curl with the -I flag for a HEAD request, or -i to include headers with the body. Either output pastes in directly.
Which security headers should every site have?: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options or CSP frame-ancestors, Referrer-Policy and Permissions-Policy. The analyser lists whichever of these your response is missing, which is usually a short and actionable list.
What max-age should HSTS use?: At least one year, 31536000 seconds, which is what preload lists require. A short max-age leaves a window in which a first visit over plain HTTP can be intercepted. Start shorter while testing if you are cautious, then raise it once you are confident every subdomain serves HTTPS correctly.
Why does it warn about my Set-Cookie header?: Because one of the three protective attributes is missing. HttpOnly keeps the cookie away from JavaScript, so an XSS bug cannot steal a session. Secure prevents it being sent over plain HTTP. SameSite limits its use in cross-site requests, which mitigates CSRF. For a session cookie all three should be present.
What is the wildcard and credentials problem in CORS?: Access-Control-Allow-Origin set to an asterisk cannot be combined with Access-Control-Allow-Credentials set to true. Browsers reject the response outright, because the combination would let any site on the internet make authenticated requests as the logged-in user. Name the specific origin instead.
Should I remove the Server and X-Powered-By headers?: Reducing them is worthwhile. They are not a vulnerability by themselves, but publishing your exact framework and version tells an attacker which known issues to try first. Removing X-Powered-By entirely and making Server generic costs nothing and removes free reconnaissance.
What does Vary actually do?: It tells caches which request headers change the response, so they can key their cache correctly. A response that differs by Accept-Encoding without a corresponding Vary can result in a compressed body being served to a client that did not ask for one. Vary on Accept-Encoding is almost always correct; Vary on Cookie effectively disables shared caching.
Is X-XSS-Protection still useful?: No. The browser filters it controlled have been removed, and in some cases they introduced vulnerabilities of their own. Current guidance is to omit it and rely on Content-Security-Policy, which addresses the same class of attack properly.
Does it check request headers too?: It recognises some request headers such as Authorization and Cookie when they appear, but the analysis is oriented towards response headers, which is where the security and caching decisions live. Paste a response for the most useful output.
Are the headers I paste sent to a server?: No. The analysis runs entirely in your browser, so headers containing session cookies, tokens and internal hostnames stay on your machine.

// How to Use HTTP Header Analyzer

Copy the response headers

Take them from the network tab of your browser developer tools, or from curl with the -I flag. One header per line in Name: Value form is what the parser expects, and a status line at the top is fine.
Read the warnings first

The recommendations panel lists specific problems with values you have set, such as a short HSTS max-age or a cookie missing HttpOnly. These are concrete and usually quick to fix.
Check what is missing

The missing security headers panel lists the important ones that are absent, with a short reason for each. Work through it alongside the per-header explanations below.

Category Network