A Security Headers Checklist for AI-Built Apps

Quick answer: Review CSP, HSTS, content-type handling, framing controls, referrer policy and browser permissions alongside application security tests. Configure each header for the deployed app and test its effects. Headers reduce specific browser risks; they do not prevent every injection, data leak or authorization flaw.

By Gabriel CA · Kraftwire Software

Inspect HTTP response headers in the deployed application alongside source and configuration review. Headers can reduce specific browser risks, including some injection, framing and insecure-transport scenarios, but do not replace application-level controls.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

Header changes may require application changes, such as nonce handling, asset loading or embedding behavior. Test representative routes and error responses before enforcing a new policy.

Why Do AI-Built Apps Need A Security Headers Checklist?

Apps built through vibe-coding need headers suited to their actual resources and browser features. Inspect the deployed response rather than assuming a host or code generator selected an appropriate policy.

Review these controls in context:

• Transport: HSTS upgrades applicable HTTP requests after the browser knows the policy; first-contact protection depends on prior knowledge or a preload list.
• Injection and exfiltration: CSP restricts supported loads and script execution, but is not a complete injection or data-loss defense.
• Framing: CSP frame-ancestors or X-Frame-Options can restrict embedding that could enable clickjacking.

What Is The Content Security Policy (CSP) Requirement?

Content Security Policy tells supporting browsers which sources and behaviors are allowed. A restrictive policy can break legitimate scripts, styles or integrations, so evaluate it against the application and test before enforcement.

Consider a strict CSP based on unpredictable per-response nonces or script hashes. Avoid relying on unsafe-inline; the source-list example below illustrates individual directives and is not itself a nonce- or hash-based strict policy.

Source-List CSP Example

This policy does the following:

• default-src 'self': Supplies a same-origin fallback for supported fetch directives; it does not control every browser action.
• script-src 'self': Restricts script sources to the same origin and blocks ordinary inline script execution under this policy.
• object-src 'none': Blocks object and embed resource loads.
• frame-ancestors 'none': Blocks framing by any ancestor in supporting browsers.

If you are using a platform like Lovable, you should verify your CSP settings to ensure they don't block necessary assets. You can learn more in our Lovable security guide.

How To Implement Strict Transport Security (HSTS)?

Once a browser has a valid HSTS policy for the host, it upgrades applicable HTTP requests to HTTPS. Even if a user types http:// in their browser, HSTS forces an internal redirect to https:// before any data is sent over the wire.

The preload directive does not itself add a domain to browser lists. Preloading requires submission and inclusion, can affect subdomains, and can take time to reverse. Evaluate the requirements and tradeoffs before opting in.

HSTS Preload Example

This max-age is two years, and the policy covers subdomains. Confirm HTTPS works throughout the affected domain before rollout, and increase the duration cautiously. An SSL checker reports supported certificate and TLS observations; it does not establish readiness for every subdomain.

Is X-Frame-Options Still Necessary?

CSP frame-ancestors provides framing controls in modern browsers. X-Frame-Options can provide a compatibility fallback for older clients. These controls restrict embedding through elements such as <frame>, <iframe>, <embed>, or <object> where supported; choose a policy that matches intended integrations.

X-Frame-Options Example

Use DENY when the page should not be framed. SAMEORIGIN permits framing by the same origin; a different subdomain is a different origin. For related access boundaries, review our guide on architecture security risks.

What Does X-Content-Type-Options Do?

X-Content-Type-Options asks browsers to respect declared MIME types. With nosniff, script and stylesheet requests with incompatible types are blocked in supporting browsers. Serve correct Content-Type values; this is not a general sanitizer for uploaded content.

Recommended X-Content-Type-Options Configuration

Check that scripts, styles and uploaded files have appropriate content types, then test behavior with the header enabled. Include this in your application security checklist.

How Should Referrer-Policy Be Configured?

The Referer header can contain origin, path and query information, depending on policy and request context. Keep secrets out of URLs; referrer policy does not remove copies in logs, history or other storage.

Referrer-Policy Example

For same-origin requests, this policy can send the origin, path and query. For cross-origin requests it sends only the origin when security is not downgraded, and omits the referrer on HTTPS-to-HTTP downgrades. An origin includes scheme, host and port; it is not just a domain name.

What Is The Permissions-Policy Header?

The Permissions-Policy header controls supported browser features such as camera, microphone and geolocation for the document and embedded contexts. Support varies by browser and directive; it does not control every capability an injected script could use.

Permissions-Policy Example

Empty allowlists disable these features where the browser supports the directives. This does not prevent every form of tracking or data theft.

How To Audit Your Headers Automatically?

Repeat header checks after deployment changes and test representative routes. An automated report captures observed responses, not every possible browser or application state.

13% of the 119 live sites SimplyScan has scanned (15 sites) have at least one high-severity web-security issue, such as a missing Content-Security-Policy or HSTS header.

Review generated code and deployed configuration directly, and test application-specific behavior alongside the supported automated checks.

SimplyScan checks supported headers alongside other health signals:

• Security: Supported exposed-secret and bounded backend checks complement header observations. A URL scan does not audit every Supabase RLS policy.
• Speed: Resource and page signals can suggest areas to measure; they do not establish every bottleneck.

79% of the 119 live sites SimplyScan has scanned (94 sites) have at least one medium-severity speed issue, such as render-blocking scripts or no route-based code splitting.

• Compliance: Observable policy, consent and tracker signals are separate from legal conclusions.
• Email: DNS checks inspect SPF and DMARC plus selected DKIM selectors; email authentication still needs message-level verification.

SimplyScan grades 8 dimensions in its free scan and shows selected findings. For a focused response-header report, use the Security Headers tool and test the policy in browsers.

Summary Checklist For Production Apps

Review these browser protections as part of deployment testing:

Content-Security-Policy

Review script sources and consider nonce- or hash-based policies rather than relying on unsafe-inline.

Strict-Transport-Security

Roll out HTTPS policy with an appropriate max-age; evaluate preload separately.

X-Content-Type-Options

Use nosniff with correct Content-Type values and test script and stylesheet responses.

X-Frame-Options

Choose DENY or SAMEORIGIN where appropriate, alongside compatible CSP framing controls.

Referrer-Policy

Evaluate strict-origin-when-cross-origin or a stricter policy for the application's data flows.

For developers using specialized backends, ensure you also follow platform-specific advice, such as the Supabase security checklist or the Firebase security checklist. Properly configured headers are a useful defense that should accompany application security review.