Security headers for AI-built apps

The practical header baseline

A launch baseline should cover the browser behaviors that most often matter for public apps: framing, content sniffing, referrer leakage, permissions, and script loading.

Do not copy a header block blindly. Start with a strict baseline, then open only the capabilities the app actually needs.

• Content-Security-Policy for scripts, styles, images, connections, and frames.
• X-Content-Type-Options: nosniff.
• X-Frame-Options or CSP frame-ancestors.
• Referrer-Policy with a deliberate leakage boundary.
• Permissions-Policy for sensitive browser capabilities.

CSP is the most important and easiest to break

A Content Security Policy can reduce script injection impact, limit external connections, and block unwanted framing. It can also break the app if it ignores real runtime dependencies.

For AI-built apps, the safest path is to inventory what the app actually loads, then write a policy that matches production behavior rather than local development behavior.

Framework defaults are not a policy

Frameworks and hosting platforms may set some headers, but the product owner still needs to decide the intended browser boundary.

If the app was generated or assembled quickly, do a direct header check before publishing the launch post.

Verify from the public URL

Header checks should run against the deployed URL because middleware, proxies, CDN settings, and platform rules can change what the browser receives.

The final answer should be based on production responses, not config files alone.

• Check the home page and app routes separately.
• Check API routes separately if they are public.
• Confirm redirects preserve the intended header behavior.