Enter a URL and IOn Probe reads the response headers your site actually sends: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, plus whether HTTP redirects to HTTPS. No signup, no email wall.
Header results are in the Security tab of the report.
The checker fetches the page the way a browser would and reports which of these headers came back.
HSTS tells browsers to reach your domain over HTTPS only, which blocks protocol downgrade on later visits.
CSP limits where scripts, styles and other resources may load from, which reduces the damage a cross-site scripting bug can do.
Stops other sites from embedding your pages in a frame, the basis of clickjacking.
With the value nosniff, browsers stop guessing a file's type and trust the Content-Type you declared.
Controls how much of the current URL is sent along when a visitor follows a link to another site.
Switches off browser features your site does not use, such as camera, microphone and geolocation.
HTTP security headers are instructions a web server sends with every response that tell the browser how to behave: load the site over HTTPS only, which scripts may run, whether the page may be framed, and how much referrer data to share. They cost nothing to add and close off whole classes of attack, such as clickjacking and protocol downgrade.
They are also easy to lose without noticing. A header set in your application can be dropped by a CDN, applied to HTML but not to redirects, or missing on one path. That is why it is worth checking the live response and not the config file.
Every site should send these six security headers. The values below are sensible starting points, and Content-Security-Policy is the one that needs tailoring to your own scripts and styles.
| Header | What it does | Starting value |
|---|---|---|
| Strict-Transport-Security | Forces HTTPS for your domain on later visits | max-age=31536000; includeSubDomains |
| Content-Security-Policy | Restricts where scripts, styles and other resources load from | default-src 'self', then widen per resource type |
| X-Frame-Options | Blocks framing by other sites. The CSP frame-ancestors directive is the modern equivalent | DENY or SAMEORIGIN |
| X-Content-Type-Options | Stops MIME type sniffing | nosniff |
| Referrer-Policy | Limits the URL detail sent to other sites | strict-origin-when-cross-origin |
| Permissions-Policy | Disables browser features you do not use | camera=(), microphone=(), geolocation=() |
You add security headers wherever responses are produced: a headers file on a static host, the server config on Nginx or Apache, or middleware in an application framework. The header names and values are the same everywhere. Only the syntax changes.
On a static host that reads a _headers file, such as Cloudflare Pages or Netlify:
/*
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()On Nginx, inside the server block:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;In an Express app, the helmet middleware sets most of them with one line:
const helmet = require("helmet");
app.use(helmet());Content-Security-Policy is the one to roll out carefully. Send it first as Content-Security-Policy-Report-Only, which reports violations without blocking anything, fix what it flags, and then switch to the enforcing header. After any change, run the check again against the live URL.
No. Security headers are one layer of defence in the browser. They do not fix an exposed API key, a database with no access rules, or an auth check that trusts an unverified token. A site can send every header on this list and still leak data, so treat a clean result as one item ticked on a longer list.
The rest of that list is covered in our app security guides, starting with the pre-launch security checklist.
Yes. IOn Probe is free with no signup and no email wall. Enter a URL and the report opens straight away.
Yes. Response headers are public: the checker reads only what any browser receives when it loads the page.
The usual causes are a CDN or proxy that drops or overrides the header, a rule that applies to some paths but not the one you checked, or a header set on HTML responses but not on redirects. Check the live response for the exact URL, not the config.
Security headers are not a direct ranking factor. Serving the site over HTTPS is a minor Google ranking signal, and headers protect the visitors you already have.
Free. No signup. The full report covers six pillars, not just this one.
Part of IOn Probe, the free website auditor from The IOn Project.