Security Header Findings: HSTS, CSP, Frame and Referrer

Short answer: A Site AI Audit report can contain up to five findings about security headers: HSTS is not enabled, X-Content-Type-Options is missing, the site can be embedded in other websites, Content-Security-Policy is missing and Referrer-Policy is missing. All five are notices, the lowest severity, because nothing is visibly broken. They are still worth fixing: each header is one line of server configuration, and together they limit the damage when something else goes wrong.

What security headers are

When a browser asks your server for a page, the server answers with the page and a set of headers, small pieces of information that travel with it. Some headers describe the content, such as its type and size. Others give the browser instructions about how to behave while showing the page: always use a secure connection, do not guess file types, do not let other sites put this page in a frame. These are security headers.

They matter because they are enforced by the visitor’s browser, not by your server. If an attacker finds a way to inject something harmful into a page, a well-chosen header can stop the browser from acting on it. Think of them as seat belts: they do nothing on a normal journey and a great deal in an accident. The audit checks the headers during the first step of the check, together with the certificate and the redirect, and reports what is missing.

The five findings one by one

HSTS is not enabled

HSTS tells the browser to always open your site over a secure connection. Without it, a visitor on public Wi-Fi who types your address without https:// can be quietly switched to an unencrypted version. The audit reports this only for sites that already work over HTTPS. The fix is to add the Strict-Transport-Security header, for example with max-age=31536000, which is one year. Introduce it carefully, because once a browser has seen the header, it will refuse to use plain HTTP for your domain until the time runs out. The article on enabling HSTS safely explains the steps.

X-Content-Type-Options header is missing

Without this header, a browser may try to guess what a file is, and may run something harmful as a script even though the server labelled it as an image or text. The fix is the header “X-Content-Type-Options: nosniff”, which tells the browser to trust the label. It has almost no side effects, which makes it the easiest of the five.

The site can be embedded in other websites

A scammer can show your real page inside their own site and place an invisible button over it, so that visitors click something they never meant to. This is called clickjacking. The fix is “X-Frame-Options: SAMEORIGIN” or a frame-ancestors rule in a Content-Security-Policy. Note that if your site is meant to be embedded elsewhere, for example a booking widget, you should allow only the partners that need it.

Content-Security-Policy is missing

CSP tells the browser where your site may load scripts from. If someone injects malicious code, for example through a comment form or a hacked plugin, CSP stops it from running. This is the strongest and the most complex of the five. The audit’s advice is to add a policy with default-src or script-src limited to your domain and trusted services, and to test it in report-only mode first. The guide to rolling out a CSP in report-only mode shows how to do this without breaking your site.

Referrer-Policy header is missing

Referrer-Policy controls what other sites learn about the page your visitor came from. Without it, full page addresses, sometimes with parameters, can leak when visitors click links. The advice is “Referrer-Policy: strict-origin-when-cross-origin”, a balanced setting that is also the default in modern browsers but is worth stating explicitly. See the article on the Referrer-Policy header for the other values.

Why these are notices and not warnings

The audit marks all five as notices because a missing header does not break anything for visitors today. This matters for your priorities. If the same report contains an expiring certificate or a broken page, deal with those first. But do not ignore the notices for long. Every serious attack on a website is a chain of small weaknesses, and these headers are among the cheapest links to remove. Each one takes minutes and, once added, keeps working.

How to add the headers

Where you add them depends on your setup:

Apache. In the site configuration or .htaccess, using the Header directive.
Nginx. In the server block, using add_header.
WordPress. With a security plugin that has a headers section, or in the server configuration when you have access to it.
A CDN or proxy. Many have a setting or a rule that adds response headers to every page.
Managed hosting. Ask support; many hosts will add standard headers for you if you list them.

The guide to adding security headers on Apache, Nginx, WordPress and CDNs has working examples for each. A good approach is to add the three simple headers, HSTS, nosniff and Referrer-Policy, plus frame protection, in one session, and handle CSP separately because it needs testing.

Common mistakes

Setting a very long HSTS before you are sure. If any subdomain still depends on plain HTTP, a long HSTS setting can lock visitors out. Start with a short value and raise it.
Adding a strict CSP on day one. A policy that blocks your own analytics, fonts or checkout will break the page. Use report-only mode first.
Blocking all framing when you need it. A site that legitimately embeds its own pages should use SAMEORIGIN, not DENY.
Adding headers in one place but serving the page from another. A cache, CDN or second server can remove or override them. The audit sees the result, so check from the outside.
Copying outdated headers. Old guides recommend headers such as X-XSS-Protection that are no longer useful; the article on deprecated security headers lists them.

How to test that a header is really sent

You do not need special tools to confirm a header. Open your site in a browser, open the developer tools, choose the network panel, reload the page and click the first request, which is the page itself. The response headers are listed there, and you can look for Strict-Transport-Security, X-Content-Type-Options and the others by name. If a header you added is not in the list, something between the server and the visitor is removing it, or the change was made on a different server than the one that answers. The audit’s next check is the second opinion: it reads the same headers from the outside and reports whether the notice has cleared.

Which pages need headers

Headers should apply to every response, not just the home page. A common slip is to add them for one location only, for example the main site, while a subdomain or the blog is served by another configuration without them. If the audit reports a missing header after you have added it, check which part of the site the audit actually fetched and whether other parts use a different server block, plugin or CDN rule.

How the headers relate to the rest of the report

The five header findings sit in the same security area as the certificate and redirect findings, and the report ranks the area by the most severe finding. That is why a site with only notices in this group can still have a good security score: the score drops by a small amount for each notice, far less than for a critical finding. If you want a high score, closing all five is worth the effort, but if you must choose, spend your first hour on certificates, redirects and mixed content, and your second on the headers.

A worked example

A small law firm has a WordPress site and a security area score of 75, caused by five notices: no HSTS, no nosniff, no frame protection, no CSP and no Referrer-Policy. The firm’s IT contractor adds four of the headers in the server configuration in about ten minutes: HSTS with a one-month value, nosniff, SAMEORIGIN and strict-origin-when-cross-origin. For CSP, he adds a report-only policy and collects reports for two weeks. He finds that the contact form loads a script from a map service that his policy did not allow, adds it, and then switches the policy from report-only to enforced. The next check shows that all five notices are gone and the security score has risen. None of the visitors noticed any change, which is exactly how headers should work.

To find out which headers your site is missing, check your website with Site AI Audit. The check needs a free account; the plans unlock the full report with the exact findings and fixes.

The bottom line

Five small headers close five easy gaps: HSTS, nosniff, frame protection, Content-Security-Policy and Referrer-Policy. Add the simple ones in one sitting, roll out the CSP in report-only mode and run the audit again to confirm that the browser now receives them.

KKK

Are missing security headers dangerous?

They do not break the site, which is why they are notices. They do reduce your protection when another weakness appears.

Which header should I add first?

Start with X-Content-Type-Options and Referrer-Policy, which are the safest. Add HSTS once you are sure the whole site works over HTTPS.

Can a header break my website?

A strict Content-Security-Policy and a long HSTS setting can. Test CSP in report-only mode and start HSTS with a short time.

Does the audit check for the Permissions-Policy header?

The audit’s security findings list five headers: HSTS, nosniff, frame protection, CSP and Referrer-Policy.

Why does the finding remain after I added the header?

A cache, CDN or second server may be answering instead of the one you configured. Clear caches and check what the outside world receives.

Security Header Findings: HSTS, CSP, Frame and Referrer Policy