Free tool
What your response headers ask browsers to do
Seven headers that let a website constrain how browsers treat its pages. This reads what a page returns and explains each one, without dressing an absence up as a breach.
Security Exposure findings identify publicly observable indicators and do not replace an authorised penetration test.
Framing
Hardening, not vulnerability
Response headers are instructions to a browser. They say which scripts may run, whether the page may be framed by another site, how much information to send when a visitor follows a link away, and which device capabilities the page may request. None of them fixes a flaw in an application. What they do is limit what a flaw can be used for.
This distinction gets lost constantly, and it does real damage. Tools that grade a site an F for missing headers produce alarm out of proportion to the situation, which tends to result either in panic or — more often — in the whole category being dismissed as noise. Neither response leads to the headers being configured thoughtfully.
The proportionate view: these are cheap, they are defensive, and they are worth adding deliberately rather than urgently. A Content-Security-Policy in particular repays being written properly against what the site actually loads, and is close to worthless when copied from an example.
Reference
What each header constrains
Presence is what this check establishes. Whether the value is any good is a separate reading.
| What it constrains | What it will not do | |
|---|---|---|
| Content-Security-Policy | Which scripts, styles, frames and other resources a browser will load, and from where. | Prevent injection. It limits what injected content can then do, which is only valuable if the policy is restrictive enough to matter. |
| Strict-Transport-Security | Forces browsers to use HTTPS for the domain for a stated period, removing the initial insecure request. | Help a first-time visitor before the header has been received, unless the domain is on the preload list. |
| X-Content-Type-Options | Stops browsers guessing a file's type from its contents rather than trusting the declared type. | Do anything at all if content types are declared correctly. It costs one line and covers the case where they are not. |
| Referrer-Policy | How much of the current address is disclosed when a visitor follows a link to another site. | Protect anything if sensitive information is placed in query strings, which is the underlying problem it mitigates. |
| Permissions-Policy | Which device capabilities — camera, microphone, geolocation — the page and its embedded frames may request. | Matter much on a site that embeds nothing and requests nothing. It matters considerably on one that embeds third-party frames. |
| X-Frame-Options / frame-ancestors | Whether other sites may embed your pages in a frame, which is what clickjacking depends on. | Apply where a site legitimately needs to be embedded. The modern form is a frame-ancestors directive within the policy. |
| Cross-Origin-Opener-Policy | Isolates the page's browsing context from windows it opens or that opened it. | Be appropriate everywhere. It can break integrations that rely on cross-window communication, so it needs testing. |
Sequence
A sensible order to approach this in
Start with the ones that cannot break anything. X-Content-Type-Options and a sensible Referrer-Policy are single lines with no realistic side effects, and they can be added the same day they are discussed.
Strict-Transport-Security comes next, but with attention to the duration. A long max-age on a domain not yet fully ready for HTTPS everywhere is difficult to reverse, because browsers have already been told to remember it. Start short, confirm, then extend.
Content-Security-Policy is last and is a project rather than a line. The workable approach is to deploy it in report-only mode, collect what it would have blocked over a period covering normal site activity, resolve each case, and only then enforce. Attempting to write a restrictive policy from scratch on an established site generally ends with unsafe-inline being added to make things work again, which forfeits most of the benefit.
Same-day, no risk
- X-Content-Type-Options
- Referrer-Policy
- Removing X-Powered-By
- Suppressing the Server version
Needs testing first
- Strict-Transport-Security duration
- Frame restrictions where anything embeds you
- Permissions-Policy on sites using third-party frames
- Cross-Origin-Opener-Policy
- Content-Security-Policy, in report-only first
Where this check stops
One page is requested, exactly as any visitor’s browser would request it, and the headers that come back are read. Nothing is probed, no input is submitted, no authentication is attempted and no weakness is tested for. The request is indistinguishable from an ordinary page view except that the user agent identifies itself honestly.
That boundary is the reason this can be offered publicly. Anything beyond it — enumerating services, testing inputs, examining anything behind authentication — requires a separate signed authorisation with a defined scope, an agreed window, named contacts and stop conditions. It is never triggered from a form on a public website, by anyone, for any domain.
Infrastructure expertise from Elite Security Europe
Elite Security Europe contributes specialist review of email authentication, DNS configuration, infrastructure posture and passive security exposure.
Common questions
Is a missing header a vulnerability?
We have a Content-Security-Policy. Does that mean we are covered?
Why do you flag the Server header?
Can you scan our whole site?
The result differs from another header checker.
Related
Headers are one signal among several
Transport configuration, DNS governance and email authentication are usually assessed together, because they are usually managed by the same people and fail in related ways.
Domain verification confirms control of an approved domain resource. It does not automatically authorise active testing of company infrastructure.