Security headers present (CSP, X-Frame-Options, X-Content-Type, HSTS)

Missing security headers leave browsers without the instructions needed to block clickjacking, MIME-type sniffing attacks, and content injection — gaps that attackers exploit through iframe embeds, malicious redirects, and injected scripts. NIST 800-53 rev5 SC-8 covers transmission integrity and SI-3 covers malicious code protection; both are satisfied in part by response headers that tell browsers what to trust. FedRAMP rev5 SC-8 applies to all cloud systems serving federal users. OWASP A05 (Security Misconfiguration) and CWE-693 (Protection Mechanism Failure) specifically call out absent security headers. A CSP header alone can neutralize most XSS payloads that slip through input validation.

Configure all four required headers in next.config.js at the framework level so they apply to every route including API responses.

// next.config.js
const securityHeaders = [
  { key: 'Content-Security-Policy',
    value: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:" },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Strict-Transport-Security',
    value: 'max-age=31536000; includeSubDomains; preload' }
]

const nextConfig = {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }]
  }
}
export default nextConfig

Verify the headers are live in production using curl -I https://yourdomain.com — not just in dev. If your CSP blocks legitimate inline scripts, migrate to nonce-based CSP rather than weakening to unsafe-inline for all sources.