Free Security Headers Checker: Test HSTS, CSP, and More

What a security headers checker tests, and why it matters

A security headers checker exists because every time someone loads your website, your server sends back more than just the page. It also sends HTTP response headers: small instructions that the visitor's browser reads before it renders anything. A few of those headers are security controls. They tell the browser to refuse insecure connections, to block your pages from being embedded in a scammer's frame, and to stop certain classes of attack before they start.

The catch is that these headers are off by default. Unless you (or your host, or a plugin) have explicitly turned them on, your site is shipping without them, and the browser falls back to its most permissive behaviour. That is the gap this check is built to find.

Here is what BadgerScan looks at and what each one does:

• HSTS (Strict-Transport-Security): forces browsers to use HTTPS for your domain, even if a visitor types http:// or clicks an old link. This shuts down a common downgrade trick where an attacker on the same network quietly strips your encryption.
• Content-Security-Policy (CSP): a whitelist of where scripts, styles, and images are allowed to load from. A good CSP is the single strongest defence against cross-site scripting, because injected JavaScript from an unapproved source simply will not run.
• X-Frame-Options: stops other sites from loading your pages inside an invisible frame. This blocks clickjacking, where a visitor thinks they are clicking your real button but are actually clicking something the attacker overlaid.
• X-Content-Type-Options: set to nosniff, this stops the browser from guessing a file's type and accidentally treating an uploaded image or text file as executable script.
• Referrer-Policy: controls how much of your URL gets passed to other sites when a visitor clicks away. It keeps query strings and private path information from leaking into third-party logs and analytics.

How BadgerScan checks it

There is no separate security-headers tool to run. This check is one part of the single free BadgerScan external scan. When you enter your domain, BadgerScan makes a normal, passive request to your site, reads the response headers your server sends back, and records which of the headers above are present, missing, or weakly configured. It is exactly the view an outside visitor's browser gets, which is the same view an attacker gets.

The scan is read-only and passive. BadgerScan never does penetration testing or active exploitation: it looks at what your server volunteers, the same way a browser does, and nothing more. Alongside headers, that one scan also covers your DNS, your email authentication (SPF, DKIM, and DMARC), your TLS certificate, exposed files, and known CVEs for any publicly detectable software versions, then folds everything into one grade.

Run the free scan and your headers result lands in the same report as the rest. If you run WordPress, Pro adds a read-only plugin that scans the inside of your site and fuses inside and outside findings into one plain-English grade and one deduplicated fix-list.

How to read your result

BadgerScan reports each header as present, missing, or present but weak. A missing header is not a live break-in, and your site will look and work exactly the same to visitors. What it means is that a layer of protection you could have is simply switched off, leaving the browser on its most permissive default.

Treat HSTS, X-Frame-Options, and X-Content-Type-Options as the quick wins. They are safe, near-universal, and you can usually add all three in minutes without touching how your site behaves. Content-Security-Policy is the highest-value header and also the most involved, because a strict policy has to list every legitimate source your pages actually use. It is worth doing carefully rather than rushing.

Headers are one signal among several. A clean header result is good, but pair it with strong email authentication and a valid, current TLS certificate for the full picture of what attackers see from outside. The combined BadgerScan report shows you how the pieces stack up together instead of in isolation.

Common fixes

Most of these are a few lines added once, either at your web server, your CDN, or through a plugin. Add them, then re-run the scan to confirm the browser is now receiving them. A few practical starting points:

• Add HSTS only once your whole site already works on HTTPS, then start with a short max-age, confirm nothing breaks, and raise it. Setting HSTS before HTTPS is solid can lock visitors out.
• Roll out CSP in report-only mode first. The browser will tell you what a strict policy would have blocked, so you can add your real script and style sources before you enforce it and accidentally break a form or analytics tag.
• Set X-Frame-Options to SAMEORIGIN (or use the frame-ancestors directive in your CSP, which supersedes it) unless you genuinely need another site to embed your pages.
• Set X-Content-Type-Options to nosniff. It is safe for almost every site and needs no tuning.
• Set a sensible Referrer-Policy such as strict-origin-when-cross-origin to stop full URLs leaking off-site.
• On WordPress, you can add headers in your server config, at your CDN edge, or with a security plugin: just avoid setting the same header in two places, which produces conflicting or duplicated values. WordPress.org's hardening guide is a good reference for site-level hardening (WordPress.org, Hardening WordPress).