Resolved addresses
Type Value TTL
No target addresses were returned.
Security Headers Check
Inspect browser-facing security headers for a URL or host.
Use Security Headers Check to resolve the URL or hostname you enter, fetch the final response through the backend, and review whether important headers like HSTS, CSP, frame, and content-type protections are present.
This page checks the final response header set. Headers can still vary by path, hostname, CDN, or proxy layer.
Security headers result
https://example.com
HEADERS FOUND
Header observations
Header Value State
No security headers were returned for this response.
What this Security Headers Check tool does
This page normalizes a URL or host, resolves the hostname through public DNS, and asks the backend to fetch the final response headers for the target.
Use it to confirm whether browser-facing security headers such as HSTS, CSP, X-Frame-Options, Referrer-Policy, and X-Content-Type-Options are present on the live response.
It does not replace a full application security review. This tool focuses on practical, response-level header checks.
When to use this tool
A site loads, but you need to confirm whether browser-facing security headers are present.
A deployment changed web server or CDN behavior and you want to compare the live header set.
You want a fast next step after HTTPS or certificate checks.
A browser hardening review needs a quick look at CSP, HSTS, frame, and content-type protections.
A site behaves differently behind a proxy or CDN and you need to verify the final response headers.
You want to separate transport problems from missing or incomplete security controls.
How to use Security Headers Check
- Enter a URL or host.
- Run the check and confirm the normalized target.
- Review whether the hostname resolves to A or AAAA records.
- Inspect the returned security headers and compare them with your expected policy.
- If the result is missing, wrong, or incomplete, continue to HTTPS Check, TLS Certificate Check, or the configuration layer that sets headers.
How to interpret security header results
Headers returned
Likely meaning: The backend could reach the URL or hostname and inspect the final HTTP response headers.
Common causes: This usually means the site is reachable and returning a visible header set.
Next action: Review which security headers are present and which are missing, then compare with your expected policy.
Missing HSTS
Likely meaning: The site did not return Strict-Transport-Security.
Common causes: HSTS may not be configured at the application, proxy, CDN, or TLS termination layer.
Next action: If the site should always be HTTPS-only, add and validate the HSTS header.
Missing CSP
Likely meaning: The site did not return Content-Security-Policy or report-only CSP.
Common causes: CSP may not be configured yet or may only exist on some paths or environments.
Next action: Define a CSP policy and deploy it carefully, starting with report-only if needed.
Fetch failed
Likely meaning: The backend could not retrieve the response headers for the URL or hostname you entered.
Common causes: The site may be down, blocking requests, redirecting unexpectedly, or failing at TLS or network level.
Next action: Continue to HTTPS Check, TLS Certificate Check, DNS Lookup, or Ping.
No DNS answer
Likely meaning: The hostname did not return A or AAAA records from the resolver used by this page.
Common causes: The hostname may be wrong, missing, stale, or published incorrectly.
Next action: Run DNS Lookup and check nameservers or propagation next.
Header scope mismatch
Likely meaning: Some headers may only appear on certain paths, hostnames, or edge responses.
Common causes: CDN config, proxy rules, app middleware, or path-specific behavior can all change headers.
Next action: Compare the final URL and path you tested with the exact page or host you intend to secure.
Common security-header issues this tool helps uncover
Strict-Transport-Security is missing on a site that should be HTTPS-only
Content-Security-Policy is absent or only appears on some responses
Frame or content-type protections are missing after a proxy or CDN change
The final response differs from the hostname or path the team expected to test
The URL is reachable, but the security headers are incomplete for browser hardening
The site fails before header inspection because of DNS, TLS, redirect, or connectivity issues
Next steps after Security Headers Check
Run HTTPS Check
Confirm secure reachability and final HTTPS behavior for the same URL or hostname.
Check TLS Certificate
If the site should be secure but the response looks wrong, verify certificate details next.
Run HTTP Check
Compare plain HTTP behavior if redirects or scheme handling may affect the final response.
Run DNS Lookup
If the wrong host or edge is responding, inspect the DNS records next.
Related tools
HTTPS Check
Verify HTTPS availability, response chain, and TLS handshake basics.
HTTP Check
Review HTTP response status, headers, and redirect behavior.
TLS Certificate Check
Inspect certificate validity, issuer chain, and expiry details.
DNS Lookup
Query A, AAAA, CNAME, TXT, and other DNS records for a domain.
Ping
Check whether a host responds and measure round-trip latency.
Security Headers Check FAQ
What does Security Headers Check do?
It normalizes a target URL, resolves the host, and asks the backend to fetch the final response headers so you can review browser-facing security headers.
What input should I enter?
Enter a full URL such as https://example.com/path or a host like example.com. If no scheme is supplied, this page assumes HTTPS.
Why can a site be reachable but still fail this check?
The site may load, but important headers such as HSTS, CSP, X-Frame-Options, or Referrer-Policy can still be missing or incomplete.
Does this replace a full security audit?
No. This page is a fast utility check for common browser-facing response headers, not a complete application security review.
Why do headers differ between pages or environments?
Headers can change at the app, proxy, CDN, or path level, so different hostnames and URLs can return different policies.
What should I check after this page?
Usually HTTPS Check, TLS Certificate Check, DNS Lookup, or the application and CDN configuration that sets the headers.