How to Check HTTP Security Headers on Any Website

HTTP security headers can help browsers apply important protections, but a header’s presence alone does not prove a site is secure. To check website security headers accurately, inspect the responses your site actually sends, understand what each header does, and verify that its policy fits your application. This tutorial covers practical ways to check headers and how to interpret Content-Security-Policy (CSP), HTTP Strict Transport Security (HSTS), and X-Content-Type-Options.

Key takeaways

• Inspect the response for the exact URL and protocol you care about; different paths and redirects can return different headers.
• CSP controls which sources a browser may use for certain content. A weak or overly broad policy may provide limited protection.
• HSTS tells browsers to use HTTPS for a host after they receive the policy over a secure connection.
• X-Content-Type-Options: nosniff helps prevent MIME-type sniffing in relevant browser contexts; it does not replace correct content types.
• A header checker reports what it observed in a response. It cannot establish that an application is secure or that a policy works as intended.

What HTTP security headers do

HTTP response headers carry metadata from a server to a browser. Some headers influence how browsers handle content, connections, and cross-origin behavior. They are one layer of a site’s security configuration, alongside application code, HTTPS, access controls, and server settings.

A check is only a snapshot of a particular response. The result may vary by URL, HTTP method, redirect, deployment environment, or the layer that serves the response, such as a CDN or reverse proxy. That is why it is useful to check both the public site and the configuration that produces its responses.

How to check website security headers

1. Check the exact URL

Start with the full URL, including https://, the hostname, and any relevant path. A homepage and an application route may be served by different systems or policies. If you administer the site, test representative pages, error responses, and any alternate hostnames you use.

You can use a browser’s developer tools: open the Network panel, reload the page, select the document request, and inspect its response headers. This shows the response received by your browser. A URL status checker can also be a useful starting point when checking a public URL’s response behavior; confirm security headers in a tool or client that displays response headers.

2. Inspect the response with curl

For a direct request, curl can display response headers while discarding the response body:

curl -sS -D - -o /dev/null https://example.com/

Look for header names such as Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options. Replace example.com with a site you own or are authorized to check.

The command above does not follow redirects. To follow them, add -L:

curl -sS -L -D - -o /dev/null https://example.com/

With redirects enabled, output can contain headers for more than one response. Read each response separately: a redirect response and the final page response may have different headers. For diagnosis, test the redirecting URL and final destination independently.

A HEAD request can be convenient, but servers may handle it differently from a normal page load. When results matter, compare with a GET request such as the command above and with the browser request you want to evaluate.

Three important headers to understand

Content-Security-Policy (CSP)

CSP lets a site specify which sources the browser may use for categories of content. A policy is commonly delivered in the Content-Security-Policy response header. Directives such as default-src, script-src, and img-src set rules for different resource types. The exact effect depends on the directives present and how the application loads its resources.

For example, this illustrative policy limits several resource types to the site’s own origin and blocks plugin content:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

This is an example to explain the syntax, not a drop-in policy. An application that relies on a third-party script, inline code, or other external resources may break under it. Build and test a policy against the site’s real resource needs. A policy that allows broad sources or unsafe execution patterns may offer less protection than its presence suggests.

If you are introducing CSP to an existing application, consider testing an appropriate report-only policy before enforcing it. Review the resulting violations, account for legitimate resources, and then deploy an enforced policy deliberately. Reporting is useful for testing, but it does not itself block the reported content.

HTTP Strict Transport Security (HSTS)

HSTS is delivered using the Strict-Transport-Security response header over HTTPS. It instructs a browser that has received the policy to use HTTPS for future connections to that host for the stated period. For example:

Strict-Transport-Security: max-age=31536000

max-age specifies how long the browser remembers the policy, in seconds. The includeSubDomains parameter extends the policy to subdomains, so use it only when those subdomains are also ready to serve HTTPS. HSTS does not secure the first visit before a browser has received the policy, and it does not replace correctly configured HTTPS.

Do not enable a long duration or includeSubDomains without checking your domain and deployment plans. An incorrectly applied policy can make affected hosts inaccessible to browsers that enforce it until the policy expires or the issue is otherwise resolved. Browser preload programs have separate requirements; adding a preload token to a header does not by itself mean a host is on a browser’s preload list.

X-Content-Type-Options

The commonly used value is:

X-Content-Type-Options: nosniff

This tells browsers not to infer a different MIME type in contexts where MIME sniffing is relevant. It is not a substitute for serving the correct Content-Type for each resource. If the server labels a file incorrectly, nosniff may cause browsers to refuse to use it as expected, rather than fixing the underlying configuration.

A practical review workflow

1. Choose the right target. Record the scheme, hostname, path, and environment you are checking. Test the public production site separately from staging.
2. Capture the response. Use browser developer tools or a command-line client. Save the status code, response headers, and redirect chain so the result has context.
3. Check the three headers. Note whether CSP, HSTS, and X-Content-Type-Options are present, then evaluate their values rather than treating presence as success.
4. Compare relevant routes. Check representative pages and error responses. If a CDN, proxy, application server, or hosting platform adds headers, verify which layer is responsible for each response.
5. Test changes in a safe environment. A CSP change can block required resources; HSTS settings can affect subdomains. Validate behavior before applying changes broadly.
6. Recheck after deployment. Repeat the same requests after configuration changes and confirm that the intended response—not only a configuration file—contains the expected values.

Common mistakes and limitations

• Checking only one page: A homepage result may not represent other routes, subdomains, or error pages.
• Ignoring redirects: A redirect and its destination are separate responses. Inspect the chain and the final URL.
• Treating presence as proof: A CSP with permissive sources may not meaningfully restrict resources. HSTS on a response received over HTTP is not a reliable way to establish the policy in browsers. nosniff cannot correct a wrong MIME type.
• Confusing scanner output with a security audit: A header check does not examine application authorization, vulnerabilities, cookie handling, dependencies, or every browser behavior.
• Assuming every client sees the same response: Caches, geographic routing, authentication, user-agent variation, and deployment differences can affect what is returned.
• Using a parser as a security control: Tools that display a URL or its response are diagnostic aids. They do not replace safe server-side configuration or protect an application from unrelated threats.

Defensive recommendations

• Serve the site over HTTPS and configure HSTS only after confirming that HTTPS works for the hosts covered by the policy.
• Design CSP around the resources the application actually requires. Avoid copying a policy without understanding its directives and consequences.
• Send the correct Content-Type for each resource and use X-Content-Type-Options: nosniff where appropriate.
• Set and maintain headers at the layer that reliably handles the relevant responses, and check for conflicting or duplicated values.
• Re-test after changes to application servers, CDNs, reverse proxies, hosting platforms, or domain structure.
• Keep the scope of checks authorized. A public response-header check is different from probing private or internal systems; do not use a URL-fetching service to access systems you are not authorized to test.

Conclusion

To check website security headers well, inspect the actual response for the pages and redirects that matter, then assess each value in context. CSP, HSTS, and X-Content-Type-Options can support safer browser behavior, but none is a complete security solution. Verify configuration changes in your own environment and treat header checks as one part of a broader defensive review.