Content-Security-Policy header is present

Without a Content-Security-Policy, any XSS vulnerability in your app becomes a full code execution primitive — injected scripts can exfiltrate cookies, keylog form inputs, or pivot to your users' other browser contexts. CSP is the browser-enforced last line of defense: even when input sanitization fails, a tight policy prevents injected scripts from loading external resources or executing inline. OWASP A03 (Injection) and A05 (Security Misconfiguration) both call out missing CSP as a critical gap; CWE-79 names the XSS class that a CSP directly mitigates. Without it, a single missed sanitization anywhere in your rendering pipeline becomes an account-takeover vector.

Add a Content-Security-Policy header starting with a restrictive default-src 'self' and expand from there based on what your app actually loads. Start minimal and use browser console violation reports to tune.

// next.config.js
headers: [{
  key: 'Content-Security-Policy',
  value: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'"
}]

If your app uses third-party scripts, add their domains explicitly (script-src 'self' https://cdn.example.com) rather than using the wildcard *. For inline scripts, use nonces rather than unsafe-inline — see the csp-no-unsafe-inline pattern for the nonce implementation.