Security Headers Analyzer
The GGX Labs Security Headers Analyzer is built to answer a very specific question: what is the server telling the browser to do? HTTP headers are one of the cleanest and most reliable ways a web application can shape client behaviour, yet they are still underused, misconfigured or omitted entirely in far too many deployments. This page exists to surface those controls in a structured way so the results are easy to read, easy to compare and useful for actual hardening work.
A good headers report should not just say that a policy exists. It should explain what the policy means, whether it is strict or permissive, how it interacts with the rest of the stack and where the practical gaps are. That is why the analyzer is presented as a full report rather than a tiny status widget. The idea is to give developers, security analysts and administrators enough context to make decisions instead of merely collecting badges.
The scanner is especially relevant for login pages, dashboards, admin panels, API gateways, public marketing pages and any service that processes user data. In those environments, the correctness of response headers has direct security impact. A missing HSTS header may leave transport behaviour weaker than intended. A loose CSP may allow unexpected resource execution. An absent framing policy can expose the site to clickjacking. These are small configuration choices with outsized operational consequences.
What the analyzer actually checks
At a minimum, the analyzer inspects the HTTP response headers that shape browser security posture. That includes Content Security Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Depending on the response, it can also evaluate cross-origin controls, caching behaviour, cookie flags and other indicators that affect whether a page is being served with modern hardening measures.
CSP deserves special attention because it is not just a signal; it is a policy engine for resource loading. A strong policy can reduce the risk of inline script abuse, restrict third-party dependencies, control where images, styles, frames and connections may originate and create a meaningful barrier against injection-driven attacks. The analyzer should therefore not merely display the header; it should help the user understand whether the policy is actually useful or merely decorative.
HSTS is another core control because it instructs browsers to use HTTPS automatically after the first trusted visit. That is a simple mechanism with a strong security effect, provided the deployment is actually ready for it. If a site claims HSTS too early, or applies it inconsistently, the result can be operational breakage rather than protection. The analyzer helps identify whether the transport posture looks mature enough to justify strict enforcement.
Why security headers matter
Security headers are part of the browser’s trust contract. They do not replace authentication, input validation, server-side access control or secure software design, but they do reduce the number of ways a client can be tricked into unsafe behaviour. For a large class of web applications, that makes them one of the highest leverage hardening steps available.
X-Frame-Options and the frame-related parts of CSP are especially relevant for clickjacking resistance. If a sensitive page can be embedded in an attacker-controlled frame, the attacker may be able to mislead the user into performing actions they did not intend. Blocking framing is not always appropriate for every page, but for admin surfaces and account-management flows it is usually the correct default.
X-Content-Type-Options helps avoid MIME sniffing behaviour that can cause browsers to interpret resources in unsafe ways. Referrer Policy reduces the leakage of URL context across navigations and cross-origin requests. Permissions-Policy governs access to browser features such as camera, microphone, geolocation and other sensitive APIs. Each of these controls is narrow on its own, but in aggregate they meaningfully reduce risk.
How to read the report
Start with the overall summary. The first thing you should learn is whether the site has the obvious protections in place or whether it is missing the usual hardening baseline. If the report immediately shows absent HSTS, weak framing protection or a permissive CSP, that tells you where to focus. The summary is not the whole story, but it is the fastest way to prioritise your attention.
After the summary, inspect each header one by one and read it in context. A policy can exist but still be ineffective if it is too permissive, duplicated in conflicting ways or overridden by downstream infrastructure. A site behind a CDN, reverse proxy or platform middleware may have security headers injected at multiple layers, so you should understand both the final response and the likely source of those headers.
The most important practical question is not whether a header is present in isolation, but whether the deployed behaviour matches the intent of the application. A static documentation site and a transaction-heavy dashboard have different threat models. The analyzer should help you compare the visible policy to the risk surface it is supposed to protect.
Content Security Policy
CSP is often the most valuable header in the entire set, but it is also the one most likely to be misconfigured. A weak policy might allow broad script sources, permit inline execution without strong justification or open network connections to many origins. A strong policy usually starts from a restrictive default and then whitelists only the exact resources required for the page to function.
A meaningful CSP analysis should explain whether script sources are locked down, whether inline code is controlled, whether object, frame and connect destinations are constrained and whether reporting or enforcement mode is actually active. In practice, many applications ship a policy that looks impressive but still contains enough broad allowances to weaken its usefulness.
The analyzer should also help distinguish between defensive maturity and cosmetic configuration. A header that exists only because a framework inserted a default value is not the same as a policy that was intentionally designed around application dependencies. The real question is whether the policy would still hold up after a security review, not whether it merely passes a checklist.
HSTS and transport hardening
HSTS is a transport control with a simple user-visible effect: browsers are told to use HTTPS automatically for future visits. That can prevent protocol downgrade problems and reduce the chance of accidental insecure access. For sites that already operate exclusively over TLS, HSTS is usually a sensible next step once the deployment is stable.
The details matter. A short max-age value gives little long-term protection. The includeSubDomains directive can strengthen coverage but also increases the blast radius if subdomains are not ready for strict HTTPS. Preload is even more deliberate and should only be considered when the organisation has full control of the domain structure and understands the operational implications. The analyzer should help surface those differences clearly.
HSTS is most effective when it is consistent. If a site only serves some paths securely, or if subdomains have uneven TLS readiness, then a strict transport stance can introduce friction. The right conclusion is rarely “turn it on everywhere immediately” or “never use it”; the right conclusion is to understand whether the domain’s lifecycle, subdomain estate and deployment maturity justify it.
Framing, MIME and referrer controls
X-Frame-Options and the CSP frame-ancestors directive are the main defences against unwanted embedding. In legacy environments, X-Frame-Options may still be the only framing control available. In modern environments, CSP frame-ancestors is more expressive and generally preferred, but older browser support and deployment reality can still make X-Frame-Options relevant as a compatibility layer.
X-Content-Type-Options: nosniff is an important low-friction hardening measure because it limits browser content-type guessing. It is especially valuable when serving scripts, styles or file downloads where type confusion can become dangerous. Referrer Policy, meanwhile, is about minimising unintentional disclosure of URL context. A strong policy reduces leakage while still preserving the telemetry the site genuinely needs.
These controls are often treated as checkbox items, but they are best understood as small, targeted boundaries on browser behaviour. They do not solve every problem, yet they meaningfully constrain how aggressively the browser may interpret content or expose navigation context. That is exactly the sort of restriction a mature security posture should prefer.
Permissions policy and feature exposure
Permissions-Policy defines which browser features may be used and by whom. It can disable high-risk features globally or scope them to specific origins, depending on implementation and browser support. For applications that do not require camera, microphone, geolocation, payment-related browser primitives or other sensitive capabilities, explicit denial is often the right default.
The value of this header is not only in preventing abuse. It also documents intent. A clean policy says, in effect, “this application does not need these browser features.” That is useful both to the security reviewer and to the developers who later maintain the application. Security architecture improves when intent is visible in the configuration rather than trapped in scattered tribal knowledge.
In the analyzer, this policy should be reported in a way that makes it obvious whether the application is narrowing access or simply omitting the header. Omitting the header may be acceptable in some contexts, but a deliberate policy is usually easier to reason about than inherited browser defaults.
Cookies and client-side session hardening
Security headers analysis is incomplete if it ignores cookie attributes. Even though cookies are not headers in the same defensive sense as CSP or HSTS, they are still part of the browser boundary and can make or break session security. Secure, HttpOnly and SameSite flags help determine whether cookies are exposed to script, transmitted only over HTTPS and constrained in cross-site contexts.
A session cookie without Secure should not be considered acceptable on a site that handles real user data. A cookie without HttpOnly is much more exposed to script-based theft if the application ever suffers injection issues. A cookie without a sensible SameSite posture may be too permissive for cross-site request flows. The analyzer should present these issues plainly rather than burying them in general commentary.
Cookie security is often where the browser-facing and application- facing layers meet. The server is responsible for issuing the right flags, but the browser is the enforcement point. That makes cookie analysis a natural extension of header analysis rather than a separate topic.
What good output looks like
Good output is not just complete; it is readable. A strong report should make it obvious which protections are present, which ones are weak and which ones are missing entirely. It should also show uncertainty where the tool cannot confidently observe a response, such as when a site is behind a challenge page, returns sparse headers or conditionally serves different policies by path or user agent.
The report should distinguish between “present but permissive” and “absent”. Those are different conditions with different remediation paths. A permissive CSP is not the same thing as no CSP at all. A short HSTS max-age is not the same thing as no HSTS header. The point of the analyzer is to preserve that nuance so the operator can make a real judgement instead of a shallow one.
It is also useful when the output identifies likely deployment sources. If a header appears to come from the application itself, that is different from a header injected by a CDN, reverse proxy or platform layer. Knowing where a control originates helps when planning remediation because it tells you which team or config surface actually needs to change.
Typical use cases
- Reviewing a production site before security sign-off.
- Auditing a login, checkout or admin surface for baseline hardening.
- Checking whether a new deployment kept its CSP and HSTS intact.
- Comparing staging and production header posture.
- Validating whether a reverse proxy or CDN is injecting the right controls.
- Documenting the security baseline for internal systems.
- Investigating browser-side risk during incident response or triage.
Why the page is structured this way
The frontend should feel like a report, not a form. The user is not here to fill in a survey; the user is here to understand a security posture. That is why the page pairs the live tool component with a long-form explanation underneath. The tool gives the actual result, while the article provides the reading frame that makes the result meaningful.
This structure also scales well. If the analyzer later adds more checks, such as report-only CSP handling, COOP/COEP/CORP visibility, cache-control analysis, response splitting diagnostics or framework-specific header guidance, the page can grow without losing coherence. That is a better long-term architecture than stuffing everything into a small tabbed interface with no narrative order.
In practice, the page should serve both as a tool and as the documentation for the tool. That makes it easier to understand, easier to index and easier to expand over time.
Frequently asked questions
What does a security headers analyzer check?
A security headers analyzer checks the HTTP response headers returned by a website and evaluates whether important browser-side protections are present and configured correctly. That usually includes Content Security Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer Policy, Permissions Policy, Cross-Origin policies and cookie attributes. The purpose is to assess whether the site is actively signalling safe browser behaviour or leaving gaps that can increase attack surface.
Why are security headers important?
Security headers are important because they let the server tell browsers how to handle content, framing, transport, cookies and cross-origin behaviour. Correctly configured headers can reduce the impact of clickjacking, MIME-sniffing abuse, insecure transport, data leakage and some classes of cross-site interaction problems. They are not a complete security control by themselves, but they are a high-value defensive layer.
Does this tool inspect the page content itself?
The primary focus is the response headers, not deep content parsing. That matters because headers describe how the browser should behave before the page is rendered. Some implementations may also record basic response metadata or visible indicators, but the core security decision is based on the actual HTTP header set returned by the host.
Why is Content Security Policy so difficult to get right?
CSP is difficult because it is both expressive and fragile. A strong policy has to allow the resources your site genuinely needs while refusing everything else by default. Many sites start with a permissive policy to avoid breakage, then gradually tighten it. That transition often exposes hidden inline scripts, third-party assets, legacy dependencies and analytics integrations that were never documented properly.
Are missing headers always a vulnerability?
Not always, but missing headers are usually a sign that the defence-in-depth posture could be improved. Some headers are more situational than others. For example, a public static site may not need every possible policy, whereas a login page, dashboard or application that handles user data should be much stricter. The right judgement depends on the exposure model and the functionality being delivered.
Can this tool be used for any website?
It can analyse any public website or endpoint that returns HTTP responses, but you should only inspect systems you are authorised to review. The output is intended for defensive assessment, hardening, development and incident response, not for unauthorised probing or abuse.
Why do some sites return incomplete results?
Some sites block automated requests, require challenge flows, present different headers to different user agents or terminate connections before a full response can be collected. That does not necessarily mean the tool is failing; it often means the site is using protection layers that limit what can be observed from the outside.
Related tools
Practical reading order
If you are using the analyzer for the first time, read the report in this order: start with CSP, then HSTS, then framing, MIME and referrer controls, then Permissions-Policy, then cookie flags, and finally the broader response metadata. That sequence surfaces the highest-impact controls first and keeps the analysis disciplined.
For a live audit, compare the current result against the expected standard for that application. A marketing site may tolerate a lighter policy set than a dashboard. A sensitive internal tool should usually have tighter framing, stricter cookies and a more deliberate CSP. A production login page should almost always be held to the strongest standard the deployment can safely support.
The tool is most useful when used iteratively. Run it against the same host after deployments, framework changes or CDN updates, and compare the header posture over time. Security headers are easy to break accidentally and easy to verify quickly, which makes them ideal for continuous review rather than one-time setup.