Security headers
The HTTP response headers a browser uses to decide what your pages are allowed to do.
20 checks in this group, 4 with a full write-up.
What the browser will do unless you say otherwise
A browser’s default behaviour is permissive. It will let your pages be loaded inside someone else’s frame, let a script pulled from a compromised ad network run with the same trust as your own code (unless a Content-Security-Policy says otherwise), let a click on an outbound link hand the destination site your full referring URL, and guess at a file’s content type from its bytes rather than trust what the server actually said it was. None of that is a bug in the browser. It is the default, and it stays the default until the server sends a header that switches it off. Security headers are not a defence against one specific exploit; they are a blanket instruction to the browser about what your pages are and are not allowed to do, sent on every response whether or not anything is currently attacking the site.
That makes this group unusual among the checks here: it is one of the few places where “fixed” does not mean “found and cleaned up”, it means a handful of lines added once, at the server or in the CMS, that then apply to every visitor on every page for as long as they stay in place. There is no ongoing maintenance burden the way there is with, say, keeping a plugin roster patched. Get the headers right once and they stay right until someone changes the server configuration for an unrelated reason and overwrites them without noticing.
That last part is the actual failure mode worth watching for across a portfolio: headers that were correct at launch and silently stopped being sent after a server migration, a CDN change, or a template update that touched the wrong config file. A header nobody remembered configuring is a header nobody notices going missing, which is exactly why every check in this group runs on the twice-daily snapshot rather than a one-off audit at the start of the relationship. Checking your website’s security headers with mySites.guru shows what that looks like in practice.
Two headers in this group are worth flagging as legacy rather than optional: Feature-Policy and Expect-CT are both deprecated and superseded, and a site still sending either is not extra safe for it, just carrying dead weight.
Generic
Content-Security-Policy Header Blocks Attacks
Sets which scripts and resources your pages are allowed to load, so injected code from an XSS attack has nowhere left to execute from.
94.9% of the Generic sites we have this data for fail it
Expect-CT Tells Browsers To Expect Certificate Transparency
Expect-CT asked browsers to verify a certificate was publicly logged, but the header is obsolete now that every trusted certificate must be logged anyway.
Permissions-Policy Controls Which Features Can Be Used In The Browser
Controls which browser features, such as camera, microphone and geolocation, your pages and any embedded content are allowed to request.
Remove Deprecated Feature-Policy Header
Feature-Policy used to restrict access to browser features like the camera and microphone, but it is deprecated in favour of Permissions-Policy, so remove it.
Referrer-Policy Sets How Much Info Is Leaked When Linking Off Site
Controls how much of your page's URL gets sent to the destination site when a visitor clicks an outbound link, which can otherwise leak private paths.
Strict-Transport-Security (HSTS) Enforces The Use Of HTTPS
Tells the browser to only ever connect over HTTPS for a set period, an instruction that is hard to undo once a visitor's browser has cached it.
X-Content-Type-Options Stops Browsers MIME Sniffing The Content Type
Stops the browser guessing a file's type from its content instead of trusting the declared type, which is how a disguised file can end up executed as a script.
X-Frame-Options Controls Whether Your Site Can Be Framed
Controls whether another site can load your pages inside a frame, which stops clickjacking attacks that trick visitors into clicking something invisible.
Joomla
Permissions-Policy Controls Which Features Can Be Used In The Browser
Permissions-Policy lets a site switch off browser features such as camera, microphone and geolocation, so a compromised script cannot invoke them.
Remove Deprecated Feature-Policy Header
Feature-Policy was the browser header gating camera, microphone and similar APIs before Permissions-Policy replaced it, so serving it now is dead weight.
Referrer-Policy Sets How Much Info Is Leaked When Linking Off Site
Without a Referrer-Policy header, a visitor clicking an outbound link can leak the full page URL, tokens and IDs included, to the destination site's logs.
Strict-Transport-Security (HSTS) Enforces The Use Of HTTPS
HSTS tells the browser to always use HTTPS for future visits, but the setting is cached for the duration you set, so a bad header is hard to undo quickly.
72% of the Joomla sites we have this data for fail it
X-Content-Type-Options Stops Browsers MIME Sniffing The Content Type
Without this header, a browser may guess a file's type from its content, letting an uploaded file dressed as an image execute as a script instead.
32.4% of the Joomla sites we have this data for fail it
X-Frame-Options Controls Whether Your Site Can Be Framed
Without X-Frame-Options, another site can load your pages inside an invisible frame and trick a visitor into clicking buttons they cannot see: clickjacking.
50.3% of the Joomla sites we have this data for fail it
WordPress
Permissions-Policy Controls Which Features Can Be Used In The Browser
Controls which browser features, such as camera, microphone and geolocation, your pages and any embedded content are allowed to request.
Remove Deprecated Feature-Policy Header
Feature-Policy used to restrict access to browser features like the camera and microphone, but it is deprecated in favour of Permissions-Policy, so remove it.
Referrer-Policy Sets How Much Info Is Leaked When Linking Off Site
Controls how much of your page's URL gets sent to the destination site when a visitor clicks an outbound link, which can otherwise leak private paths.
Strict-Transport-Security (HSTS) Enforces The Use Of HTTPS
Tells the browser to only ever connect over HTTPS for a set period, an instruction that is hard to undo once a visitor's browser has cached it.
X-Content-Type-Options Stops Browsers MIME Sniffing The Content Type
Stops the browser guessing a file's type from its content instead of trusting the declared type, which is how a disguised file can end up executed as a script.
X-Frame-Options Controls Whether Your Site Can Be Framed
Controls whether another site can load your pages inside a frame, which stops clickjacking attacks that trick visitors into clicking something invisible.
Find out which of these your sites fail
Connect a site and every check in this group runs against it automatically, with the result and the fix in one place. These run twice a day on every connected site.
Run a free audit