Home / Guides / How to add security headers to a Lovable app

How to add security headers to a Lovable app

Lovable hosting sends HSTS, nosniff and Referrer-Policy but no CSP or clickjacking protection. Three ways to add them, and a CSP that won’t break your app.

Check your live site

Run the free ShipLatch scan on your own site without leaving this page.

Uses 1 of your 3 free scans today; a site scanned in the last 24 hours answers from that scan. Passive and read-only: we only look at what any browser can see. Only check sites you own or may test.

Short answer

A Lovable app on Lovable hosting already sends three of the usual security headers. It does not send a Content-Security-Policy or any clickjacking protection, and Lovable's hosting has no setting where you can add your own response headers. To add them you either put your custom domain behind Cloudflare and add the headers there, or host the build somewhere that reads a headers file (Netlify, Vercel). A CSP meta tag is a partial fallback.

Headers are the low-stakes part of Lovable security. If you haven't checked RLS and secret keys yet, do those first.

What a Lovable app sends today

We checked a live lovable.app app on Oct 26, 2026. The response carried:

Missing: Content-Security-Policy, and X-Frame-Options or CSP frame-ancestors. Without one of those last two, any site can load your pages in a hidden frame (clickjacking).

Check your own app. In a terminal run curl -sI https://yourapp.lovable.app, or open DevTools → Network, reload, click the first (document) request and read Response Headers. Platforms change defaults, so trust what you see over this page.

Why you can't just ask Lovable to add them

Response headers come from whatever serves your site, not from your React code. Lovable's hosting docs cover publishing, HTTPS and custom domains, but describe no way to set custom response headers. If you ask the AI to "add security headers", it may write a _headers or vercel.json file that Lovable hosting never reads. The fix looks done, and nothing changes on the live site.

Option 1: custom domain behind Cloudflare (keeps Lovable hosting)

  1. Your domain's DNS must be on Cloudflare. When you connect the domain in Lovable (Project → Settings → Domains), turn on the advanced Uses Cloudflare or similar proxy option. Lovable then gives you a CNAME to your lovable.app URL, which you add in Cloudflare as Proxied (Lovable custom domain docs).
  2. In Cloudflare open Rules → Transform Rules → Modify Response Header, and create a rule for your hostname that sets these headers: 
    X-Frame-Options: DENY
Content-Security-Policy-Report-Only: (your policy, see below)
    HSTS, nosniff and Referrer-Policy already arrive from Lovable, so you don't need to repeat them.
  3. Send people to the custom domain. The lovable.app address bypasses your Cloudflare rule and stays without these headers.

Option 2: host the build yourself

Connect GitHub (Git sync) and deploy the repo to Netlify or Vercel, which Lovable documents in Deploying and hosting outside Lovable. Then:

Lovable's Publish button keeps publishing to Lovable hosting only, so point your custom domain at the new host.

Option 3 (partial): a CSP meta tag

You can ask Lovable to put <meta http-equiv="Content-Security-Policy" content="..."> in the page head. It does limit where scripts can load from. But browsers ignore frame-ancestors in a meta tag, so it gives no clickjacking protection. Header scanners (ShipLatch included) only read real response headers, so the "No Content-Security-Policy header" finding will stay.

Writing the CSP without breaking the app

A CSP lists every outside service your app talks to. Miss one and that part of the app breaks, so start in Report-Only mode. It logs what would be blocked and blocks nothing. A starting point for a Lovable app with a Supabase-style backend:

default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; font-src 'self' data:; connect-src 'self' https://YOUR-PROJECT.supabase.co wss://YOUR-PROJECT.supabase.co; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'

Find your backend URL in DevTools → Network (the requests your app makes when you sign in or load data). Add Stripe (https://js.stripe.com in script-src and frame-src), font and analytics domains if you use them. Use the app for a few days, read the CSP warnings in the browser console, add what's legitimate, then rename the header to Content-Security-Policy to enforce it. Newer Lovable apps render on the server and may include inline scripts. If Report-Only flags those, fix that before you enforce, rather than adding 'unsafe-inline' to script-src by reflex.

Copy-paste into Lovable
List every outside domain this app loads scripts, styles, fonts, images or data from, or opens connections to (backend, websockets, payments, analytics). Then write a Content-Security-Policy for it, starting from: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. Give it to me as one line for a Content-Security-Policy-Report-Only response header. Do not create _headers or vercel.json files unless I say the app is hosted on Netlify or Vercel.

Prove it worked

Run curl -sI https://yourdomain.com and confirm the new headers are in the response, then re-scan the custom domain. Also click through sign-in, data loading and checkout once with the console open.

Related: Security headers for vibe-coded apps · Is my Lovable app secure? · Lovable checklist

Scan your app free

ShipLatch reads your live site's response headers, plus leaked keys, exposed files and Supabase/Firebase setup, and tells you which ones matter most. The $29 Fix Pack gives you fix prompts written for your app and re-scans that prove each fix worked.

Scan free at shiplatch.com → See the Fix Pack

Want the whole pre-launch process in one place? Get App Security for Vibe Coders, our $9 PDF playbook.

More guides