verified_user Technical SEO

Security Headers Checker

Check any URL for the security headers that protect visitors, including HSTS and CSP.

Enter a URL and get a score and an A to F grade for the security settings your server sends to browsers. Eight checks: HTTPS, HSTS (forces secure connections), Content-Security-Policy, X-Content-Type-Options, clickjacking protection, Referrer-Policy, Permissions-Policy, and whether X-Powered-By is hidden.

build_circle Try the free tool
list On this page expand_more
star

Key takeaways

  • check_circle Security headers are inexpensive server settings that protect visitors from clickjacking, content sniffing, and downgrade attacks without changing page content.
  • check_circle This checker scores eight equal checks, so read each result rather than relying on the letter grade alone.
  • check_circle Enable HSTS only after the whole site works over HTTPS, and be cautious with preload because it is hard to undo.
  • check_circle Introduce Content-Security-Policy in report-only mode, review violations, then enforce it.
  • check_circle A pass means a header is present with an acceptable value, not that the policy is strong.
  • check_circle Headers can differ by page, subdomain, and CDN rule, so test your homepage and key templates after every infrastructure change.
  • check_circle The tool reads headers from one page only and is not a vulnerability scan.
verified_user

What is Security Headers Checker?

HTTP security headers are instructions a web server sends with each page that tell browsers how to behave when handling it. They can require encrypted connections, limit which sources may run scripts, prevent files from being reinterpreted as another type, stop other sites from embedding your pages in hidden frames, and control how much of your URL is shared when someone clicks a link.

The HeyLead Security Headers Checker fetches a URL you enter, follows redirects, and reads the headers of the final response. It runs eight checks: HTTPS, Strict-Transport-Security with a max-age of at least six months, Content-Security-Policy, X-Content-Type-Options set to nosniff, clickjacking protection through X-Frame-Options or frame-ancestors, Referrer-Policy, Permissions-Policy, and the absence of an X-Powered-By header. You receive a letter grade, a score out of 100, the number of checks passed, and a list of the headers found with their values.

The checker is a hygiene tool, not a security audit. It confirms that basic protections are present on one page, and it explains what to add for each failure. It cannot judge how strict a policy is, does not test for vulnerabilities, and cannot see pages behind a login. Use it before launch, after a hosting or CDN change, and during vendor reviews. Headers rarely affect rankings directly, but a site that handles them properly is easier to trust, and to defend, than one that ignores them.

insights

Why security headers matter

Many attacks on websites are automated and opportunistic. Security headers close common gaps at almost no cost: they push browsers to use HTTPS, restrict what can run on a page, and reduce what leaks to third parties. They are also easy for customers, auditors, and procurement teams to check, so missing basics can cost trust. Fixing them early is much cheaper than explaining a gap later.

arrow_forward Protects visitors from clickjacking, content sniffing, and downgrade attacks.
arrow_forward Reduces the impact of injected scripts when a Content-Security-Policy is in place.
arrow_forward Answers common questions in vendor security reviews and client due diligence.
arrow_forward Takes minutes to fix at the server or CDN level and persists across content changes.
play_circle

How to use this tool

  1. 1

    Enter a URL

    Use your homepage or a key template.

  2. 2

    Read the score

    See which headers are present and which are missing.

  3. 3

    Add missing headers

    Set them at your server, CDN, or hosting layer and re-check.

fact_check

What this tool checks

verified

HTTPS in use

Checks whether the final URL after redirects uses HTTPS. An http starting address that lands on https passes. A site that stays on plain HTTP fails.

verified

Strict-Transport-Security

Looks for the HSTS header and reads its max-age value. It passes when max-age is at least 15552000 seconds, about six months, and fails when the header is missing or shorter.

verified

Content-Security-Policy

Passes when a Content-Security-Policy header is present. A report-only policy is noted separately but does not pass, and the tool does not judge how strict the policy is.

verified

X-Content-Type-Options

Passes only when the header value is nosniff, which stops browsers from guessing a file's type and running scripts disguised as images or text. It is safe to add everywhere.

verified

Clickjacking protection

Passes if X-Frame-Options is set or the Content-Security-Policy includes a frame-ancestors directive, either of which controls whether other sites can embed your page in a frame.

verified

Referrer, permissions, and disclosure

Three further checks: Referrer-Policy present, Permissions-Policy present, and no X-Powered-By header exposing software details. All eight checks count equally toward the score and letter grade.

engineering

Technical guide

Signals, standards, and what to fix when checks fail.

code

What the checker requests and reads

The checker fetches the URL you enter from a server, follows redirects, and reads the response headers of the final page. It evaluates eight checks: HTTPS, HSTS, CSP, X-Content-Type-Options, clickjacking protection, Referrer-Policy, Permissions-Policy, and absence of X-Powered-By. The results show a grade, a score out of 100, and how many checks passed, followed by a preview listing each security header and its value, cut to 160 characters. Only one page is examined, so a CDN rule or template that sets headers differently elsewhere on the site will not be visible here.
code

How the score and grade are calculated

