Free Security Headers Checker: Test HTTP Headers & CORS

Why Headers Matter

HTTP security headers are the last line before the browser. A missing X-Frame-Options means your login page can be loaded inside an attacker’s iframe and clickjacked. Missing Strict-Transport-Security means your users’ first visit over plain HTTP can be downgraded and the session cookie sniffed. Permissive CORS means other sites can read your authenticated responses with the user’s cookies attached.

The headers themselves are simple key-value strings - they fix entire vulnerability classes for the cost of one config block. They’re also the cheapest, fastest hardening pass an app will ever get.

For AI-generated apps on Vercel, Netlify, Railway, or Cloudflare Pages, headers are almost always missing on day one. The generator ships a working UI; the host serves it with framework defaults; nobody adds vercel.json / _headers / Helmet until a scanner fails a free check. That is exactly the niche this tool fills.

The Grade Card

Each header gets scored Pass / Warn / Fail with specific guidance:

Header reference table

HSTS details that trip people up

• max-age under 1 day grades poorly - browsers barely remember the policy.
• includeSubDomains without HTTPS on all subdomains bricks HTTP-only internal tools on those hosts. Inventory subdomains first.
• preload means you intend to submit to the HSTS preload list; do not set it until every subdomain is HTTPS-ready.
• HSTS only helps after the first successful HTTPS response. Users who type http:// on first visit still need redirects; the checker assumes you already force HTTPS at the edge.

CSP directives that matter for vibe-coded apps

How attackers find this

Header misconfigurations are trivially scanned. There are public scanner indexes (securityheaders.com, Mozilla Observatory, plus dozens of “security report” SaaS bots) that crawl deployed sites continuously and publish grades. Attackers don’t need to scan you - they just query the index.

For specific exploits:

• Missing HSTS - sslstrip-style downgrades on hostile networks (open Wi-Fi, hotel captive portals). The first request a user makes to yoursite.com is plain HTTP; the attacker rewrites the redirect.
• Missing X-Frame-Options - attacker hosts attacker.com/win-a-prize, embeds yoursite.com/transfer-funds in a transparent iframe over a “click here” button. User clicks button on attacker site, actually clicks the transfer button on your site, with their cookies attached.
• Access-Control-Allow-Origin: * with credentials - when paired with Allow-Credentials: true (browsers reject this combo, but bad servers send * anyway and developers then “fix” it by reflecting the Origin header without validation), any site can read authenticated responses.
• Missing CSP - every reflected XSS becomes a full account takeover, because the injected script can call any origin and exfiltrate cookies/localStorage.
• Server and X-Powered-By headers - version disclosure. Attacker reads Express 4.17.1, looks up CVEs for that version, knows exactly which exploits apply.

Reflected Origin is the AI-favorite CORS bug:

// Dangerous "works with any localhost port" fix
res.setHeader("Access-Control-Allow-Origin", req.headers.origin);
res.setHeader("Access-Control-Allow-Credentials", "true");

Allowlist origins instead. See also CORS credentials misconfig.

Host-Specific Recipes

The report includes paste-ready config for every target. Common ones:

vercel.json:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=31536000; includeSubDomains; preload" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=(), payment=()" },
        { "key": "Content-Security-Policy", "value": "default-src 'self'; script-src 'self' 'nonce-{NONCE}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" }
      ]
    }
  ]
}

Netlify _headers:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
  Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Express + Helmet:

import helmet from 'helmet';

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'", (req, res) => `'nonce-${res.locals.nonce}'`],
      objectSrc: ["'none'"],
      baseUri: ["'self'"],
      frameAncestors: ["'none'"],
    },
  },
  hsts: { maxAge: 31536000, includeSubDomains: true, preload: true },
  crossOriginOpenerPolicy: { policy: 'same-origin' },
}));

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;

The always flag is mandatory - without it Nginx skips the header on error responses, which is exactly when version-disclosure leaks happen.

Next.js headers() in next.config.js:

async headers() {
  return [
    {
      source: "/:path*",
      headers: [
        { key: "X-Content-Type-Options", value: "nosniff" },
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
        { key: "X-Frame-Options", value: "DENY" },
      ],
    },
  ];
}

