Security Header Check for HTTP Security Header, CSP and HSTS
Free individual check · without registration
Checks Important HTTP Security Header a URL: Strict Transport Security, Content Security Policy, X-frame options, Referrer policy, Permissions policy and more.
- HSTS / Strict Transport Security
- Content Security Policy (CSP)
- X-frame options
- Referrer policy
- Permissions policy
- X Content Type Options
- Cross-origin header
- Missing or risky header configurations
- Notes for server, CDN, proxy and CMS output
| Headers | Status | Assessment | Value/Note |
|---|---|---|---|
| — | |||
When does a security header check make sense?
A security header check is especially useful if a website is to be checked technically after a relaunch, server change or changes to CDN, proxy or hosting. Especially in productive environments, security headers are often lost unnoticed or delivered inconsistently.
After relaunch or infrastructure change
For deployments, server changes or CDN adjustments, headers are often not completely adopted or changed by new rules.
Security hardening
If you technically follow up security measures, you should check whether important headers such as CSP, HSTS or Referrer-Policy are even available and meaningfully set.
For CDN, proxy or WAF setups
In more complex architectures, headers are often placed in several places. This quickly creates inconsistencies or unintentional overwrites.
For technical QA
A quick header check helps to make technical quality visible and to detect missing safety mechanisms at an early stage.
Typical errors in security headers
Problems with security headers often do not arise because they are deliberately wrongly set, but because they Not available at all, too generally configured or delivered differently at different locations. Especially with setups CDN, Reverse Proxy, Server, CMS or App Framework Such inconsistencies are typical.
Important headers are missing completely
Often, safety-relevant headers such as Content Security Policy, Strict Transport Security or X Content Type Options Not set at all. Then the browser lacks important protection mechanisms.
Content security policy is too weak
An existing CSP is not automatically good. If rules are formulated too openly, for example with very generous approvals, the policy quickly loses a large part of its protective effect.
HSTS is missing despite HTTPS
If a website is already cleanly accessible via HTTPS, but no Strict Transport Security The potential for consistent HTTPS enforcement is not used.
Contradictions between CDN, proxy and server
In more complex setups, CDN, reverse proxy, web server or application headers sometimes set multiple or different headers. This leads to inconsistent, difficult-to-follow security signals.
Outdated or inappropriate header configuration
Some websites deliver even older low-impact headers, while more modern and relevant policies are missing or not cleanly maintained. This has a technically inconsistent effect and squanders protective potential.
Too strict rules block functions
Security headers can also be configured too restrictively. Then scripts, iFrames, external resources or integrated services are unintentionally blocked. For this reason, safety rules should not only be in place, but should also be practical.
What you should pay particular attention to
- Important security headers should be Not missing
- Policies should Conscious and Consistent set out shall be:
- Header configurations from CDN, proxy and server Should fit together
- Rules that are too open or too strict should be technically tested and properly coordinated.
FAQ: Security Header Checker
Frequent questions about HTTP security headers, browser protection mechanisms, typical misconfigurations and the technical classification of security headers on websites.
What is a Security Header Checker?
A security header checker checks which security-relevant HTTP header a website delivers. These include, for example, Content Security Policy, Strict Transport Security, X Content Type Options or Referrer policy. This allows you to quickly identify whether basic browser protection mechanisms are present or important headers are missing.
Why are security headers important?
Security headers help browsers to better limit risks. Depending on the header, they can control the handling of embedded scripts, file types, referrer information or HTTPS connections. They do not replace a secure application, but they are an important additional protection at the HTTP level.
Which headers are particularly important?
Particularly often relevant Content Security Policy, Strict Transport Security, X Content Type Options, Referrer policy and Permissions policy. Which headers actually make sense, however, always depends on setup, application and integration of external resources.
What Does a Content Security Policy Do?
The Content Security Policy specifies from which sources scripts, styles, images, frames or other resources may be loaded. It can help reduce risks from unwanted or manipulated content. However, a CSP is only really helpful if it is clean and suitably configured.
What does HSTS mean?
Strict Transport Security Signals to the browser that a website should only be accessed via HTTPS. This is especially useful if HTTPS is already cleanly set up and is to be permanently enforced. If HSTS is missing, even though the website runs entirely on HTTPS, unnecessary protection potential often remains untapped.
Is it good if the headers are simply present?
Not automatically. An existing header is only the first step. The decisive factor is whether it is also meaningfully configured. One too open Content Security Policy Or inconsistent header output via CDN, proxy and server often brings significantly less than a deliberately coordinated configuration.
Can security headers also cause problems?
Yes. If rules are set too strictly or inappropriately, scripts, external services, iFrames, images, or other resources can be unintentionally blocked. Therefore, Security Headers should not only be activated according to the checklist, but should always be tested and tuned in the real setup.
Why do headers sometimes differ by URL?
Security headers are not always delivered identically globally. Depending on the route, file type, application logic, CDN rule, reverse proxy or server configuration, headers can be set differently on different URLs. This is exactly why the check is worthwhile not only on the start page, but also on important page types.
Are security headers only relevant for large websites?
No. Smaller websites also benefit from clean security headers. Especially standard setups in CMS, shops or frameworks often provide gaps, outdated defaults or inconsistent configurations.
When is a Security Header Checker particularly useful?
The tool is particularly useful after relaunches, server changes, CDN or proxy changes, framework updates or security hardening measures. Also in the case of technical audits, customer projects or QA processes, a quick check helps to make missing or contradictory headers visible.
When is a Security Header Checker no longer sufficient?
A security header checker is ideal for the quick technical classification of individual URLs. However, if CSP rules have to be fine-tuned in detail, security issues have to be systematically assessed or different header configurations have to be cleaned up across applications, proxy, CDNs and servers, a single tool is often no longer enough. Then a more in-depth technical analysis makes sense.
Appropriate Next Checks
Security headers should not be viewed in isolation. Depending on the findings, it is often worth looking at response headers, HTTPS setup, host consistency or status codes.
Security header from warning list to actionable hardening plan
Missing headers are often easy to spot, but not always easy to fix cleanly. HSTS, CSP, X-frame options, referrer policy and permissions policy depend on whether headers are set in the web server, CDN, reverse proxy, framework or CMS. The check helps to check the visible configuration and sort the next technical steps cleanly.
A content security policy should control scripts, styles, images, and external services without damaging tracking, checkout, or forms.
HSTS only belongs on stable HTTPS setups with tested subdomains, certificates and redirects.
X-Frame Options and Referrer Policy reduce typical browser risks and should be set to match the website function.
When the app, CDN and server send different headers, duplicate, missing or conflicting rules arise.
Introducing a content security policy step by step
Practical example · for illustration
Starting position
Check a page with external fonts and a payment widget.
Classify the findings
A missing CSP header is a configuration hint; an overly strict policy can block legitimate resources.
Specific amendment
Capture required sources and first test an adapted policy in a controlled manner, if necessary in report-only mode.
Control and border
Check browser console and central functions, then retrieve headers again. A header check proves neither complete security nor better rankings.