How to Check Your Website's Security Headers
A practical walkthrough of how to check what security headers your website currently sends, what the results mean, and how to fix common gaps.
Checking what security headers your website currently sends takes minutes, and it's one of the highest-value, lowest-effort security checks available. Here's how to actually do it, and what to do with the results.
Method 1: Browser developer tools
The fastest way to check a single page, with nothing to install:
- Open your site in a browser and open developer tools (usually F12 or right-click → Inspect)
- Go to the Network tab
- Reload the page and click on the main document request (the first item, representing the HTML page itself)
- Look at the Response Headers section
This shows you exactly what headers your server is actually sending for that specific request — useful for a quick spot-check, though it only reflects the single page you're looking at.
Method 2: Command-line check
For a faster, scriptable check:
curl -I https://yourdomain.com
This returns the response headers directly, without needing a browser. It's particularly useful for checking multiple pages or automating the check as part of a script or CI pipeline.
Method 3: Dedicated header-scanning tools
Several free online tools exist specifically to check and grade a site's security headers, providing a summary of what's present, what's missing, and often a letter-grade style assessment. These are a convenient starting point, though it's worth understanding what they actually check — most evaluate presence and basic configuration, not necessarily whether a given policy (like a CSP) is meaningfully restrictive versus just technically present.
What to actually look for in the results
Presence isn't the whole story — configuration matters just as much:
- Is Strict-Transport-Security present, and does it include a reasonably long
max-age? A very short duration provides limited protection. - Is Content-Security-Policy present, and how permissive is it? A policy that allows scripts from
*(any source) is present but provides little real protection. - Is X-Content-Type-Options set to
nosniff? This one is binary — either it's set correctly or it isn't. - Is frame protection present, either via
X-Frame-Optionsorframe-ancestorsin CSP? - Is Referrer-Policy set to something reasonably restrictive, rather than left at browser default behavior?
Checking across your whole site, not just the homepage
Header configuration can vary by page or by server, particularly on sites with multiple backends, a CDN in front of some paths but not others, or different configurations for API versus web routes. A check on the homepage alone doesn't guarantee the same configuration applies everywhere — checking representative pages across different parts of the site, including authenticated pages and API responses, gives a more accurate picture.
Common gaps found during a check
- Headers present on the main site but missing on subdomains or API endpoints
- A CSP that's overly permissive, effectively providing minimal real protection despite being technically present
- HSTS present but with a short
max-age, or missing theincludeSubDomainsdirective where it would be appropriate - Headers configured at the application level but stripped or overridden by a CDN or reverse proxy in front of it
After the check: fixing what's missing
Most header gaps are a matter of server, CDN or reverse proxy configuration rather than application code changes — meaning fixes are usually fast to implement once identified. The main area requiring more care is Content-Security-Policy, where a new or tightened policy should ideally be tested in report-only mode first, to catch anything it would inadvertently block before full enforcement.
How does Averto fit in?
Header checks are included as part of Averto's continuous scanning — covering configuration quality, not just presence, and checked across the actual surface of the application rather than just the homepage.
Frequently asked questions
Is it enough to check my homepage's security headers?
No — configuration can vary across subdomains, API endpoints and different parts of a site, particularly where a CDN or multiple backends are involved.
Do free header-scanning tools check configuration quality, or just presence?
Most check presence and basic configuration; understanding whether a policy like CSP is meaningfully restrictive often requires reading the actual policy value, not just seeing that the header exists.
How often should I check my site's security headers?
Periodically, and after any change to server, CDN or reverse proxy configuration — these are common points where headers get accidentally dropped or altered.
Can a CDN affect which security headers my site sends?
Yes — a CDN or reverse proxy sitting in front of your application can add, strip or override headers, so what your application code sets isn't always what actually reaches the browser.