Security headers are one of the fastest ways to reduce common web risks, but many sites still misconfigure them or skip them entirely.
This guide explains how to check security headers, what to look for in the results, and how to interpret missing or weak settings.
What security headers are and why they matter
Security headers are HTTP response headers sent by a web server or application to tell browsers how to handle content, framing, cookies, scripts, and transport security.
They help mitigate attacks such as cross-site scripting, clickjacking, MIME sniffing, and insecure transport downgrade attempts.
Common headers include Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and Set-Cookie attributes like Secure and HttpOnly.
While headers are not a complete security strategy, they are a measurable baseline that can significantly improve browser-side protection.
How to check security headers in a browser
The quickest way to inspect response headers is through your browser’s developer tools.
This is useful when you want to verify what a page is actually sending to the client, including headers injected by a CDN, reverse proxy, or application framework.
Using Chrome or Edge DevTools
- Open the site in Chrome or Microsoft Edge.
- Right-click the page and select Inspect.
- Open the Network tab.
- Refresh the page so requests appear in the list.
- Select the main document request.
- Review the Response Headers section.
Look for headers such as Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and Referrer-Policy.
If the page is behind a redirect chain, inspect both the final document and any intermediate responses, because HSTS and redirect behavior can differ.
Using Firefox Developer Tools
- Open the site in Firefox.
- Open Developer Tools and choose the Network panel.
- Reload the page.
- Click the document request and inspect the Headers tab.
Firefox is especially useful when testing how a policy affects script loading, framing behavior, or mixed-content warnings alongside the response headers themselves.
How to check security headers with command-line tools
Command-line tools are the most reliable way to audit headers precisely, especially in automation or CI/CD pipelines.
They allow you to capture the raw response without browser caching or UI noise.
Using curl
Run a HEAD or GET request and print the response headers:
curl -I https://example.comFor redirects, follow the chain and inspect each response:
curl -I -L https://example.comUseful things to verify in the output:
- Whether HSTS appears only on HTTPS responses.
- Whether Content-Security-Policy is present and syntactically valid.
- Whether cookies include Secure, HttpOnly, and SameSite.
- Whether X-Content-Type-Options is set to nosniff.
Using wget or similar tools
Tools like wget can also expose response headers, but curl is generally preferred because it is widely available and easier to script.
In Linux environments, curl paired with shell scripts is often the simplest way to create a repeatable header check.
How to check security headers with online scanners
Several reputable scanners can quickly rate a site’s header posture and identify missing or weak controls.
These tools are useful for baseline audits, external reviews, and validating production domains after deployment.
Common options include securityheaders.com, Mozilla Observatory, and SSL/TLS testing platforms that also report HTTP headers.
These scanners typically analyze the main document response and assign grades or findings based on known best practices.
Use scanners carefully: they may not test authenticated pages, internal applications, or routes behind bot protection.
They are best used as a first pass, then followed by manual validation in developer tools or curl.
Which security headers should you check?
Not every site needs every header, but the following are the most important to review in 2026.
Content-Security-Policy
Content-Security-Policy, or CSP, controls which resources browsers are allowed to load.
It is one of the most effective defenses against cross-site scripting when implemented correctly.
Check whether it uses restrictive sources, avoids wildcard overuse, and includes reporting or testing modes before full enforcement.
Strict-Transport-Security
Strict-Transport-Security, commonly called HSTS, tells browsers to use HTTPS for future requests.
Check that it is served only over HTTPS and that the max-age is long enough for your security posture.
Many sites also use includeSubDomains and preload, but those settings should be adopted only after confirming all subdomains support HTTPS.
X-Frame-Options or frame-ancestors
These controls help prevent clickjacking by limiting whether a page can be embedded in an iframe.
X-Frame-Options is legacy but still widely supported, while the CSP frame-ancestors directive is the modern approach.
Verify that the policy matches your intended embedding behavior.
X-Content-Type-Options
This header should generally be set to nosniff.
It prevents browsers from guessing content types, which can reduce exposure to script or style injection through mislabeled files.
Referrer-Policy
Referrer-Policy controls how much URL information is shared in the Referer header.
Check that it aligns with privacy and analytics needs, such as strict-origin-when-cross-origin or a similarly deliberate choice.
Permissions-Policy
Permissions-Policy limits access to browser features like camera, geolocation, microphone, and payment APIs.
Audit it to ensure sensitive features are disabled unless explicitly required.
Set-Cookie attributes
Cookies are not headers in the same category as CSP or HSTS, but they are part of HTTP response security.
Inspect session cookies for Secure, HttpOnly, and SameSite.
Missing attributes can expose authentication cookies to interception, JavaScript access, or cross-site request risks.
How to interpret missing or weak headers
A missing header does not always mean the application is vulnerable, but it usually means the browser has fewer guardrails.
Weak settings often come from default server configurations, framework boilerplate, or proxy layers that overwrite upstream policies.
- No HSTS on a public HTTPS site can leave users open to SSL stripping on first contact.
- A permissive CSP such as default-src * can undermine the point of the policy.
- Missing X-Frame-Options or frame-ancestors can allow clickjacking on sensitive pages.
- Missing nosniff can increase the risk of content-type confusion in legacy scenarios.
- Overly broad Permissions-Policy settings may expose unnecessary device or location access.
When reviewing results, check both the presence and the scope of each header.
A header can exist and still be ineffective if it is too broad, incorrectly scoped to certain paths, or only delivered on some responses.
How to automate security header checks
For production environments, manual checks should be supplemented with automation.
Security header checks can be built into CI/CD, scheduled audits, or uptime monitoring.
Practical automation options include:
- Shell scripts that run curl against key URLs and compare expected headers.
- Infrastructure tests that validate reverse proxy or CDN rules before deployment.
- Security scanners integrated into pipelines for recurring checks.
- Custom unit or integration tests in frameworks such as Node.js, Python, or Go.
Automation is especially valuable when multiple services share a domain, because a header misconfiguration on one path can quietly bypass a global standard.
Common reasons headers disappear
Even well-configured apps can lose headers during deployment.
Common causes include CDN overrides, load balancer rewrites, cached edge responses, misordered middleware, server-side redirects, and framework defaults that are disabled in certain environments.
If a header appears in staging but not production, compare the full request path, including origin server, proxy, and CDN layers.
Also verify that the header is attached to the final response, not just the initial redirect.
What a good security header review looks like
A solid review checks coverage, consistency, and intent.
The goal is not simply to see headers present, but to confirm they match the application’s actual behavior and risk profile.
- Inspect the homepage, login page, authenticated pages, and static assets.
- Check HTTP to HTTPS redirects and final HTTPS responses.
- Review cookies issued during login and session renewal.
- Compare browser, curl, and scanner results for consistency.
- Retest after framework upgrades, CDN changes, or reverse proxy edits.
By combining browser tools, command-line requests, and automated scanners, you can quickly determine whether your site is protected by meaningful security headers or just carrying default settings that look secure at a glance.