HTTP Headers Analyzer
Fetch a URL or paste response headers and see which security headers are missing, which are weakened, and why each one matters.
Check a live URL or paste response headers, and see which security and caching headers are missing or weakened.
The request is made by this site's server, because a browser cannot read another origin's response headers. Private and internal addresses are refused.
Header review
1 good, 5 to improve, 2 missing
Content-Security-Policy
Set, but weakened
default-src 'self'; script-src 'self' 'unsafe-inline'
Contains unsafe-inline or unsafe-eval, which allows exactly the injected inline script the policy exists to stop. Use a nonce or a hash.
Strict-Transport-Security
max-age is only 86400
max-age=86400
Six months (15768000) is the usual minimum, and preload lists require a year.
X-Content-Type-Options
nosniff
nosniff
Stops the browser guessing a file's type. Without it an uploaded text file can be sniffed as script and executed.
X-Frame-Options
Not set
Controls who may put your page in an iframe. Without it, your page can be layered under an invisible overlay and clicks stolen.
Referrer-Policy
Not set
Decides how much of the current URL is sent when a visitor follows a link away. strict-origin-when-cross-origin is a sensible default.
Permissions-Policy
Not set
Switches off features the page never uses, such as camera, microphone and geolocation, so injected code cannot reach for them either.
Cache-Control
public, max-age=0
public, max-age=0
Controls how long this response may be reused.
Server
nginx/1.18.0
nginx/1.18.0
Announces the exact software version, which hands an attacker the list of known vulnerabilities to try first. Remove it.
About the http headers analyzer
Security headers are close to free and easy to forget. Each one closes a specific attack, and the tools that report on them usually give you a grade without saying what the grade is for.
This explains each header in terms of what it prevents, and it flags the case that catches people out: a Content-Security-Policy that exists but allows unsafe-inline, which removes most of the protection while still looking configured.
How to use it
- 1Enter a URL and fetch, or paste headers you already have.
- 2Read the review, starting with anything marked missing.
- 3Note which existing headers are weakened rather than absent.
- 4Add the missing headers at your server or CDN.
Questions
Why does the request go through your server?
A browser cannot read another origin's response headers, so a direct fetch would be blocked by CORS on almost every site. The request is proxied through the same guarded endpoint the API client uses, and private or internal addresses are refused.
Which header should I add first?
X-Content-Type-Options: nosniff and a Referrer-Policy take a minute each. Strict-Transport-Security is next. A Content-Security-Policy is the most valuable and the most work, so start it in report only mode.
Why is my CSP flagged when it is set?
Because it allows unsafe-inline or unsafe-eval. Injected inline script is exactly what a CSP is meant to stop, so allowing it removes most of the benefit. Use a nonce or a hash instead.
Does a Server header really matter?
On its own, no. Announcing an exact version number hands an attacker the list of known vulnerabilities for that build, so it is worth removing even though nothing breaks if you leave it.