Each of the eight checks is worth the same amount. The score is the share of checks passed, rounded to a percentage. A score of 90 or more earns an A, 75 or more a B, 60 or more a C, 40 or more a D, and anything lower an F. With eight equal checks, seven passes gives 88, which is a B, and only all eight gives an A. Because the weighting is equal, a minimal CSP counts the same as a well-tuned one, so read the individual results, not just the grade.
code

What passing does and does not prove

A pass means the header exists with an acceptable value. It does not mean the policy is strong. The CSP check does not analyze directives, so a policy that allows unsafe inline scripts still passes. HSTS is judged by max-age only, not by includeSubDomains or preload. X-Frame-Options passes with any value present. These are presence checks meant to catch missing basics. For a real security review, inspect the actual policy text, test with browser developer tools, and use a dedicated scanner or a penetration test. Treat the tool as a first pass.
code

Where to set headers and how to verify

Headers can be set at the web server (Apache, Nginx, IIS), at a CDN or edge layer such as Cloudflare rules, in application middleware, or through your hosting control panel. Managed WordPress and shared hosts often expose them through a plugin, an .htaccess file, or a settings page. Set each header on all HTML responses, then re-run the checker on your homepage and a key template. If a CDN sits in front, confirm the header survives caching. Keep the change in version control so a deployment does not quietly remove it.
school

Deep dive

lock

HTTPS and HSTS: forcing secure connections

HTTPS encrypts traffic between visitor and server, but a visitor who types your domain without a scheme may still reach an HTTP version first. HSTS closes that gap. After a browser sees the Strict-Transport-Security header over HTTPS, it refuses to use HTTP for your domain until max-age expires. This checker asks for a max-age of at least 15552000 seconds, about six months. Before enabling it, confirm that every page, image, script, and subdomain you serve loads over HTTPS, because HSTS turns any remaining insecure resource into a hard failure. Start with a short max-age, raise it as you gain confidence, and treat includeSubDomains and preload as separate decisions. Preload submits your domain to a list browsers ship, and removal can take a long time.

Audit before enabling

Crawl the site for HTTP references, including old images, embeds, and legacy subdomains, and fix them so nothing breaks once HTTPS becomes mandatory. Include staging hosts that share the domain.

Raise max-age in steps

Begin with a day or a week, then raise it to six months or a year after monitoring real traffic for problems. Mixed content warnings in the browser console are the early signal to watch.

Treat preload as permanent

Only request preload when every subdomain, now and in the future, will support HTTPS. Reversing the decision is slow, so document who approved it and why before submitting. A one-year max-age is a sensible interim setting.

security

Content-Security-Policy without breaking the site

A Content-Security-Policy tells the browser which origins may supply scripts, styles, images, fonts, frames, and other resources. Its main value is limiting damage from injected code: even if an attacker inserts a script tag, the browser refuses to run it from an unlisted source. The difficulty is that modern sites load resources from many places, including analytics, tag managers, chat widgets, fonts, and payment providers. A policy written without an inventory will block something important. The safe path is report-only mode: publish Content-Security-Policy-Report-Only, collect violations, add legitimate sources, remove inline code where you can, and then enforce. This checker counts only an enforced policy as a pass and mentions when a report-only one is found, but it does not grade the strictness of the directives.

Inventory your sources

List every third-party script, style, font, image, and frame the site loads, including those added by tag managers and plugins. Payment and chat providers are the ones most often forgotten.

Use report-only first

Collect violation reports for at least a full business cycle, covering checkout, forms, and rarely visited templates, before switching to enforcement. Monitor the report endpoint so it does not fill silently.

Tighten over time

Replace broad allowances such as unsafe-inline with nonces or hashes as your team is able, and review the policy after any new script is added. Quarterly reviews are a reasonable rhythm.

rule

Framing, sniffing, referrer, and permissions

Four smaller headers cover most remaining basics. X-Content-Type-Options with the value nosniff stops browsers from guessing a file's type, which prevents a file served as text or an image from being executed as script. Clickjacking protection, through X-Frame-Options or the frame-ancestors directive of CSP, stops other sites from embedding your pages in hidden frames. Referrer-Policy limits how much of your URL is sent to other sites, and strict-origin-when-cross-origin is a common default that balances analytics needs with privacy. Permissions-Policy lets you switch off browser features you do not use, such as camera, microphone, and geolocation. This checker requires nosniff exactly, accepts either framing control, and checks that the referrer and permissions headers are present without evaluating their contents.

Pick a framing rule

Use SAMEORIGIN or frame-ancestors 'self' unless you deliberately allow embedding, for example for a partner widget or a payments frame. List any allowed partners explicitly instead of using wildcards.

Balance referrer and analytics

Strict referrer settings limit data sent to other sites but can reduce visible referral detail in partner reports, so test how your analytics and affiliate tools behave after any change.

Disable unused features

List the browser features your site needs and switch off the rest in Permissions-Policy, especially where third-party embeds run. Camera, microphone, and geolocation are the usual candidates to disable. Retest embeds afterward.

terminal

Deploying headers and keeping them in place

