What Are HTTP Security Headers?
When someone opens your site, the server sends back more than HTML. It also sends HTTP response headers - small instructions that tell the browser how to handle your pages. Some of those headers are purely technical. Others are there specifically to reduce risk: they limit what scripts can load, stop your site from being framed on a shady domain, or force HTTPS on return visits.
Most people never see them. Developers often forget to set them until something goes wrong, or until a security audit flags the gap. The good news is they are usually a one-time server config change, and this tool lets you check them in seconds without digging through DevTools on every domain you manage.
Why Bother Checking Security Headers?
Headers will not replace a proper code review or a WAF, but they close off a bunch of cheap attacks. Clickjacking, mixed content slips, XSS from injected scripts - browsers can block or soften a lot of that behaviour if you give them the right directives. Search engines do not rank you higher just because HSTS is on, yet visitors and clients notice when a site feels careless about basics.
If you run more than one site - a blog, a shop, a client project - it is worth scanning each one after deploy. Config drifts. A staging fix does not always make it to production. A five-minute header check catches that early.
Headers This Checker Looks For
We focus on six headers that show up on almost every security checklist. Missing one does not mean your site is doomed; present ones still need sensible values. Still, absence is a fair warning sign.
Strict-Transport-Security (HSTS)
Tells browsers to stick to HTTPS for a set period. Without it, a user on public Wi‑Fi could be nudged onto HTTP first - classic SSL stripping territory. You want a sensible max-age and ideally includeSubDomains if your whole property is HTTPS-only.
Content-Security-Policy (CSP)
Defines which sources are allowed for scripts, styles, images, and frames. Getting CSP perfect takes iteration; even a report-only policy is better than nothing. We count both standard CSP and report-only variants as a pass.
X-Content-Type-Options
Usually set to nosniff. Stops the browser from guessing file types in ways that can turn an uploaded image or document into executable content.
X-Frame-Options
Controls whether your pages can sit inside an <iframe> on another site. DENY or SAMEORIGIN is typical. Useful against clickjacking where a user thinks they are clicking your UI but are actually on an attacker's overlay.
Referrer-Policy
Decides how much URL detail leaves your site when someone follows a link out. Tighter policies (strict-origin-when-cross-origin, no-referrer) cut down accidental leakage of paths or tokens in query strings.
Permissions-Policy
Replaces the older Feature-Policy name on many stacks. Lets you switch off camera, microphone, geolocation, and similar APIs for pages that do not need them. Less attack surface, fewer surprise permission prompts.
How to Run a Scan
Paste a full URL (or just the domain - we add https:// if you skip the scheme) and hit Analyze. You will get a score, a card per header, and the raw response list if you want to copy values into a ticket for your host or dev team. Re-scan after you deploy changes; header updates often need a cache clear or CDN purge before they show up publicly.
Fixing Missing Headers
Where you edit them depends on your stack. Nginx and Apache use add_header or Header set in config. WordPress users often use a security plugin or the theme's functions file - though server-level is cleaner. Cloudflare and similar CDNs let you inject headers at the edge, which is handy when you cannot touch origin config.
- Start with HSTS only after HTTPS works everywhere - otherwise you can lock users onto broken HTTP.
- Roll out CSP in report-only mode first if you are nervous about breaking inline scripts.
- Test checkout, login, and embed pages after changes; those are where strict headers bite.
Limits Worth Knowing
Scans pull live headers from the target URL via a public lookup service. Rate limits apply on busy days, so if a scan fails, wait a minute and try again. Results reflect what the server returns to that request - redirects, CDNs, and regional edges can differ slightly from what you see in your own browser on localhost. Use this as a quick health check, then confirm critical fixes in your production environment.