The home page sends fewer than four of the six common security headers that help protect visitors from intercepted connections, clickjacking and injected scripts. Most take a single line of configuration.
What it means
Security headers are instructions the server sends with each page, telling the browser what to allow. They don’t fix weaknesses in the website itself, but they make many common attacks much harder.
The six graded are Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors), Referrer-Policy and Permissions-Policy.
What triggers it
Once a week the Security headers check loads the home page over HTTPS and counts how many of the six it sends: all six is an A, five a B, four a C, three a D, two an E and fewer an F. At D or below this Medium issue is raised, titled with the grade and listing the missing headers. It shows in the app and isn’t emailed.
A missing HSTS header is also reported on its own. See No HSTS header.
Common causes
- Most web servers and hosting plans send none of these headers by default.
- The headers are set for some folders or servers but not for the home page.
How to fix it
- Add the simple ones first, which rarely break anything: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin and a Permissions-Policy such as camera=(), microphone=(), geolocation=().
- Set them in your web server, CDN, hosting control panel or a security plugin for your CMS.
- Add Content-Security-Policy last, after testing it with Content-Security-Policy-Report-Only, because a strict policy can block your own scripts, fonts or tracking.
When it clears
The issue disappears at the next weekly check that finds at least four of the six headers (grade C or better), and its action drops off the action plan 7 days later.
If you mark the action done and the problem is still found 14 days later, it comes back as “Fix didn’t work”. See Using the action plan.