Security Headers Analyzer

Inspect HTTP response headers to ensure your web server is instructing browsers to protect users from XSS, clickjacking, and packet sniffing.

Crucial Security Headers

When a browser visits a web page, the server sends hidden "headers" before the HTML content. These headers act as strict rules the browser must follow.

Strict-Transport-Security (HSTS): Forces the browser to always use HTTPS for this site, even if the user types http://.
X-Frame-Options: Prevents other sites from embedding your page in an <iframe>, stopping "Clickjacking" attacks.
X-Content-Type-Options (nosniff): Prevents the browser from trying to guess the file type, stopping malicious script execution hidden inside images or text files.
Content-Security-Policy (CSP): An advanced whitelist of exactly which domains are allowed to load scripts, images, or styles on your site. The ultimate defense against XSS (Cross-Site Scripting).

Our Security Headers Checker fetches your site and inspects every HTTP response header that affects browser security — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy — then explains what each missing header exposes you to.

What Are HTTP Security Headers?

HTTP security headers are instructions your server sends alongside every page telling the browser how to treat your content. They are enforced by the browser itself, which makes them a genuinely defensive layer rather than an advisory one.

The most important are Strict-Transport-Security, which forces HTTPS; Content-Security-Policy, which controls which scripts and resources may load; X-Frame-Options, which prevents your pages being embedded in a hostile frame; and X-Content-Type-Options, which stops the browser guessing at content types.

They are cheap to deploy — most are a single line of server configuration — and they mitigate entire classes of attack, including cross-site scripting, clickjacking and protocol downgrade.

Response headers that instruct the browser how to handle your content
Enforced by the browser, so they work regardless of application code
Mitigate XSS, clickjacking, MIME sniffing and downgrade attacks
Usually a one-line server configuration change
Checked by most security scanners and compliance frameworks

Why Security Headers Matter

Security headers are defence in depth for the failures you have not found yet. A Content-Security-Policy does not fix a cross-site scripting vulnerability, but it can stop the injected script from executing or from sending stolen data anywhere useful. HSTS does not fix a mixed-content bug, but it prevents the downgrade attack that would exploit it.

They are also among the very few controls that apply uniformly across an entire site with no code changes. For an application with years of accumulated legacy pages, headers protect every one of them at once.

Limit the damage of vulnerabilities you have not yet discovered
Apply site-wide without touching application code
HSTS prevents SSL stripping and protocol downgrade attacks
CSP is the most effective mitigation available for cross-site scripting
Their absence is flagged in essentially every security audit

How This Security Headers Checker Works

The tool makes an HTTP request to your site and analyses the response headers it receives.

Validates the URL input against format and SSRF safety checks
Issues an HTTP request and captures the full response headers
Checks for each recommended security header in turn
Evaluates the value of each header, not merely its presence
Reports missing headers and weak configurations with specific fixes

How to Use the Security Headers Checker

Enter your site URL in the input field
Run the scan to fetch and analyse the response headers
Review which recommended headers are missing
Check the value of the headers that are present, since a weak value is close to no header
Apply the suggested configuration and re-scan to confirm

Understanding Your Security Headers Results

Each header addresses a specific attack class. Here is what they do:

Field / Value	Meaning
`Strict-Transport-Security`	Forces browsers to use HTTPS for all future requests to your domain. A good value is max-age=31536000; includeSubDomains. It prevents SSL stripping attacks on return visits.
`Content-Security-Policy`	Controls which sources may load scripts, styles, images and frames. The most powerful header available and the hardest to deploy, since a strict policy usually requires application changes.
`X-Frame-Options`	Prevents your pages being embedded in a frame on another site, blocking clickjacking. DENY or SAMEORIGIN. Superseded by the CSP frame-ancestors directive but still worth sending for older browsers.
`X-Content-Type-Options`	The single value nosniff stops browsers guessing a content type different from the one you declared, which prevents a class of attacks where an upload is interpreted as script.
`Referrer-Policy`	Controls how much URL information is sent when a user follows a link away from your site. strict-origin-when-cross-origin is a sensible default that avoids leaking paths and query strings.
`Permissions-Policy`	Declares which browser features — camera, microphone, geolocation — your site and its embedded frames may use. Disable everything you do not need.

