← All tools

HTTP Security Headers Checker

Inspect any public URL for missing or misconfigured security headers. Get severity-ranked issues with copyable fix snippets for Nginx, Apache, and Cloudflare.

Enter a public URL. We fetch its response headers and analyze them against OWASP best practices.

What Are HTTP Security Headers?

HTTP security headers are response headers your web server sends along with every page. They tell the browser how to behave: what content to trust, what to block, when to enforce HTTPS, and whether the page can be embedded by other sites. Used correctly, they form a critical layer of defense against the most common web attacks: cross-site scripting (XSS), clickjacking, MIME-sniffing exploits, downgrade attacks, and information leakage.

The catch: these headers are opt-in. Without explicit configuration, modern browsers default to permissive behavior for backward compatibility. A site with no security headers is functionally equivalent to a site from 2005. It works, but it leaves doors open that attackers know exactly how to push through.

Why Your Site Needs Them

Three reasons, in order of importance:

  1. Real attacks. XSS and clickjacking are not theoretical. They're consistently in the OWASP Top 10. A properly configured Content-Security-Policy alone would have blocked the majority of XSS exploits in the last decade.
  2. Compliance and trust. Security audits, bug bounty programs, and enterprise customers expect a security-headers grade of A or better. Without it, you fail vendor questionnaires.
  3. SEO and reputation. Google's algorithm doesn't directly rank by security headers, but search engines do prefer secure, modern sites. Browsers also display warnings for sites missing HSTS on .dev, .app, and similar HTTPS-required TLDs.

The Headers We Check

Strict-Transport-Security (HSTS)

Forces browsers to use HTTPS for every connection to your domain, even if a user typeshttp:// or clicks an old HTTP link. Once a browser sees HSTS, it remembers your site is HTTPS-only for the duration of max-age. This prevents downgrade attacks and cookie hijacking on public Wi-Fi. Required for theHSTS preload list, which bakes your domain into Chrome, Firefox, Safari, and Edge themselves.

Content-Security-Policy (CSP)

The most powerful header on this list. CSP tells the browser exactly which sources of scripts, styles, images, fonts, and other resources are allowed to load. A strict CSP makes XSS attacks effectively impossible. Even if an attacker injects malicious JavaScript into your HTML, the browser refuses to execute it because the source isn't whitelisted. The tradeoff: CSP is the hardest header to deploy because it must accommodate every legitimate resource your site loads. Start withContent-Security-Policy-Report-Only, watch violation reports, then enforce.

X-Frame-Options

Stops other sites from embedding your pages in <iframe> elements. Without it, an attacker can put your login page inside their own page, overlay a fake button, and steal credentials with a single click (clickjacking). Set it toDENY if you never need to be framed; SAMEORIGIN if you frame yourself (e.g., admin dashboards). Modern alternative:frame-ancestors directive inside CSP, which is more granular.

X-Content-Type-Options

A small but important header that blocks MIME-type sniffing. Without it, browsers may treat a file's contents differently from its declared Content-Type. For example, executing a .txt file as JavaScript if the contents look like code. Setting this to nosniff removes that ambiguity. There's no good reason not to enable it.

Referrer-Policy

Controls what URL information the browser sends in the Referer header when users navigate away from your site. The default leaks your full URL (including query strings that might contain session tokens, search terms, or other sensitive context) to every external link target. Use strict-origin-when-cross-origin(modern browser default) or no-referrer for maximum privacy.

Permissions-Policy

Restricts which powerful browser APIs your site (and any third parties loaded by it) can use. Camera, microphone, geolocation, payment, USB, accelerometer: all features that should be off by default for sites that don't need them. Settingcamera=(), microphone=(), geolocation=() blocks both your own code and any embedded scripts from prompting users for these permissions.

Frequently Asked Questions

Do I need to set all six headers?

At minimum: HSTS, X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors), and Referrer-Policy. These cost nothing and break nothing. CSP and Permissions-Policy require more thought because they can block legitimate functionality if misconfigured. Deploy them in report-only mode first.

Will adding these headers break my site?

HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy are safe to deploy with the recommended values. CSP is the only one likely to break things on first deploy, because it enumerates everything your site loads. UseContent-Security-Policy-Report-Only first, monitor violation reports for a week, fix the legitimate ones, then switch to enforcing mode.

What's the difference between X-Frame-Options and CSP frame-ancestors?

X-Frame-Options is older and accepts only three values: DENY,SAMEORIGIN, or ALLOW-FROM (deprecated).frame-ancestors inside CSP supports multiple origins, wildcards, and'none'. If you set both, modern browsers obey frame-ancestorsand ignore X-Frame-Options. Keeping X-Frame-Options is fine as a fallback for older browsers.

Why does HSTS require HTTPS?

HSTS only takes effect over a secure connection. Sending the header over plain HTTP is meaningless, since an attacker could strip it. The browser ignores HSTS on HTTP responses by design. Once a user visits your HTTPS site, the header registers and HTTPS is enforced from then on.

How often should I re-scan my site?

After any deployment that touches your CDN, third-party scripts, or analytics setup. Also after migrating hosting. Nginx config gets lost on server moves more often than you'd expect. Some teams add a security headers scan to their CI pipeline; we'll publish API docs for that workflow in a future release.

Are these headers enough for a secure website?

No. They're one layer. You still need HTTPS with modern TLS, secure cookies (Secure, HttpOnly, SameSite), input validation, output encoding, parameterized queries, dependency updates, and the rest of the OWASP Top 10. Security headers are necessary, not sufficient.

Further Reading