Where you set headers depends on your stack. Server configuration in Apache, Nginx, or IIS applies them to every response, a CDN or edge rule applies them before content reaches visitors, and application middleware or a plugin lets developers manage them in code. Pick one source of truth, because duplicate headers from a plugin and the server can conflict or double up. After deploying, retest with this checker on the homepage and a few key templates, and check that cached responses carry the same headers. Then guard against regressions: keep header configuration in version control, note it in launch checklists, and re-run the check after CMS upgrades, host moves, and CDN changes. Businesses in the US, UK, Australia, and Singapore commonly face security questionnaires from larger clients, and a documented header baseline helps answer them.

One source of truth

Decide whether the server, CDN, or application owns each header and remove duplicates elsewhere to avoid conflicting values. Note the decision in your runbook so future changes go to the right place.

Test more than the homepage

Check checkout, login, blog, and landing page templates, since different routes or subdomains can return different headers. Redirects between HTTP and HTTPS versions are also worth testing.

Add checks to releases

Include a header check in your launch and post-migration checklists so a platform change does not silently remove protections. Save the results with the release notes for later comparison.

compare

Examples

thumb_up Strong examples

HSTS with long max-age

Strict-Transport-Security: max-age=31536000; includeSubDomains

A one-year max-age tells browsers to use HTTPS only, and includeSubDomains extends that to subdomains once you are certain every one supports HTTPS. Increase it only after testing.

Report-only CSP rollout

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

It logs what a strict policy would block without breaking the site, giving you evidence to tune the policy before enforcing it. Keep the report endpoint monitored.

Content type protection

X-Content-Type-Options: nosniff

A single safe line that stops browsers guessing file types. Combined with referrer and framing controls, it covers most of the basic gaps at no cost.

thumb_down Weak examples

Version disclosure

X-Powered-By: PHP/8.1.2

It advertises the technology and exact version in use, which helps attackers find matching known vulnerabilities, and it serves no purpose for visitors. Remove it at the server or app level.

Short HSTS lifetime

Strict-Transport-Security: max-age=300

Five minutes is too short to protect returning visitors, and this checker fails HSTS below six months, so the header gives little real value. Use at least six months once stable.

Blindly copied strict CSP

Content-Security-Policy: default-src 'none'

Pasted without testing, it blocks scripts, styles, images, and fonts, which can break the site entirely and pressure teams into removing the header. Test each directive before you enforce.

rule

Best practices and common mistakes

check_circle Best practices

  • done Enable HSTS only after every page and subdomain you serve works correctly over HTTPS.
  • done Roll out Content-Security-Policy in report-only mode first, then enforce it after reviewing reports.
  • done Send X-Content-Type-Options: nosniff on every response, since it is safe and cheap to add.
  • done Use frame-ancestors in your CSP for clickjacking control, with X-Frame-Options as a fallback.
  • done Set a Referrer-Policy such as strict-origin-when-cross-origin to limit URL data sent to other sites.
  • done Remove X-Powered-By and other version headers, and re-check after every server or CDN change.

cancel Common mistakes

  • close Copying a strict Content-Security-Policy into production without testing, because it can break scripts, fonts, and embeds.
  • close Enabling HSTS preload before you are certain every subdomain supports HTTPS.
  • close Treating a high grade as proof the site is secure, since this checks headers only.
  • close Setting headers on the homepage only and leaving other templates or subdomains unprotected.
  • close Adding overlapping or conflicting headers from both plugin and server, which makes results unpredictable.
lightbulb

Common use cases

task_alt

Running a pre-launch security hygiene check on a new site or staging environment.

task_alt

Confirming that a CDN, host, or platform migration kept your headers intact.

task_alt

Supporting client due diligence and vendor security questionnaires.

task_alt

Checking a competitor or partner site to compare baseline practices.

task_alt

Verifying a fix after a penetration test recommended missing headers.

groups

Who should use this

person Developers and DevOps engineers hardening web servers. person Site owners and marketers who want a plain-language security check. person Agencies auditing client sites before launch or migration. person IT and security teams performing quick vendor checks. person Ecommerce managers protecting checkout and account pages.
dictionary

Glossary

HSTS
HTTP Strict Transport Security: a header instructing browsers to load a site only over HTTPS for a specified time.
CSP
Content-Security-Policy: a header that lists which sources of scripts, styles, images, and frames a page may load.
Clickjacking
An attack that hides your page inside a frame on another site so visitors unknowingly click your buttons.
MIME sniffing
Browser behavior of guessing a file's type from its content, which the nosniff value of X-Content-Type-Options disables.
frame-ancestors
A CSP directive that specifies which sites may embed your page in a frame, replacing the older X-Frame-Options header.
Referrer-Policy
A header controlling how much of the current page's URL is sent to other sites when a visitor follows a link.
Permissions-Policy
A header that enables or disables browser features, such as camera, microphone, and geolocation, for your page and embedded frames.
HSTS preload
A list of domains built into browsers that always use HTTPS. Joining requires strict settings and is difficult to reverse.
quiz

Frequently asked questions

Ready for a deeper audit?

HeyLead reviews your site, competitors, and growth opportunities with no sales pressure.

Get a Free Audit arrow_forward