How to Check Website Security Headers

Every time a browser requests a page from your web server, the server responds with HTTP headers — metadata that provides information about the response. Most headers are functional, specifying content type, caching behavior, or encoding. Security headers are a specific subset that instruct the browser to apply security protections when rendering your page.

For example, the Content-Security-Policy header tells the browser which sources of content are allowed, helping prevent cross-site scripting attacks by blocking scripts from unauthorized sources. The X-Frame-Options header prevents your page from being embedded in iframes on other sites, which mitigates clickjacking attacks. The Strict-Transport-Security header tells browsers to always use HTTPS for your domain, preventing protocol downgrade attacks.

Security headers matter because they provide a defense-in-depth layer. Even if your application code has a vulnerability, properly configured security headers can limit what an attacker can do. They are relatively easy to implement — usually a matter of adding configuration to your web server or CDN — and they are checked by security auditors, compliance frameworks, and increasingly by insurance underwriters evaluating your security posture.

It is important to understand that security headers are one component of a broader security strategy. They help reduce risk but do not replace secure application development, regular updates, access controls, or professional security assessments. Think of them as additional locks on your doors — valuable, but not a complete security system on their own.

Strict-Transport-Security (HSTS) tells browsers to always connect to your site via HTTPS, even if the visitor types http:// or clicks an HTTP link. This prevents protocol downgrade attacks and cookie hijacking. The header includes a max-age directive that specifies how long the browser should remember this rule, and optionally includes subdomains and preload directives.

Content-Security-Policy (CSP) is the most powerful and complex security header. It specifies which sources of content the browser is allowed to load — scripts, styles, images, fonts, frames, and more. A well-configured CSP significantly reduces the impact of cross-site scripting vulnerabilities by ensuring that only content from trusted sources executes. However, CSP requires careful configuration specific to your site's architecture.

X-Content-Type-Options set to 'nosniff' prevents browsers from MIME-type sniffing, which means the browser will respect the declared Content-Type header. This helps prevent attacks where a malicious file is served with a misleading content type and executed as a different type by the browser.

X-Frame-Options controls whether your page can be displayed in an iframe, frame, or object element. Setting it to DENY prevents any framing; SAMEORIGIN allows framing only from your own domain. This mitigates clickjacking attacks where an attacker overlays invisible frames on top of legitimate-looking content to trick users into clicking unintended elements.

Referrer-Policy controls how much referrer information is sent when a user navigates away from your page. Setting it to 'strict-origin-when-cross-origin' sends the full URL for same-origin requests but only the origin for cross-origin requests, balancing functionality with privacy.

Permissions-Policy (formerly Feature-Policy) controls which browser features your page can use — such as camera, microphone, geolocation, and autoplay. By restricting access to features your site does not need, you reduce the impact of any vulnerability that might try to access those features.

• Strict-Transport-Security (HSTS) — enforce HTTPS connections
• Content-Security-Policy (CSP) — control allowed content sources
• X-Content-Type-Options — prevent MIME-type sniffing
• X-Frame-Options — prevent clickjacking via iframes
• Referrer-Policy — control referrer information sharing
• Permissions-Policy — restrict browser feature access

Browser developer tools let you inspect the HTTP response headers for any page you visit. This is the fastest method for a quick check and requires no external tools. It shows you exactly what headers your server is sending for that specific page, which is useful because different pages on the same site can theoretically have different headers.

In Chrome or Edge, open Developer Tools with F12 and navigate to the Network tab. Reload the page, then click on the first request (the HTML document). In the request details panel, look for the 'Headers' tab and scroll to the 'Response Headers' section. This lists all HTTP headers sent by the server. Look for each security header by name: strict-transport-security, content-security-policy, x-content-type-options, x-frame-options, referrer-policy, and permissions-policy.

In Firefox, open Developer Tools with F12, go to the Network tab, reload, and click the document request. The Headers panel shows response headers in a similar format. Firefox also has a built-in security panel in the developer tools that highlights some security header issues, providing a quick visual assessment.

In Safari, enable the Develop menu in Preferences > Advanced, then open the Web Inspector. The Network tab shows request and response headers. Safari's interface is slightly different but provides the same information. Look for the response headers section of the document request.

The browser method shows headers for a single page at a single point in time. It is excellent for development and debugging but not suitable for ongoing monitoring. Headers can change based on server configuration updates, CDN rules, or application code changes. For continuous verification, automated checking is more reliable than periodic manual inspection.

The curl command line tool can retrieve HTTP response headers without loading the full page. Use the command: curl -I https://yourdomain.com. The -I flag (or --head) sends a HEAD request, which retrieves only the headers without the response body. The output lists all response headers, and you can scan for the security headers by name.

For a more targeted check, pipe the output through grep to filter for specific headers: curl -sI https://yourdomain.com | grep -iE '(strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy)'. This shows only the security-relevant headers, making it easier to see what is present and what is missing.

If you need to check headers for a specific page rather than the homepage, include the full path: curl -I https://yourdomain.com/specific-page. This is useful because some applications send different headers for different routes — for example, an API endpoint might have a different CSP than the main website.

