Security Headers
NullFault inspects the live production response for security headers like Content-Security-Policy, HSTS, and X-Frame-Options that reduce common browser risks.
What NullFault Checks
- Whether the final response includes key hardening headers for transport (HSTS), framing (X-Frame-Options or frame-ancestors), content type handling, referrer behavior, browser permissions, and script policy (CSP).
- Whether a present policy is meaningfully restrictive or only decorative.
- Whether the scanner observed the headers on the live URL after redirects.
Why It Matters
- Headers do not replace secure code, but they reduce the blast radius of browser-side mistakes.
- Missing or weak policies can make clickjacking, content injection, or data leakage easier to exploit.
- Header drift is common when apps move between local, preview, CDN, and production.
Common Causes
- Relying on framework defaults that do not set headers.
- Setting headers in local middleware that the CDN or host overrides.
- Adding a CSP that is present but effectively permissive.
Check it yourself
Open DevTools Network, click your main document request, and read the Response Headers for Content-Security-Policy, Strict-Transport-Security, and X-Frame-Options.
Mitigation
- Set headers at the strongest layer you control: CDN, reverse proxy, host, or app framework.
- In Next.js, define them in the headers() function of next.config; on Netlify or Vercel, use the platform headers config.
- Start with practical defaults, then tighten Content-Security-Policy after testing real third-party scripts and analytics.
- Apply headers consistently across redirects and important routes, and retest after deployment.
Reality check
A missing header is usually a hardening gap, not proof of compromise. NullFault ranks these below direct secret or data exposure unless the policy is clearly dangerous.