Security headers: the five-minute hardening AI builders skip
CSP, HSTS, X-Frame-Options — a handful of response headers that turn a contained bug into a non-event. AI builders almost never set them. Here is what each one stops and how to add them.
Security headers are instructions your server sends with every response telling the browser how to behave: what scripts it may run, whether it may be embedded in a frame, whether it must use HTTPS. They cost nothing and ship in minutes. AI builders skip them anyway, because nothing in the app breaks without them — the gap only matters the day something else goes wrong.
That is exactly why they are worth setting now. A single missing header rarely sinks you on its own; together they are the difference between a contained mistake and an account takeover.
The four that earn their keep
Content-Security-Policy — restricts which origins can load scripts and styles. It is the strongest single defence against cross-site scripting: even if an attacker injects a <script>, the browser refuses to run it. Strict-Transport-Security (HSTS) — forces HTTPS for every future visit, closing the window where a first request over HTTP can be intercepted and downgraded. X-Frame-Options (or CSP frame-ancestors) — stops your app being embedded in an attacker's invisible iframe and clickjacked. X-Content-Type-Options: nosniff — stops the browser guessing content types, a trick used to make an uploaded "image" execute as script.
Why a CSP is the one to get right
Most of these headers are a single line. CSP is the exception: it takes thought, because a policy that is too loose (script-src with unsafe-inline, or a wildcard) protects nothing, while one that is too strict breaks your own bundle. Start in report-only mode, watch what it would have blocked, then tighten. The goal is a policy that names exactly the origins your app legitimately loads from and nothing else.
How to add them
You do not need to touch application code. Set headers at the edge — your host's configuration, a CDN rule, or a middleware that runs on every response.
On Vercel/Netlify: add a headers block to vercel.json or netlify.toml / _headers. Behind a reverse proxy or framework: add them once in middleware so every route inherits them. Verify with a scan or curl -I; do not assume the host set sensible defaults — most do not.
VibeSafely grades CSP, HSTS, X-Frame-Options, X-Content-Type-Options and the rest against current best practice and tells you which are missing and which are present-but-weak — so you fix the policy, not just the checkbox.
See what your app left exposed.
One free scan, sixty seconds, no credit card — every finding with a copy-paste fix.
Scan my site — free