LaunchTrust
Log inStart trial

Detector registry

Security Headers Checker: Spot Missing HTTP Protections

Run a security headers checker on your own site to spot missing CSP, X-Frame-Options, and more before you ship. See detected vs not-detected signals.

Updated 2026-06-19security headers checkerSignals, not a verdict
Run free scanStart trial

HTTP response headers are quiet but powerful. A handful of them tell the browser how to defend your users against clickjacking, content sniffing, and leaky referrers. They cost nothing to add, yet many freshly shipped sites and web apps go live without them because the framework default simply does not set them. If you are a solo developer or store owner about to launch, a quick security headers checker tells you which protections are present on your own pages and which are silently absent.

LaunchTrust runs a passive security headers check against a page you own and reports what it sees as plain signals: detected, not detected, or unable to determine. It does not rate or grade your security posture, and it does not promise your site is safe. It surfaces missing headers so you can decide what to do before launch day.

What LaunchTrust checks

This detector is fully passive. It reads the HTTP response headers your server already returned for the page — it does not send extra probes, run scripts, or fetch your bundles. It looks for four core protections that browsers act on:

  • Content-Security-Policy (CSP) — restricts where scripts, styles, and other resources can load from, the primary defense against cross-site scripting (XSS) and injection.
  • X-Frame-Options (or an equivalent frame-ancestors directive inside your CSP) — stops other sites from embedding your pages in a hidden frame for clickjacking. The check treats a CSP frame-ancestors directive as satisfying this protection, so a modern CSP-only setup is not penalized.
  • X-Content-Type-Options — set to nosniff, this prevents the browser from guessing (and mis-executing) a response's content type.
  • Referrer-Policy — controls how much URL information leaks to other sites when a user clicks a link.

How to read the result:

  • Detected — all four core protections are present. This is a positive signal: it is something you want to see.
  • Not detected — at least one of the four is missing, and the signal names which ones. If Content-Security-Policy is among them, the result is weighted higher (medium) because CSP carries the most defensive weight; otherwise it is flagged at a lower level.
  • Unable to determine — the page could not be fetched, so its headers could not be read.

The output is a signal about what the headers contain, not a judgment of whether your overall security is correct. A page can have all four headers and still have weak policies; the checker reports presence, not the strength of each policy's value.

Why it matters

Security headers map directly to the OWASP Secure Headers Project, a widely referenced baseline in application security. Missing headers are among the most common findings in routine web security reviews precisely because they are easy to overlook and easy to fix.

For app and extension submissions, reviewers increasingly expect basic web hardening on any companion site, dashboard, or backend you operate. For e-commerce and SaaS sites, missing clickjacking and content-type protections are frequent flags in penetration tests and vendor security questionnaires. None of these is a single legal statute you can cite — they are commonly expected good practice in cybersecurity, and shipping without them invites avoidable risk and follow-up questions. This is about reducing exposure and rejection risk, not earning a certificate.

A concrete example

A response that satisfies this detector looks like this (values shortened):

content-security-policy: default-src 'self'; frame-ancestors 'none'
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin

Here, frame-ancestors 'none' inside the CSP covers the clickjacking protection, so a separate X-Frame-Options header is not required for the check to read it as present. A bare response returning only content-type and cache-control would instead read "not detected" and name all four missing headers — weighted medium because CSP is absent.

How to address it

  1. Decide where to set headers. Headers are usually added at your edge (Cloudflare, Vercel, Netlify), your reverse proxy (Nginx, Caddy), or in application middleware. Pick one layer and apply consistently so you do not set conflicting values.
  2. Add X-Content-Type-Options: nosniff. This is the safest quick win — it has essentially no compatibility downside.
  3. Add a Referrer-Policy. strict-origin-when-cross-origin is a sensible, broadly compatible default.
  4. Add clickjacking protection. Either send X-Frame-Options: DENY (or SAMEORIGIN if you embed your own pages) or include frame-ancestors 'none' / frame-ancestors 'self' in your CSP.
  5. Introduce a Content-Security-Policy carefully. CSP is the highest-value header and the easiest to break a working site with. Start in Content-Security-Policy-Report-Only mode, watch for violations, tighten the directives, then switch to enforcing mode.
  6. Re-scan after deploy. Confirm the headers appear on the live response, not just in local config, since edge platforms sometimes strip or override headers.

Check this in 30 seconds

Paste your own site or web app URL into the free LaunchTrust scanner. It reads your live response headers passively and tells you which of the four core protections are detected and which are not, with the missing ones named so you know exactly what to add. No account, no crawl of pages you do not own — just a fast read of the surface a browser already sees.

FAQ

Does running this checker make my app pass review or secure? No. It surfaces signals about which security headers are present on a page you own. It is not legal advice, not a security certification, and not a guarantee that your app is safe or will be approved. Use it to find gaps, then verify and fix them.

My site works fine without these headers — do I still need them? A site can function perfectly while still being exposed to clickjacking, content sniffing, or referrer leakage. These headers add defenses the browser enforces; their absence is a common finding in security reviews even on sites that otherwise work.

Will adding a Content-Security-Policy break my site? It can if introduced too strictly, since CSP is the most likely header to block legitimate scripts. Start in report-only mode, review what would be blocked, and tighten gradually before enforcing.

Does "detected" mean my headers are configured well? Not necessarily. The check reports that the four core headers are present; it does not evaluate whether each policy's value is strong. A weak CSP still counts as present, so treat "detected" as "the protections exist," then review the actual values yourself.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.