Security headers are HTTP response headers that tell the browser how to treat your page defensively — which scripts are allowed to run, whether the page can be loaded inside a frame, whether HTTPS is mandatory. When they're missing, the browser falls back to permissive defaults, which opens the door to attacks like cross-site scripting, clickjacking, and protocol downgrade that the header would otherwise have blocked outright.
The headers that matter most
Four headers cover most of the practical risk for a typical web app:
- Content-Security-Policy (CSP) — restricts which script, style, and connection sources the browser will execute or load, limiting the damage of an injected script.
- Strict-Transport-Security (HSTS) — tells the browser to only ever connect over HTTPS for this domain, closing off downgrade and cookie-theft attacks over plain HTTP.
- X-Frame-Options (or a frame-ancestors CSP directive) — stops other sites from loading your page inside an invisible iframe for clickjacking.
- X-Content-Type-Options: nosniff — stops the browser from guessing a file's type in a way that can turn an uploaded file into executable script.
Why AI-scaffolded apps tend to skip these
Most AI app builders and default framework templates ship with none of these set, because they're not required for the app to function — a missing CSP or HSTS header never shows up as a bug during development, since the app still loads and works normally. They only matter when someone is actively trying to exploit the gap, which is exactly why they're easy to ship without noticing.
How to add them in Next.js
Set headers in next.config.js via the headers() function, or in middleware.ts if you need per-route logic. A minimal starting CSP for a typical Next.js app allowlists 'self' plus any third-party script domains you actually use (analytics, payment widgets, etc.) — an overly strict policy will silently break those integrations, so test after deploying.
Frequently asked
Will adding a Content-Security-Policy header break my app?
It can, if the policy doesn't allowlist every domain your app actually loads scripts, styles, or fonts from. Start with a report-only CSP (Content-Security-Policy-Report-Only) to see what it would have blocked before enforcing it.
Do I need all four headers, or can I prioritize?
If you can only add one, add Content-Security-Policy — it has the broadest defensive coverage. HSTS is the next highest priority if your app handles logins or sensitive data over HTTPS.