Our HTTP Security Observer fetches and analyzes HTTP response headers from any web server. It checks for critical security headers including Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, and more. The tool also reports the server software and HTTP version, giving you a complete picture of your server's security posture.
How to Use
1Enter the domain you want to analyze.
2Click "Check" to fetch HTTP headers.
3Review all response headers and security configurations.
4Identify missing or misconfigured security headers.
Use Cases
•Audit HTTP security headers for compliance
•Verify HSTS is properly configured
•Check CSP policies for security weaknesses
•Monitor server information disclosure
Frequently Asked Questions
HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, each reported as present, absent or present but worth reviewing. The distinction between the last two matters more than it looks: a header set to a value that does nothing is easy to mistake for protection, and most people only notice after an incident. Reading the value alongside the verdict is what turns this into a finding rather than a checklist.
HTTP Strict Transport Security is a response header telling browsers to reach this site over HTTPS only for a stated period, so they never send the first request in the clear. That first request is the one an attacker wants, because everything after it is protected; without HSTS a visitor who types the hostname or follows an http:// link can be intercepted before any redirect happens. The header only takes effect once it has been received over HTTPS, and it is remembered for up to max-age, so setting it is a commitment.
Content-Security-Policy is the main defence against cross-site scripting, because it restricts which sources a page may load code and data from. It works by removing the assumption the vulnerability depends on: that a browser will happily run script an attacker managed to inject. A policy cannot make XSS impossible, but it can stop an injected script from loading, exfiltrating to, or being framed by anything the policy does not name. It is most valuable on pages that display user-supplied content.
Yes, every response header is shown as received, alongside the parsed analysis of the security-relevant ones. The raw view is the one that settles arguments, because a proxy in front of your server may be adding, rewriting or stripping headers you believe you configured, and the only way to know is to read what actually went over the wire. Check it from outside your own network as well, since a header set on one hop can be dropped on another.
Because the config is what you intended and the response is what happens. Proxies, application frameworks and platform defaults add and remove headers on the way out, so a configuration that looks correct can produce a response that is not. Reading the live response is the only way to know what a browser actually receives, which is the thing the headers are for.
No, and this is the most common gap. Headers are per response, so error pages, redirects, API endpoints and static asset paths may each have different behaviour depending on how your framework routes them. If a header is set in middleware it usually covers everything — if it is set per view it may not. Spot-check an error page and an API route before assuming coverage.
HSTS, because it is the only one that affects whether traffic is encrypted at all rather than how it is treated once encrypted. After that the content-type and framing protections, which prevent content confusion and clickjacking. The others are worthwhile but the first two close the largest gaps, and both are single-line additions with no compatibility cost.
Not a vulnerability, but it is reconnaissance you give away for nothing. It names the software and often the version, which helps someone decide whether to try a known issue. Suppressing it costs one directive and removes a useful signal for attackers. The other benefit is practical: during an incident, knowing what is in front of your application is worth more than the small cost of hiding it from everyone else.
Because you may be reaching different infrastructure. A load balancer, a CDN edge and a regional deployment can each present different headers, and a page served from cache may carry a subset of what the origin sends. Run it several times from different vantage points before concluding a finding is real — and remember that inconsistent results across locations are themselves worth understanding.
What Is Observed
Most of a server's posture is visible in its HTTP responses. This page fetches a page and reports what came back.
1Request the page over HTTPS and read the full response header set. Because the connection is established before this happens, it also confirms the transport actually works rather than assuming it.
2Check the security headers present, absent and present-but-wrong, because those are three different problems with different fixes and a presence count alone cannot distinguish them.
3Note the informational headers too — the server header, redirect behaviour and status code. None are findings on their own, but each is something you may have an opinion about and none is obvious without looking.
Headers apply per response, not per origin. A page you check can be correct while an API route, an error page or a different host serving the same content is not — so coverage across responses is worth verifying separately.
Tips & Best Practices
•Use HTTP observer to analyze HTTP security headers and configuration
•Monitor HTTP responses for security issues and misconfigurations
•Compare HTTP headers across different endpoints and servers
•Document HTTP security configuration for compliance evidence
Technical Details
Analysis: HTTP response header and security configuration analysis Headers: HSTS, CSP, X-Frame-Options, and other security headers Status: HTTP status code and response time analysis Output: HTTP security assessment with recommendations
