A secure headers test checks the HTTP responses your site sends and whether important browser policies are present and fit the site’s behavior. You can inspect responses with an HTTP client or browser developer tools, then use a scanner as a second check. Treat the result as a configuration signal—not proof that a site is secure or a full security audit.
What an HTTP security headers test checks
When a browser requests a page, the server returns a response containing a status, headers and, usually, a body. Security response headers tell the browser how to handle aspects of that response: which resources it may load, whether to use HTTPS on later connections, how to interpret content types, how much referrer information to share, and which browser features a document may use.
A test can report a header that is missing, malformed or configured in a way the scanner considers weak. Those are different findings. A missing header may be worth adding; a present policy may still be too broad, too restrictive or inconsistent with the application. A scanner checks only its own rules and the responses it can reach. It does not establish that the application has no vulnerabilities.
Check the hostname and URL tested, response status, redirects and relevant paths. A homepage result does not necessarily represent an API route, login flow, static asset or error page. If a scanner provides a score, read the individual findings and understand the tested scope rather than treating the score as a security guarantee.
#1 Best Overall
Check response headers yourself
Use cURL to inspect the response and redirects
Replace https://example.com/ with the URL you want to check. This command follows redirects, saves the response headers from each response to headers.txt, discards the body, and prints the final effective URL and status code:
curl -sS -L --max-redirs 10 -D headers.txt -o /dev/null -w 'Final URL: %{url_effective}nHTTP status: %{http_code}n' https://example.com/Open headers.txt and review each response block. The first block may be a redirect, not the final page. Check which host sent each policy and whether the final HTTPS response contains the headers you expect. A redirect from HTTP to HTTPS is useful, but it is not itself evidence that HSTS has already been learned by a browser.
To inspect the HTTP endpoint and its redirect behavior explicitly, run:
curl -sS -D - -o /dev/null -w 'nFinal URL: %{url_effective}nHTTP status: %{http_code}n' http://example.com/This second command does not follow the redirect, so you can see the initial HTTP response. If you also want the destination response, add -L. Do not put credentials or private tokens in a URL you plan to share or publish.
Rank #2
Inspect a response in Python
With Python and the requests package installed, this script follows redirects, prints each response in the redirect history, then reports the final response headers:
import requests
url = "https://example.com/"
response = requests.get(url, timeout=30, allow_redirects=True)
for item in [*response.history, response]:
print(f"n{item.status_code} {item.url}")
for name, value in item.headers.items():
print(f"{name}: {value}")
print(f"nFinal status: {response.status_code}")Header names are case-insensitive. A request client can show what the server returned, but it does not reproduce every browser behavior or prove that all users receive the same response. Caches, geography, authentication, cookies, user-agent rules and application routing can affect what is returned.
Use browser developer tools
- Open the page in your browser and open Developer Tools.
- Select the Network panel and reload the page.
- Select the document request for the page, not just an image or script request.
- Review its status, redirect sequence and response headers. Repeat for other important routes, such as sign-in pages or API endpoints.
Browser tools are useful for seeing the response the browser received during that session. They do not replace checking other paths or environments.
Review the main security headers
Content-Security-Policy
Content-Security-Policy (CSP) lets a site control which resources a browser may load for a page. Directives can restrict scripts and other resource types and can address embedding and related browser behavior. CSP can help reduce the impact of cross-site scripting, but it must reflect the site’s real scripts, styles, images, connections and embeds. A generic restrictive policy may break legitimate functionality; a permissive one may provide less protection than intended.
Before enforcing a proposed policy, use Content-Security-Policy-Report-Only to observe violations without applying that policy as a block. Review what the site legitimately loads and adjust the policy before moving to enforcement. MDN’s CSP guidance says a CSP should be delivered in the Content-Security-Policy response header. Its upgrade-insecure-requests directive is not a replacement for HSTS.
Strict-Transport-Security
Strict-Transport-Security (HSTS) tells browsers to use HTTPS for future connections to the host after they have received the policy over HTTPS. Browsers ignore HSTS when it is sent over insecure HTTP. It applies to a hostname, not an IP address. The includeSubDomains directive extends the policy to subdomains, so use it only when those subdomains are ready to work exclusively over HTTPS.
HSTS ordinarily cannot protect a browser’s first visit before that browser has received the policy. Preloading can mitigate that first-connection gap, but it has broader, domain-wide consequences; do not treat a scanner’s preload suggestion as a harmless checkbox. Confirm that every affected host can support HTTPS before adopting a wider policy.
X-Content-Type-Options
The relevant value is nosniff. It tells browsers to respect the MIME type declared in Content-Type rather than infer a different type. For script and style requests, a mismatch between the declared type and the expected JavaScript or CSS type can cause the browser to block the response. The header does not repair an incorrect Content-Type; serve each resource with the appropriate type.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Rank #4
Referrer-Policy
Referrer-Policy controls how much referrer information accompanies requests. no-referrer sends none. same-origin limits the referrer to same-origin requests. strict-origin-when-cross-origin sends the full URL for same-origin requests, only the origin for qualifying cross-origin HTTPS requests, and none when moving from HTTPS to a less secure destination. MDN identifies strict-origin-when-cross-origin as the default when no valid policy is supplied. Choose a policy with the site’s privacy and integration needs in mind.
Permissions-Policy
Permissions-Policy lets a site allow or deny selected browser features in its document and embedded frames. The appropriate settings depend on which features the application uses and what its supported browsers implement. MDN labels the documented feature experimental, so verify current browser behavior and compatibility before adopting a generic allowlist or denylist.
Interpret scan results without overreacting
- Confirm what was tested. Record the hostname and URL, response status, redirect chain and whether the final response was HTTPS. Check that the result is for the page or endpoint you care about.
- Separate absence from policy quality. “Header missing” differs from “header present but unsuitable.” Inspect the actual value and understand what that policy does before changing it.
- Match policy to application behavior. For CSP, identify legitimate resource sources and use report-only observation before enforcement. For HSTS, confirm the HTTPS setup and consider the effects on subdomains or preload before expanding scope.
- Check representative routes. Repeat tests for important page types and API endpoints. A scanner may not authenticate, exercise application flows or reach every response path.
- Verify after a change. Recheck the actual response and test application behavior. A passing scan cannot establish that the rest of the application is free of security flaws.
MDN’s HTTP Observatory documentation cautions that API results may not accurately reflect an API’s overall security posture. More generally, a header scan is one limited configuration check. It is not a substitute for reviewing authentication, authorization, input handling, dependencies, TLS configuration or other parts of an application’s security.
Common problems and fixes
- The expected header is missing from the final response. A redirect response may differ from the destination response, or a proxy, CDN, application server or route may be setting headers inconsistently. Inspect every response in the chain and check the layer responsible for the final response.
- HSTS appears on HTTP but not HTTPS, or the reverse. Browsers ignore HSTS received over HTTP. Configure it on HTTPS responses and verify the HTTPS endpoint directly.
- A CSP change breaks scripts, styles or embeds. The policy may not include a resource the site legitimately uses. Roll back or adjust the enforcement change, gather violations in report-only mode and test the revised policy before enforcing it.
- Scripts or styles stop loading after enabling
nosniff. Check the resource’sContent-Typeand correct the server or application response instead of relying on MIME guessing. - The scanner’s score differs from a manual check. Compare the exact URL, redirect handling, response status and tested path. Tools may have different rules and scope; investigate the underlying response and finding rather than assuming one score is definitive.
- A command returns a timeout or unexpected status. Check the URL, network access, DNS, TLS connectivity and whether the endpoint requires authentication. Test a representative public route where possible; a public scanner may not be able to inspect a private or login-protected response.
Performance, reliability and cost considerations
Header inspection is a request-and-response check, but the result is only as representative as the request and response examined. A single public URL may miss authenticated pages, regional variants, cache behavior, application-specific errors or endpoints that return different headers. For a dependable review, test several representative paths, record status and redirects, and rerun checks after configuration changes.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11No scanner result establishes that the site is secure overall. MDN’s Observatory documentation specifically cautions that API results may not accurately represent an API’s overall security posture. The research basis for this article does not establish a universal price or performance comparison among security-header scanners; check a tool’s current scope, handling of submitted hostnames and terms before sending sensitive targets.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server, not an HTTP security-header scanner: it can capture a page visually, but use cURL, browser developer tools or a security-configuration scanner to inspect response headers. If a visual record of a public page is useful alongside your header review, a single GET request can capture it. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpScreenshotNeo removes cookie banners, newsletter popups and chat widgets before capture; bot checks, blank pages and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. These are screenshot features, not a substitute for a header test.
Sign up free for ScreenshotNeo.
Frequently Asked Questions
Do security headers prevent SQL injection or fix insecure application code?
No. They are browser-facing response policies. They do not replace secure query handling, access controls, input validation or application security testing.
Can I test a route that requires a login with a public scanner?
Not necessarily. A scanner that cannot authenticate may only inspect a public redirect or login page. Use an authorized method that can reach the protected route, and avoid submitting credentials to a service unless its handling is acceptable to you.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
