How do I add security headers on a Lovable site?

Check what your published Lovable URL actually sends with curl -I. Lovable's hosting docs describe HTTPS, global delivery and custom domains, but they do not document a project setting or UI for adding your own security headers. If the headers you need are missing, put a CDN or reverse proxy in front, or host the build on Vercel, Netlify or Cloudflare Pages where you control vercel.json / _headers.

That is the honest path as of the docs we checked (October 2026). Do not invent a "Lovable headers" panel that isn't in the product docs. Measure first, then choose a host layer you can configure.

What Lovable hosting documents (and what it doesn't)

From How Lovable hosts your app:

• Publishing puts a snapshot on a lovable.app URL (or your custom domain on a paid plan).
• HTTPS and certificates are included automatically.
• Delivery is global; you don't configure CDN nodes yourself.
• Preview is not the same as the published site.

What those pages do not document: a switch, file or chat action that lets you set Content-Security-Policy, X-Frame-Options, Permissions-Policy or a custom HSTS value on Lovable-managed hosting. Lovable's external deployment guide is explicit that when you move the frontend to Vercel, Netlify, Cloudflare Pages and similar, you take on CDN behaviour, environment variables and production config — which is where custom headers normally live.

Lovable's Trust center can observe whether certain connection and browser protections are present on a published app (HTTPS redirect, HSTS-style stay-on-HTTPS, nosniff, framing restrictions, load rules, feature permissions, referrer behaviour). That is a verification page Lovable generates at /.well-known/trust.html — not a place to edit header values yourself. Treat Trust center as evidence of what Lovable could confirm, not as a headers editor.

Sandbox tooling for local Vite configs has also been documented (third-party / ecosystem notes) as stripping custom server.headers inside Lovable's proxy. Even if that changes, production headers are still decided by whatever serves the published site — so always verify the live URL.

Step 1: Check what you already send

Only probe sites you own. Against your published *.lovable.app URL or custom domain:

curl -sI https://your-app.lovable.app/ | grep -iE \
  'strict-transport|x-content-type|x-frame|content-security|referrer-policy|permissions-policy|cross-origin'

Also check a deep route and a static asset, because some hosts differ by path:

curl -sI https://your-app.lovable.app/dashboard | grep -iE 'strict-transport|x-frame|content-security'
curl -sI https://your-app.lovable.app/assets/index.js | grep -iE 'strict-transport|x-frame|content-security'

Interpret the result:

What you see	What it means
HSTS / nosniff / frame / CSP lines present	Platform or an upstream layer is already sending them. Note the exact values before you change anything.
Almost nothing beyond content-type / cache	You need another layer to add security headers.
Trust center shows browser checks, but curl is thin	Trust center and curl can disagree in timing or coverage — republish, wait a few minutes, curl again. Prefer curl on the URL users hit.

For the meaning of each header, see the security headers fix guide. StackSiren's security headers checker runs the same class of checks passively on a URL you own.

Headers worth having

Same baseline as our Vercel and Netlify guides:

Header	Starter value
Strict-Transport-Security	max-age=63072000; includeSubDomains
X-Content-Type-Options	nosniff
X-Frame-Options	DENY
Referrer-Policy	strict-origin-when-cross-origin
Permissions-Policy	camera=(), microphone=(), geolocation=()
Content-Security-Policy	Start with Report-Only, then enforce

Only add HSTS preload if every subdomain is HTTPS and you intend to submit the domain to the preload list. CSP is the header most likely to break Stripe.js, Supabase or fonts — roll it out carefully (details below).

Reliable fix A: Host outside Lovable (recommended when you need control)

Lovable documents Git sync plus deploy to Vercel, Netlify, Cloudflare Pages and others. Older React + Vite apps publish static dist/; newer TanStack Start apps need a host that runs the server output. Once the production frontend is on a host you configure:

Vercel — vercel.json

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" },
        { "key": "Content-Security-Policy-Report-Only", "value": "default-src 'self'; script-src 'self' 'unsafe-inline' https://js.stripe.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' https://*.supabase.co wss://*.supabase.co; frame-src https://js.stripe.com https://checkout.stripe.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" }
      ]
    }
  ]
}