Common Problems & How to Fix Them

Without HSTS, a visitor typing your domain without a scheme makes an initial plaintext request that an attacker on the network can intercept and redirect.

Add the header to your HTTPS responses:
Strict-Transport-Security: max-age=31536000; includeSubDomains

Start with a shorter max-age such as 300 while you confirm every subdomain works over HTTPS, then raise it. Be careful with includeSubDomains — it applies to every subdomain immediately, and it cannot be undone quickly because browsers cache the directive.

Any successful script injection runs with full access to your page and can exfiltrate data anywhere.

Deploy CSP in report-only mode first so nothing breaks:
Content-Security-Policy-Report-Only: default-src self; report-uri /csp-report

Collect violations for a few weeks, refine the policy until it is clean, then switch to enforcing mode. Avoid unsafe-inline and unsafe-eval, which remove most of the protection CSP offers.

The unsafe-inline keyword permits inline scripts, which is exactly what most XSS payloads are. Its presence removes the majority of the benefit.

Move inline scripts into external files, or adopt a nonce or hash based policy where each permitted inline block carries a per-request nonce. This usually requires application changes, which is why it is the step most deployments stop short of.

Browsers may ignore your declared Content-Type and infer their own, which can turn a user-uploaded file into executable script.

Add the header with its only valid value:
X-Content-Type-Options: nosniff

There is no downside and no configuration to tune.

Server and X-Powered-By headers revealing exact software versions give an attacker a precise target to match against known vulnerabilities.

In nginx set server_tokens off. In Apache set ServerTokens Prod and ServerSignature Off. In PHP set expose_php = Off. This is obscurity rather than security, but it removes free reconnaissance.

Best Practices

Deploy HSTS with a long max-age once every subdomain works over HTTPS
Roll out CSP in report-only mode before enforcing it
Send X-Content-Type-Options: nosniff on every response
Use CSP frame-ancestors alongside X-Frame-Options
Set Referrer-Policy to strict-origin-when-cross-origin or tighter
Disable unused browser features through Permissions-Policy
Suppress version information in Server and X-Powered-By headers
Re-scan after every deployment, since headers are easily lost in configuration changes

Security Recommendations

Avoid unsafe-inline and unsafe-eval in CSP, since they negate most of its protection
Test HSTS includeSubDomains carefully — every subdomain must serve valid HTTPS, and browsers cache the directive for the full max-age
Consider HSTS preloading only when you are certain, because removal from the preload list takes months
Set security headers at the edge or reverse proxy so they cannot be omitted by an individual application
Collect and review CSP violation reports, as they reveal both misconfiguration and genuine injection attempts
Remember headers are defence in depth, not a substitute for input validation and output encoding

Frequently Asked Questions

Strict-Transport-Security and Content-Security-Policy provide the most protection. X-Content-Type-Options and X-Frame-Options are trivial to add and eliminate specific attack classes. Referrer-Policy and Permissions-Policy are valuable refinements.

It instructs browsers to use HTTPS for all future requests to your domain for the duration of max-age. This prevents SSL stripping, where an attacker intercepts an initial plaintext request and keeps the connection unencrypted.

A strict policy forbids inline scripts and styles, which most existing sites rely on heavily. Getting real benefit usually means refactoring application code to use external files or per-request nonces. Report-only mode lets you measure the work before committing to it.

The CSP frame-ancestors directive supersedes it and takes precedence in browsers that support both. Sending X-Frame-Options as well costs nothing and covers older clients, so the usual advice is to send both.

Yes. An overly strict CSP will block legitimate scripts and styles, and HSTS with includeSubDomains will break any subdomain not serving valid HTTPS. Both should be rolled out gradually — CSP in report-only mode, HSTS with a short max-age first.

At the reverse proxy, load balancer or CDN, so they apply uniformly and cannot be accidentally omitted by an individual application or route. Setting them in application code alone risks inconsistency across endpoints.

Only with certainty. Preloading embeds your domain in browser binaries so HTTPS is enforced even on a first visit, but removal takes months to propagate. Every subdomain must serve valid HTTPS indefinitely before you submit.