The command line method is fast, scriptable, and does not require a browser. It is particularly useful for checking headers on servers that are not publicly accessible (using appropriate network access) or for automating header checks across many domains. You can write a simple script that checks a list of domains and reports which security headers are present or missing for each one.

• Use 'curl -I https://yourdomain.com' to retrieve response headers
• Filter for security headers with grep to see only relevant results
• Check multiple pages, not just the homepage, for consistent header configuration
• Run checks periodically or automate them with scripts for ongoing monitoring

Online scanners analyze your website's security headers and provide a graded report with explanations and recommendations. These tools are valuable because they not only show which headers are present but also evaluate whether the header values are configured correctly and securely. A header can be present but misconfigured — for example, a CSP that allows 'unsafe-inline' for scripts significantly weakens the protection.

SecurityHeaders.com, created by Troy Hunt, is one of the most widely used tools. Enter your domain and it returns a grade from A+ to F based on the presence and configuration of security headers. It provides specific guidance for each header, explaining what it does, whether your configuration is appropriate, and how to improve it. The tool also checks for less common but still valuable headers like Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy.

Mozilla's Observatory is another comprehensive tool that checks security headers alongside TLS configuration, cookie attributes, and other security-related settings. It provides a score and detailed breakdown of each check. The Observatory is particularly useful because it evaluates your site against Mozilla's security guidelines, which are well-respected in the web security community.

These online tools are excellent for a one-time audit or periodic check. They provide educational context that helps you understand why each header matters and how to configure it. However, like all manual tools, they do not provide continuous monitoring. After implementing security headers based on the scanner's recommendations, you want a way to verify they remain in place — which is where automated monitoring adds value.

When you check your security headers, the results typically fall into three categories: headers that are present and correctly configured, headers that are present but misconfigured, and headers that are missing entirely. Each category requires a different response.

Missing headers are the most common finding. Many web servers and hosting platforms do not include security headers by default. If your site has no security headers at all, this is the first thing to address. Adding basic headers like X-Content-Type-Options, X-Frame-Options, and Referrer-Policy is straightforward and low-risk. HSTS requires that your site works correctly over HTTPS before enabling. CSP requires the most careful configuration because an overly restrictive policy can break legitimate site functionality.

Misconfigured headers are more subtle. A CSP that includes 'unsafe-inline' and 'unsafe-eval' for script sources provides significantly less protection than a policy using nonces or hashes. An HSTS header with a max-age of only 300 seconds provides minimal protection. An X-Frame-Options set to ALLOW-FROM a specific domain may not be supported by all browsers. Online scanners help identify these issues by evaluating the actual values, not just the presence of headers.

Present and correctly configured headers should be verified periodically. Server configuration changes, CDN rule updates, or application deployments can inadvertently remove or modify headers. What was correctly configured last month may have changed without anyone noticing. This is why ongoing monitoring matters — it confirms that your security header configuration remains intact over time.

Checking only the homepage is a common oversight. Different pages on your site may be served by different application routes or even different servers, and headers can vary between them. An API endpoint might lack headers that the main website has. A login page might need stricter CSP than a blog post. Check headers for all critical pages — especially those handling authentication, forms, or sensitive data.

Assuming that a CDN or hosting provider handles security headers automatically is another mistake. Some providers do add default security headers, but the configuration varies and is often minimal. Verify exactly which headers your provider adds and whether they meet your security requirements. If you need additional or stricter headers, you can typically add them through your CDN configuration, server configuration, or application code.

Implementing headers without testing is risky, particularly for CSP. A restrictive CSP that blocks legitimate scripts, styles, or images will break your site's functionality. Always test CSP in report-only mode first — using the Content-Security-Policy-Report-Only header — which logs violations without enforcing them. Review the reports to understand what your site needs, then craft a policy that allows legitimate content while blocking unauthorized sources.

Treating security headers as a set-and-forget configuration is a long-term risk. Headers should be reviewed when you make significant changes to your website — new third-party integrations, CDN changes, application framework updates, or hosting migrations. Each of these changes can affect how headers should be configured.

MonitorMojo helps you verify that your website's security headers remain in place and correctly configured over time. Rather than manually checking headers in browser tools or running command line checks periodically, MonitorMojo includes header checks as part of its website monitoring. This helps you detect if a configuration change, deployment, or hosting update inadvertently removes or modifies a security header.

While MonitorMojo is not a substitute for a comprehensive security audit or penetration test, it helps organize ongoing verification of your security header configuration into a consistent monitoring routine. If a header that was present last week is suddenly missing, MonitorMojo helps you spot that change early so you can investigate and restore the configuration.

Security header monitoring works alongside uptime, SSL, response time, and health checks to provide a more complete picture of your website's operational health. Results depend on your server configuration, CDN setup, and how quickly you respond to changes detected by monitoring. MonitorMojo helps you maintain awareness of your security header status without requiring manual checks for each domain you manage.