Full walkthrough: how to add security headers on Vercel.

Netlify — public/_headers (Vite) or netlify.toml

/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'unsafe-inline' https://js.stripe.com; connect-src 'self' https://*.supabase.co wss://*.supabase.co; frame-ancestors 'none'

Full walkthrough: how to add security headers on Netlify.

Keep using Lovable for editing if you want; point production DNS at the external host when that deploy is verified. Lovable's Publish button continues to update Lovable hosting only — your external pipeline deploys from the synced repo.

Reliable fix B: CDN or reverse proxy in front of the custom domain

If you keep serving from Lovable but control DNS for a custom domain, some teams put Cloudflare (or another CDN) in front and add Transform Rules / Response Header Modification (product names vary) so every response gains the security headers. Requirements:

1. The CDN must be able to add response headers on the way to the browser.
2. You must point the custom domain at that CDN and keep TLS valid end-to-end.
3. You re-check with curl -I https://your.custom.domain/ — not only the lovable.app origin — because users hit the CDN hostname.

Exact Cloudflare / Fastly / AWS CloudFront clicks change often; follow your CDN's current "modify response headers" docs rather than a screenshot from this post. If the CDN can't override headers from the origin, use Fix A instead.

A meta tag CSP in index.html is a partial backstop only. Per MDN, Content-Security-Policy via <meta http-equiv> cannot set frame-ancestors (or some reporting features), so clickjacking protection still needs a real HTTP header.

Roll out CSP without breaking the app

1. Ship Content-Security-Policy-Report-Only first (as in the examples above).
2. Click through sign-in, payments and any embeds; watch the browser console for violations.
3. Allowlist real origins (Supabase project URL, https://js.stripe.com, your font host, analytics).
4. Rename to Content-Security-Policy when the console is quiet.

Wildcard CORS (Access-Control-Allow-Origin: *) is a separate misconfiguration — see is Access-Control-Allow-Origin: * safe? — and fixing headers does not fix a wide-open API CORS policy.

After you change anything

curl -sI https://your.production.domain/ | grep -iE \
  'strict-transport|x-content-type|x-frame|content-security|referrer-policy|permissions-policy'

You want one line per header on HTML responses. Then run a free StackSiren scan on that same URL so missing headers show up beside exposed keys and env files.

Related reading

• Security headers fix guide
• Add security headers on Vercel
• Add security headers on Netlify
• Lovable + Supabase RLS policies

FAQ

Can I ask Lovable chat to "add security headers"? You can ask it to add a vercel.json, netlify.toml, _headers file or a meta CSP in index.html. Those files help once a host that reads them serves the app. They do not configure Lovable's own managed hosting unless Lovable documents that behaviour — and the hosting docs we checked do not.

Does the Trust center mean my headers are perfect? No. It reports checks Lovable could confirm for the current deployment. It is not a certification, and omitted checks are not a full vulnerability report. Still verify with curl -I.

Is HTTPS enough? HTTPS (which Lovable includes) stops network eavesdropping on the wire. Security headers additionally constrain framing, MIME sniffing, future HTTPS use and which scripts can load. You usually want both.

Will a meta tag CSP replace HTTP headers? No. Use it only as a weak backstop. Prefer HTTP headers from the host or CDN, especially for frame-ancestors.

What about secrets while I'm fixing headers? Headers don't protect a Stripe sk_ or Supabase service_role key in the browser. Keep secrets server-side — Lovable's own security best practices show Stripe secrets in frontend code as an anti-pattern. See exposed Stripe secret key.

How do I re-check after each publish? curl -I on the production hostname, then a free StackSiren scan. Solo ($29/mo) and Builder ($79/mo) add scheduled rescans of sites you own.