// SECURITY
What do missing security headers and open CORS actually expose?
Updated 2026-08-11 · 4 min read
Security headers tell the browser how to protect your users (force HTTPS, block clickjacking, restrict scripts). CORS decides which other websites may call your API. Missing headers and a wildcard CORS policy (Access-Control-Allow-Origin: *) let a stranger’s site act against your API on behalf of your logged-in users.
What it is
Headers like HSTS, X-Frame-Options/frame-ancestors, and Content-Security-Policy are instructions the browser follows to reduce attacks. CORS is a separate control listing which origins may call your API from a browser.
Why it matters to you
A wide-open CORS policy means any website can make authenticated requests to your API using your users’ sessions. Missing HSTS allows downgrade attacks; missing frame protection allows clickjacking.
How it happens in AI-built apps
CORS is often set to * to "make the API work" during development and never tightened. Security headers are simply never added, because the app functions perfectly without them.
The fix
- Set CORS to an explicit allow-list of your own domains, never * for authenticated APIs.
- Add HSTS, X-Content-Type-Options: nosniff, and a frame-ancestors / X-Frame-Options policy.
- Add a Content-Security-Policy to limit which scripts can run.
Key takeaways
- Access-Control-Allow-Origin: * on an authenticated API lets any site abuse your users’ sessions.
- Restrict CORS to your own domains.
- Add HSTS, frame protection, nosniff, and a CSP.
Frequently asked
Are security headers really necessary for a small app?
Yes. They are free, quick to add, and close whole classes of attack. Attackers scan for missing headers first because they signal an app nobody hardened.