FREE TOOL

Security Headers Checker

Inspect the HTTP security headers a website sends and which browser protections are in place.

Headers checked

  • Strict-Transport-Security (HSTS)
  • Content-Security-Policy (CSP)
  • X-Content-Type-Options
  • X-Frame-Options
  • Referrer-Policy
  • Permissions-Policy

What HTTP security headers do

When your browser requests a web page, the server responds with the page content plus a set of HTTP response headers. Some of those headers tell the browser how to handle the content safely. These are called security headers.

Security headers are instructions, not enforcement. They don't make a site secure by themselves, but they define how the browser should behave in specific situations — and having the right ones in place closes off entire classes of common attacks.

The six headers this tool checks

Strict-Transport-Security (HSTS)

HSTS tells the browser to only ever access this domain over HTTPS, even if a user types http:// or clicks an old HTTP link. It prevents downgrade attacks and cookie hijacking on public Wi-Fi networks. A well-configured HSTS header includes max-age=31536000 (one year) and, increasingly, the preload directive so that browsers know about it before the first visit.

Content-Security-Policy (CSP)

CSP restricts which sources the browser is allowed to load scripts, styles, images, fonts, and frames from. A strong CSP blocks most cross-site scripting (XSS) attacks, which are among the most common web vulnerabilities. CSP is the most complex of the six headers — a misconfigured one can break legitimate site functionality, so sites often start in "report-only" mode before enforcing.

X-Content-Type-Options

This header prevents the browser from "sniffing" a file's type and executing it as something else. Should almost always be set to nosniff. Without it, a file that a site intended as a harmless text file could be interpreted as a script if the browser guesses wrong.

X-Frame-Options

Controls whether the page can be embedded in an <iframe> on another site. Prevents clickjacking — the technique where an attacker overlays invisible buttons to trick users into clicking things they didn't intend (like confirming a bank transfer). Common values: DENY (never allow framing) or SAMEORIGIN (allow framing only from the same domain).

Referrer-Policy

Controls how much referrer information the browser sends when a user clicks a link away from the page. This protects privacy and prevents leaking sensitive URLs (e.g., a password-reset URL that contains a token) to third parties. Common values: strict-origin-when-cross-origin (a good modern default) or no-referrer (send nothing).

Permissions-Policy

Limits which browser features the page (and any embedded third-party scripts) can request — camera, microphone, geolocation, payment APIs, and so on. Setting Permissions-Policy: camera=(), microphone=(), geolocation=() on a page that doesn't need those features removes an entire class of potential abuse.

What missing headers actually mean

Missing headers do not mean a site is malicious. In practice, missing headers usually mean one of:

  • The site was built before these headers became standard practice
  • The hosting stack or CMS doesn't set them by default
  • The site is on an older platform where adding them requires manual configuration
  • The site owner isn't aware of them

Conversely, having all six headers does not prove a site is safe. A phishing site can be well-configured — headers only describe the browser's behavior, not the intent of the operator.

Reading the results

Detected (green)
The server sends that header in its response. The header is present and the browser will honor it.
Not detected (amber)
The server does not send that header, or sends it only on certain pages (many sites set different headers on different routes).

A site with 5 or 6 detected is usually one that cares about security posture — often a modern SaaS platform, an established business, or an infrastructure provider. A site with 0 detected is not automatically untrustworthy; it may simply be an older site, a small static site, or a site that relies on other protections.

Why this is a trust signal, not a verdict

Security headers are one observable signal among many. Used alone, they can mislead in both directions. Use them as:

  • A positive signal when they're present and well-configured
  • A weak negative signal when they're absent and the site handles sensitive data
  • Never a reason to trust or distrust a site on their own

Combine this check with what you see on the site itself — content quality, contact details, policy pages, and independent reputation — before making a decision.

Limitations

This tool reports observable signals only. It is not a security audit, a business verification, or proof of fraud. Always verify independently.

← Back to all Verigrity tools