Security headers for vibe-coded apps

Security headers are boring until they are missing.

They are HTTP response headers that tell browsers how to handle your site more safely. They can reduce the risk of clickjacking, MIME sniffing, mixed content, cross-site scripting damage and accidental exposure.

AI builders often skip them because the app appears to work without them.

That is exactly why you should check.

The headers worth knowing

You do not need to memorise every header before launch.

Start with these:

• Content-Security-Policy
• Strict-Transport-Security
• X-Frame-Options or frame-ancestors
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

Each header answers a browser question.

Can this page be framed? Can scripts load from anywhere? Should HTTP be upgraded to HTTPS? How much referrer data should be sent? Can the page access camera, microphone or location?

Check what your site sends

Run:

curl -I https://your-domain.com

Look for security headers in the response.

If you do not see them, ask your agent:

Review the HTTP response headers for this app.

Identify missing or weak security headers.
Recommend a safe baseline for this framework and hosting provider.
Explain what each header does, what it protects against, and what could break if configured too strictly.

Content Security Policy

Content-Security-Policy is the most powerful and the easiest to break.

It controls where scripts, styles, images, frames, fonts and connections can load from.

A strict CSP can reduce the damage from cross-site scripting.

A careless CSP can break your app, analytics, Stripe, embedded videos, fonts, images, or AI widgets.

Use this prompt:

Design a Content Security Policy for this app.

First inspect:
- scripts and analytics providers
- fonts
- images and remote image domains
- Stripe or payment providers
- auth providers
- embedded videos or iframes
- API endpoints used by the frontend

Then propose a CSP that is safer than no policy but unlikely to break production.
Include a rollout plan using report-only mode if appropriate.

For many early apps, "safer than nothing and verified not to break the site" is better than "perfect policy copied from a blog post."

Strict Transport Security

Strict-Transport-Security tells browsers to use HTTPS for future requests.

It is usually safe once your site is fully HTTPS.

But do not add aggressive preload settings blindly if you do not understand the domain implications.

Ask:

Check whether this site is ready for Strict-Transport-Security.

Confirm all production pages and assets load over HTTPS, then recommend an HSTS header value. Warn me before adding preload or includeSubDomains.

Clickjacking protection

Clickjacking is when another site frames your app and tricks users into clicking it.

Protection usually comes from:

• X-Frame-Options: DENY or SAMEORIGIN
• Content-Security-Policy: frame-ancestors ...

If your app genuinely needs to be embedded, configure this carefully.

If it does not, block framing.

Permissions Policy

Permissions-Policy restricts browser features like camera, microphone, geolocation and payment APIs.

Most apps do not need broad access.

Ask:

Review browser capabilities used by this app.

Create a Permissions-Policy that disables features we do not need, without breaking legitimate product functionality.

Add headers in the right place

Where headers live depends on the stack:

• Next.js can define headers in next.config
• Vercel can add headers through framework config or route handling
• Express or custom servers can set headers in middleware
• Cloudflare, Netlify and other hosts can add them at the edge

Do not add duplicate conflicting policies in three places.

Ask:

Find the correct place to define security headers in this project.

Avoid duplicate header definitions.
Show me the exact file and explain how to verify the deployed response with curl.

Verify after deployment

Local config is not enough.

After deployment, check the live domain:

curl -I https://your-domain.com

Then open the site in a real browser and check for console errors.

Security headers are only useful if they are actually sent and do not break the app.

What PageLens can help with

PageLens checks security header presence and related launch-readiness signals on the live site.

That matters because headers are often configured differently between local, preview and production.

If PageLens flags missing headers, treat that as a production-surface issue, not just a code style issue.

Security headers are one part of the public edge. If your production logs show bots probing paths like /.env, /.git/config, /xmlrpc.php or /wp-admin, also read Middleware, proxies and automated attack scanners.