Website Security

Security Headers Checker

Reads your response headers and grades the eight security headers that harden browsers against downgrade, clickjacking, and injection.

Scan your site for this →

What is Security Headers Checker?

HTTP security headers are instructions your server sends with every response that tell the browser how to behave safely — enforce HTTPS, block your site from being framed, restrict what scripts can run. They're one of the cheapest, highest-leverage defenses on the web: a few lines of server config that harden every visitor's browser against whole classes of attack. The catch is they're opt-in, so a site that never sets them silently ships with those protections off.

What Nandix checks

  • Strict-Transport-Security (HSTS) — presence, max-age ≥ 1 year, includeSubDomains
  • Content-Security-Policy (CSP)
  • X-Frame-Options
  • X-Content-Type-Options
  • Referrer-Policy
  • Permissions-Policy
  • X-XSS-Protection
  • Cache-Control

Probes

8 checks

How it detects

Passive. A single request is issued and each header is evaluated for presence and directive strength (for example, HSTS is only a full pass with a max-age of at least one year and includeSubDomains). Missing or weak directives become findings; no payloads are sent.

Why it's dangerous

Missing headers don't break your site, which is exactly why they get overlooked — the damage only shows up when someone's attacked. Without Strict-Transport-Security, a user on public WiFi can be silently downgraded to HTTP and have their session hijacked. Without X-Frame-Options or a frame-ancestors CSP, your site can be invisibly embedded and used for clickjacking. Without Content-Security-Policy, a single injected script runs with full access to your page. Each missing header is a door left unlocked.

Example finding

HSTS missingHIGH

No Strict-Transport-Security header — visitors can be downgraded from HTTPS to HTTP by a network attacker, exposing session cookies.

How to fix it

Set the headers at your edge — server, reverse proxy, or CDN — so they apply everywhere at once. Strict-Transport-Security: max-age=31536000; includeSubDomains — force HTTPS for a year. Content-Security-Policy — allowlist the sources scripts, styles, and frames may load from; start in report-only mode to avoid breaking things. X-Frame-Options: DENY (or a frame-ancestors CSP) — stop framing/clickjacking. Add X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a restrictive Permissions-Policy.

js

// Next.js — next.config.js
const securityHeaders = [
  { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];
module.exports = {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }];
  },
};

Severities & standards

Severities

HIGH · MEDIUM · LOW

References

Frequently asked questions

Which security header matters most?

Strict-Transport-Security (HSTS) and a solid Content-Security-Policy give the most protection. HSTS is a one-line quick win; CSP takes more tuning but stops injected scripts.

Will adding these headers break my site?

HSTS and X-Frame-Options rarely cause issues. CSP can block legitimate scripts if set too strictly — deploy it in Content-Security-Policy-Report-Only mode first, watch the reports, then enforce.

Where should I set security headers?

At the highest shared layer you control — CDN or reverse proxy is ideal, so every response is covered regardless of which app served it.

See how every check runs on the methodology page, or browse all scanners.

Scan your site for this →

Free security headers scanner. Nandix checks HSTS, CSP, X-Frame-Options and 5 more headers that protect your users from clickjacking, downgrade, and injection attacks.