Security Headers Checker

A security headers checker shows which protective HTTP response headers your website sends to browsers and which are missing. Ours requests your homepage over HTTPS, follows any redirects and reads the headers on the page visitors actually land on. Every missing header is flagged with a suggested value and a ready-made Apache and Nginx line, so a developer, hosting provider or agency can close the gap quickly instead of working from a vague recommendation to improve security.

How to use the Headers checker

1. 1 Enter your domainType example.co.uk or paste any URL from the site. We test the homepage of that host.
2. 2 Run the scanSign in to your free account and start the check. We request https:// first, follow up to five redirects and fall back to plain http:// only if HTTPS cannot connect at all.
3. 3 Work through the warningsEach missing header appears as a warning with the value we suggest and the matching Apache and Nginx configuration line to copy.
4. 4 Deploy, then re-testAdd the headers on your server, CDN or CMS, clear any cache, and run the check again after ten minutes, which is how long results are cached per domain.

What a security headers check looks at

HTTP response headers are short instructions your server sends before the page itself. Most are about caching or content type, but a handful tell the browser to apply extra protection for your visitors. They cost nothing to send, work in every modern browser and close off whole categories of attack, from protocol downgrades to clickjacking. Our security headers checker tests the following on the final response:

• Strict-Transport-Security (HSTS): makes the browser use HTTPS for your domain for a set period, plus a separate check that its max-age is long enough.
• Content-Security-Policy: lists where scripts, styles, images and frames may load from, limiting the damage of injected code.
• X-Content-Type-Options: the value nosniff stops browsers treating a file as a different type from the one declared.
• X-Frame-Options: controls whether other sites may load your pages inside a frame.
• Referrer-Policy: limits how much of the current URL is passed to other sites when visitors click away.
• Permissions-Policy: switches off browser features such as camera, microphone and geolocation that the site does not use.
• Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy: isolate your pages and files from other origins.

How the HTTP security header scan works

The tool makes a normal GET request to the root of the domain and follows up to five redirects, so if example.co.uk redirects to https://www.example.co.uk/ the headers are read from the www page. It records the first value of each header on that final response. Only the homepage is tested, which matters if your server sets different headers for different paths or for static files.

Most results are presence checks. A Content-Security-Policy is marked present whatever it contains, so a policy that allows unsafe-inline scripts passes here even though it offers limited protection. Treat a pass as confirmation the header is being sent, then review its value yourself or rebuild it with our CSP generator.

Strict-Transport-Security is examined more closely. We read the max-age value in seconds and compare it with 15552000, which is roughly six months. We also note whether the preload directive is present. Framing protection passes if either an X-Frame-Options header is sent or your Content-Security-Policy includes a frame-ancestors directive, since both stop other sites loading your pages in a frame.

Reading your security header results

Each row is either a pass or a warning, and the overall score weights them by importance. HSTS and Content-Security-Policy carry the most weight, followed by X-Content-Type-Options and X-Frame-Options, then Referrer-Policy and Permissions-Policy, with the cross-origin headers weighted least. Because a missing header counts as a warning rather than a fail, a site sending none of these headers scores 50, and each header you add lifts the score by its weight, so 100 means every header is present and HSTS max-age is strong.

• Present (pass): the header was found on the final response.
• Missing (warning): the header was not sent. The row includes a suggested value and copy-ready configuration.
• HSTS max-age is strong (pass): max-age is at least six months, shown in days, with preload noted if it is included.
• HSTS max-age is short (warning): HSTS is present but expires in under six months. Raise it once you are confident every page works over HTTPS.
• COOP or CORP present (pass): the row shows the value found, such as same-origin or same-site.

How to add security headers on Apache, Nginx, cPanel and Cloudflare

Apache and most cPanel shared hosting: open the .htaccess file in your site root through cPanel File Manager or SFTP, and add Header always set lines inside an IfModule mod_headers.c block. The always keyword sends the header on redirects and error pages too. LiteSpeed servers, common on UK shared hosting, read the same .htaccess directives.

Nginx: add add_header lines with the always flag inside the server block, then run nginx -t and reload. Be aware that Nginx headers do not merge: if any location block contains its own add_header, every header from the server block is dropped for that location. Repeat the full set there or move it into an included snippet.

Cloudflare: HSTS has its own setting under SSL/TLS, Edge Certificates. Other headers can be added with a response header transform rule in the Rules section, which applies them to every response passing through Cloudflare without touching your server.

WordPress: a well-maintained security plugin can set most headers from its settings screen. If you prefer code, hook into the send_headers action in a small custom plugin rather than the theme, so the headers survive theme updates.

Rolling out HSTS and Content-Security-Policy safely

These two headers give the most protection and can also cause the most disruption if rushed. For HSTS, start with a max-age of 300 seconds, check the site and any subdomains, then step up to a day, then six months to a year. Only add includeSubDomains when every subdomain, including old ones used for email marketing or staging, works over HTTPS.

Preloading goes further: browsers ship your domain in a built-in HTTPS-only list. To qualify, the header must have a max-age of at least 31536000 seconds, include includeSubDomains and preload, be served from the bare domain, and the site must redirect HTTP to HTTPS on the same host first. Removal takes months to reach users, so treat it as permanent.

For CSP, send Content-Security-Policy-Report-Only first, browse the site with the developer console open and note every violation. Add the sources you genuinely need, remove scripts you do not, and only switch to the enforcing header when the console stays quiet across your key pages and checkout.

Security header best practice

Security headers are a layer, not a fix for vulnerable code. Keep your CMS, plugins and server software patched, and use headers to reduce the impact when something slips through.

• Set each header in one place. If the CDN, server and CMS all add X-Frame-Options, conflicting duplicates can be ignored by browsers.
• Send headers on every response, including error pages, redirects and static files, not just HTML pages.
• Use SAMEORIGIN or DENY for framing, and add frame-ancestors to your CSP as the modern equivalent.
• Test Cross-Origin-Opener-Policy carefully: same-origin can break sign-in and payment pop-ups.
• Re-run the security headers checker after plugin updates, theme changes, server migrations and CDN changes, when headers most often disappear.

Examples you can copy

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

<?php
add_action('send_headers', function () {
    header('X-Content-Type-Options: nosniff');
    header('X-Frame-Options: SAMEORIGIN');
    header('Referrer-Policy: strict-origin-when-cross-origin');
    header('Permissions-Policy: geolocation=(), camera=(), microphone=()');
});

curl -sI https://www.example.co.uk/ | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy"

Common mistakes to avoid

Frequently asked questions