Bolt.new Security Check

This page is about Bolt.new, the AI app builder at bolt.new, not door locks or bolt hardware. If you built a web app in Bolt and you're about to share the demo link, this is the check to run first.

Bolt gets you from prompt to published site in minutes. Speed like that means some details get left at their defaults: response headers, environment variables, and the tags that tell Google whether to index you. None of that shows up in the preview. All of it shows up for a stranger, a bot, or a buyer doing a quick check before they sign up.

The Pro Logica AI App Security Check is a free, passive scan of your live Bolt app. You get a score out of 100 in about a minute. Run a free Bolt.new security check.

What Bolt apps usually miss

Security headers. Headers are set by the host that serves your files, not by your React code, and builders rarely add them unless you ask. In our passive check of 18 public showcase apps built with Lovable or Bolt, 18 of 18 had no Content-Security-Policy, and 18 of 18 had no clickjacking protection. The average score across that sample was 76 out of 100.

Secrets in the bundle. Bolt projects usually use Vite. In Vite, any variable that starts with VITE_ is written into the JavaScript that ships to the browser. A Supabase anon key in a VITE_ variable is fine. A Stripe secret key, an OpenAI key or a database password is not. We scan your homepage and up to eight of your own JS files for live secret patterns and mask anything we find.

Leftover files. If a .env file or a .git folder ends up in the published output, anyone can download it. When you confirm you own the app, we check /.env and /.git/HEAD once each.

Google blockers. A stray noindex, no <title>, no meta description, or no sitemap. In the same 18-app sample, 15 of 18 had no sitemap we could find.

Database access. Many Bolt apps use Supabase, either connected directly or through Bolt's built-in database. If we find a Supabase URL and anon key, we run a count-only test to see whether anonymous visitors can read table rows. We never download the rows.

Fixing headers on a Bolt app

Where the fix goes depends on where the app is published. Bolt publishes to its own hosting by default, and you can switch a project to Netlify in Project settings → Domains & Hosting.

If your Bolt project publishes to Netlify, add a plain text file called _headers to the public/ folder. Vite copies it into the build output, and Netlify reads it from there:

/*
  Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://YOUR-PROJECT.supabase.co; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

You can also use [[headers]] tables in netlify.toml. One limitation from Netlify's docs: custom headers apply only to files Netlify serves from its own storage. Functions, edge functions, and proxied or server-rendered responses have to set their own headers.

If your project uses Bolt hosting, Bolt's docs don't currently describe a setting for custom headers. Add the _headers file anyway, publish, and test with curl -I https://your-domain. If the headers don't show up, either put a CDN in front of your custom domain and set the headers there, or switch the project to Netlify hosting.

Build your CSP in report-only mode first. Send Content-Security-Policy-Report-Only with the same value, open the app, and check the browser console for anything it would have blocked, such as fonts, analytics, payments or your Supabase URL. Add those sources, then switch to the enforcing header. Don't fall back to script-src *. That defeats the point.

Use Bolt's own checks too. The Publish menu has a security audit (on paid plans) and a database security check (on all plans). Those review your code and database rules from the inside. Our scan checks what your live URL actually serves.

Before you share the demo

1. Run the free scan on the URL you're about to share, not on a preview link.
2. Fix anything critical first: a live key in the bundle, a public /.env, or readable database tables. Rotate any exposed key at the provider. Deleting it from the code doesn't make it secret again.
3. Add the headers above and confirm them with curl -I.
4. Check that your production page doesn't carry noindex, has a real title and description, and has a sitemap listed in robots.txt.
5. Rescan. A higher score is your proof that the fix worked.

Related issues

• Missing security headers checklist
• Exposed .env file: rotate and fix
• Supabase RLS not enabled
• Other builders: Lovable · Replit · Cursor · v0

Run the free check on your app again after you fix things. See all Pro Logica cybersecurity services.

FAQ

Is this about Bolt.new or about door bolts?

Bolt.new, the AI tool that builds and publishes web apps from a prompt. We don't test physical locks.

Does Bolt add security headers for me?

Don't assume it does. Scan your live URL or run curl -I and look for content-security-policy, strict-transport-security, x-content-type-options and referrer-policy. If they're missing, add them using the steps above.

Is the Supabase key in my Bolt app a problem?

The anon key is meant to be public. It's only safe when Row Level Security is on for every table that holds private data. A service_role or secret key in the browser is a real problem. Rotate it and move the work to a server function.

Will the scan slow down or break my site?

No. It's passive: GET and HEAD requests only, about 40 at most, paced out, and it respects robots.txt for page fetches. Nothing is written or submitted.

What do I get if I unlock the full report?

Every finding with masked evidence, a plain-English fix, and a copy-paste prompt written for Bolt, so you can paste it into Bolt's chat and review the change.

See your score before you share the link. Run the free Bolt.new security check.