If both CDN Transform Rules and origin set CSP, pick one owner. Duplicate policies confuse debugging when staging “works” and prod fails.

CSP rollout strategy

CSP is the one header that will break things if you turn it on cold. Roll out in three stages:

1. Report-only - deploy Content-Security-Policy-Report-Only with report-uri /csp-report. Browsers send violation reports; nothing is blocked. Run for 1–2 weeks across your real traffic.
2. Triage reports - every violation is either a real script you missed in the policy (whitelist with hash/nonce) or an actual XSS attempt (good, it would have been blocked).
3. Enforce - promote to Content-Security-Policy. Keep report-uri so regressions surface in CI.

If you can’t host a report endpoint, csp-evaluator.withgoogle.com will at least flag obvious holes in a pasted policy.

Nonces vs hashes vs 'unsafe-inline'

• Nonces work well with SSR frameworks that can inject a per-request random value into script tags and the CSP header.
• Hashes fit static inline scripts that never change.
• 'unsafe-inline' is what AI generators leave forever after an analytics paste. Treat it as temporary debt with an expiry.

<!-- Server injects the same nonce in header and tag -->
<script nonce="rAnd0m">window.__BOOT__ = {}</script>

Why AI-Generated Apps Fail This

AI generators ship the app first, headers later - or never. Default framework output ships without CSP. CORS gets set to * “temporarily” during debugging and stays. The dev environment never triggered any of these as bugs because everything was same-origin localhost. This checker is the fastest way to catch those drifts.

Typical AI excuses that stay in production:

• “We’ll add Helmet later.”
• Access-Control-Allow-Origin: * to unblock a Vite port.
• Inline analytics snippets forcing 'unsafe-inline' forever.
• Marketing page and app sharing one origin without split CSP.
• Middleware that sets headers only on HTML pages, leaving JSON APIs bare.
• Preview deployments that skip vercel.json headers until custom domain production.

Cookies the checker cares about

Headers and cookies interact:

AI session code often sets SameSite=None; Secure “so mobile WebViews work” without needing it - widening CSRF surface. Prefer Lax unless you have a documented cross-site cookie need.

How to verify after fixing

curl -sI https://yoursite.com | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy'

1. Redeploy with header config.
2. Re-run this checker on production and preview URLs (they can differ).
3. Click through login, payments, and any third-party widgets - CSP breakages show as blank widgets or console errors.
4. Confirm authenticated pages send Cache-Control: no-store where needed.
5. Still run Token Leak Checker and Vibe Code Scanner - headers do not catch open APIs.
6. Check an error page (404/500) still includes security headers (always on Nginx; framework error handlers on Node).

Framework notes

If both CDN and origin set CSP, the browser uses the response it receives - duplicate conflicting policies are a common “works on staging, fails on prod” issue. Pick one authoritative layer.

What this scanner does NOT flag

• Headers set on a different domain. If your assets are on a CDN subdomain that returns its own headers, we test only the URL you submit. Pass each origin separately.
• Edge-case CSP issues. A policy that parses correctly but allows 'unsafe-eval' for a single legitimate library is graded Warn, not Fail - the call is yours.
• Cookie issues for cookies the scanner never sees. We grade the cookies your site sets on a fresh visit. Cookies set only after login require an authenticated re-scan.
• Header order or duplicates from upstream proxies. Some load balancers prepend their own X-Frame-Options. We report the value the browser actually receives; if your app sends DENY and the proxy rewrites it to SAMEORIGIN, the scanner shows the rewritten value.
• Business-logic auth failures. Perfect headers, open Supabase tables - still critical elsewhere.

Related tools and guides

• Token Leak Checker - header hardening matters less if your API keys are in the bundle anyway.
• Vibe Code Scanner - full app scan that reads headers and probes auth and RLS.
• Free Security Self-Audit - manual checklist that pairs with header scanning.
• CORS Checker - deeper CORS-only pass when the grade card flags ACL-Allow-Origin.