A security headers report looks intimidating the first time you see one. Rows of acronyms, a grade, and warnings about headers you have never set. Underneath the jargon, though, each line answers a simple question: when a browser visits this site, what protections does the site ask for? A header is not a feature of the page content. It is an instruction sent with the page, telling the browser how to behave. Learning to read those instructions turns a confusing report into a short, prioritised fix list. Security Header and DNS Checker checks a site's headers and TLS details and explains each result in plain language.
Start with the most important caveat, because it shapes everything else. A checker reports what a site sends at the moment of the check. It does not prove a site is secure, and it does not fix anything. A site can have every header in place and still have other problems the checker cannot see, such as weak passwords or outdated software. Conversely, a missing header is not proof of a breach; it is a missing layer of protection. Think of headers as locks on different doors. The report tells you which doors have locks, not whether anyone has tried them.
HSTS: forcing the secure connection
Strict-Transport-Security, usually called HSTS, tells the browser to use only the encrypted version of a site in future, even if a link or a typed address asks for the unencrypted version. Without it, a visitor who types a bare domain name may first connect over plain HTTP before being redirected, and that first connection can be intercepted. With HSTS, the browser skips the insecure step entirely and goes straight to HTTPS.
A report line for HSTS usually shows whether the header is present and how long it lasts, measured by the max-age value. A short max-age, such as a few minutes, is common during testing but offers little protection in practice, because the instruction expires quickly. A long max-age, such as a year, is the normal goal for a settled site. The fix for a missing HSTS header is a server configuration change, not a change to page content, which is why site owners sometimes need their host's help to add it. It is also worth checking that the site genuinely works over HTTPS first, since HSTS makes the browser refuse the insecure version outright.
CSP and framing headers: controlling what a page may do
Content-Security-Policy, or CSP, is the longest and most confusing header in most reports, but its idea is simple: it lists which sources a page is allowed to load content from — scripts, styles, images, and frames. If an attacker manages to inject a script from an unknown source into a page, a strict CSP tells the browser to refuse it. A report may show CSP as missing, which is common on small sites, or present but permissive, which means it allows so much that it blocks little.
Do not rush to add a strict CSP to a finished site without testing, because a policy that is too tight will break legitimate features: embedded videos, analytics scripts, or fonts from a third party can all stop loading. The sensible first step is a report-only version, which logs violations without blocking anything, letting you discover what the page actually loads before you enforce anything. The other framing header, X-Frame-Options, is simpler: it tells browsers whether other sites may embed this page in a frame. Setting it to deny framing prevents a technique called clickjacking, where an attacker frames a real page invisibly and tricks visitors into clicking something they cannot see.
The remaining headers, in plain language
X-Content-Type-Options, usually set to "nosniff", stops browsers from guessing a file's type when the server's declared type looks wrong. That guessing once allowed attackers to disguise a script as an image and have it run. Referrer-Policy controls how much of the page's address is sent to other sites when a visitor follows a link: a strict policy shares less, which is a privacy improvement rather than a security fix. Permissions-Policy, formerly Feature-Policy, lets a site switch off browser features it does not use, such as the camera or microphone, so a compromised script cannot silently reach them.
None of these headers is individually decisive. Their value is cumulative, and the report's grade reflects the combination. A small site that fixes HSTS and framing first, then adds the content-type and referrer policies, has covered the most important ground. CSP is the biggest job and the one most worth doing carefully rather than quickly. For a fuller guide to each header's purpose, see the HTTP security headers guide.
Worked example: reading a fictional small-site report
Imagine a fictional bakery site, listed for this example at example.com, run by an invented owner, Sara. Her report shows: HSTS missing, CSP missing, X-Frame-Options present, X-Content-Type-Options present, and a TLS certificate valid for another year. The certificate result is good news, but it answers a different question: it confirms the encrypted connection itself, not the headers around it.
Sara's priority order is clear. First, add HSTS, because it protects every future visit and costs nothing once HTTPS works. Second, set the framing header — already present here, so nothing to do. Third, add the content-type and referrer policies, which are one-line server settings. CSP comes last, starting in report-only mode while she lists the third-party scripts her booking widget loads. She should not expect the report grade to jump to perfect after one change; it improves as each layer is added, and a report run after each change confirms the new header is actually being sent.
Honest limitations
A header check inspects the response for one URL at one moment. It cannot see the rest of the site, the server's software versions, or the application's own flaws, and headers set on the homepage may differ from those on other pages. Results can also change: a host may alter server settings, or a page may move behind a service that strips headers. Re-check after changes, and re-check occasionally even when nothing seems to have changed. A good report is a snapshot, not a certificate of safety, and it never replaces keeping software updated and using strong, unique passwords.
FAQs
What do HSTS, CSP, and X-Frame-Options actually protect against?
HSTS forces future visits over encrypted HTTPS, preventing downgrade interception. CSP restricts which sources a page may load content from, blocking injected scripts from unknown sources. X-Frame-Options stops other sites embedding the page in a frame, preventing clickjacking.
Does a good headers grade mean my site is secure?
No. A checker reports the headers a site sends; it does not audit the site's software, passwords, or application logic. Treat a good grade as evidence that one layer of protection is in place, not as proof of overall security.
Why is my CSP report so complicated?
Because CSP lists allowed sources for many content types, and real pages load scripts, styles, images, and fonts from several places. Start with a report-only policy to learn what your page loads, then tighten it gradually.
Can I add security headers from my page content?
No. Headers are sent by the server with the page, not written in the page itself. Adding them usually means a server or hosting setting, sometimes with your host's help.
The same checker also looks up DNS and email records for a domain, and the On-Page SEO and Redirect Checker covers the page-level audit — titles, headings, and redirect chains — that pairs naturally with a headers review. If the site also publishes structured data, the Structured Data Generator can validate that markup alongside the header check.
human review pending client designation