security headers checker

A browser reads these
before your page.

Seven response headers decide what a browser will let your page do — where scripts may come from, whether it can be framed, whether http is upgraded on the way back. This reads them and says which are set, which are missing, and which are present when they should not be.

This tool works differently from the generator. The generator never uploads your image — it runs in your browser. The checker cannot: it fetches the public address you type, from our server, and reads no page body at all — only the status and response headers the site answers with, after following any redirect to the response that answers. The body is cancelled unread rather than fetched and thrown away. Only the address you enter is sent. The addresses you check are then kept in this browser, so it can tell you what changed since last time; they go nowhere, and you can clear them.

Questions

Does this read my page content?

No. Only the status and the response headers the site answers with; the body is cancelled rather than read. What is graded is what your server says about the page, not what the page says.

A header is set on my site but the report does not show it. Why?

The headers reported are the ones on the response that finally answered, not on a redirect along the way. If your header is set on the address you typed but that address redirects, the grade describes where the chain ended. Follow the chain first and then check the address that answered.

The seven headers, and what each one is for

These are the headers the check above grades, described on their own rather than against any site. Six of them are things to send. The seventh is a thing to remove, and it is the one most often reported the wrong way round.

HTTPS is enforced for return visitsstrict-transport-security
Tells a browser to reach this site over https only, and to remember that for a stated length of time. Without it the first request of a session can still go out over http — which is the one request anything sitting between the reader and your server gets to answer.
What to sendSend "Strict-Transport-Security: max-age=31536000; includeSubDomains" on every https response. That max-age is a year. Leave includeSubDomains off if any subdomain of yours is still served over http, because it will stop being reachable.
A content security policy is in forcecontent-security-policy
Lists where scripts, styles, images and frames are allowed to come from. The browser refuses anything the list does not cover. It is what turns an injected script tag into a blocked request rather than into code running as your own site, with everything that carries.
What to sendThere is no header line to give here, and that is the answer rather than a gap in it: a policy written by something that has never loaded your pages will block your own scripts, and a broken site is worse than an unprotected one. Start with the policy you have in mind on Content-Security-Policy-Report-Only, which blocks nothing and reports what it would have blocked. When the reports stop naming things you meant to allow, send that same value as Content-Security-Policy.
The page cannot be framed by another sitex-frame-options
Says whether another site may put your pages inside an iframe. Without it a page can be framed invisibly over something else, so a click aimed at that site lands on yours instead — and nothing about the page tells the reader.
What to sendSend "X-Frame-Options: DENY", or "X-Frame-Options: SAMEORIGIN" if your own pages frame each other. A CSP frame-ancestors directive covers the same ground and supersedes it, so either one closes this.
Declared content types are trustedx-content-type-options
Holds the browser to the Content-Type your server declared, instead of guessing one from the first bytes of the file. Guessing is the step that lets a file uploaded as an image be run as a script. It is also the step that rescues anything you currently serve with the wrong type, which is why this one is worth testing before it goes live.
What to sendSend "X-Content-Type-Options: nosniff" — the one value the header has. It holds your server to the types it declares, so anything you currently serve with the wrong Content-Type will stop working rather than be guessed at.
Addresses are not leaked to other sitesreferrer-policy
Decides how much of the current address travels to whatever the reader clicks through to. Left alone, the whole address goes — path and query included, which is where search terms, internal identifiers and the occasional token live.
What to sendSend "Referrer-Policy: strict-origin-when-cross-origin". Your own pages still receive the whole address; anywhere else gets the origin on its own, and an https page linking to an http one sends nothing at all.
Powerful features are switched off by defaultpermissions-policy
Switches browser features — camera, microphone, geolocation and the rest — off for the page and for anything embedded in it. It bounds what a third-party embed is able to ask your readers for, whether or not you knew it could ask.
What to sendSend "Permissions-Policy: camera=(), microphone=(), geolocation=()". The empty brackets deny each feature to your own page as well as to anything embedded in it, so name only the features you are sure nothing on the page asks for.
The retired XSS filter is not switched onx-xss-protection
A retired filter from an older generation of browsers. This is the one row where having the header is the finding rather than missing it. No current browser implements the filter, and the version that shipped had vulnerabilities of its own — it could be used to switch scripts off on a page selectively. A checker that gives you a tick for sending it is grading backwards.
What to sendThe fix here is a deletion rather than an addition: take X-XSS-Protection out of your server configuration. If something upstream sets it without asking, send "X-XSS-Protection: 0", which is the documented way to switch it off.