Is Bolt.new Safe? Security Risks Every Founder Should Audit

TL;DR: Bolt.new turns a prompt into a working app in minutes. That speed hides a trade-off. Bolt builds in the browser, so the code it writes leans hard on the frontend. Keys end up in the bundle. Row Level Security stays off. Rate limits never get added. A bolt.new security audit checks the app you shipped, not the tool you used. This guide shows what to check, and how to scan your live URL free in about 30 seconds.

Bolt.new grew faster than almost any software product ever. It went from launch to $20 million in yearly revenue in about two months. It passed $40 million within five. Around five million people signed up in the first year. Only ChatGPT grew faster.

That is millions of apps built by people who never had to think about a threat model. Many of those apps take payments, store user data, and sit on the open internet. Most have never been checked by anyone.

Want the fast answer for your app? Run the free scan on your live URL first. No code access. No install. Then read on.

Is Bolt.new Safe? The Tool Is Fine. The Apps Are Not.

Start with the honest answer. Bolt.new itself has no critical CVE on record. StackBlitz, the company behind it, has run browser-based dev tools for years. The platform is not the problem.

The problem is volume. When a tool grows from zero to $40 million in revenue in five months, the apps pile up faster than anyone can review them. Most Bolt builders are first-time founders, marketers, and designers. They ship the moment the demo works. The demo working tells you nothing about what a stranger with DevTools open can see.

The data on AI-built apps is blunt. Symbiotic Security scanned 1,072 Supabase-backed vibe-coded apps across 65,643 URLs. 98% had at least one security issue. 16% had a critical flaw. 172 sites let anyone delete records with no login. 39 sites exposed their full database through a public key. Only 26 apps came back clean.

Bolt apps sit squarely in that population. Supabase is Bolt's default database. The failure pattern is the same one we flag every day.

Why Bolt Apps Leak Keys: The Browser-First Trade-off

Bolt.new runs on WebContainers. Your whole dev environment lives in a browser tab. Nothing installs. That is the magic, and it is real.

It also shapes the code Bolt writes. A browser-based builder defaults to browser-based code. When you ask Bolt for a feature that needs an API, the shortest working path is to call that API straight from the frontend. The key goes where the call goes. Into the bundle. Public.

Bolt's default stack makes this concrete. Most Bolt apps use Vite. In a Vite project, any variable that starts with VITE_ ships to the browser by design. That prefix is a build rule, not a security feature. A VITE_STRIPE_SECRET_KEY looks tidy in the env panel. Reference it from frontend code, and it is readable by anyone who opens your site and views the source.

One key is built for this: the Supabase anon key. It is public by design, and Row Level Security is what keeps it safe. Every other secret is not. OpenAI keys, Stripe secret keys, service role keys. Scrapers hunt fresh deployments for exactly these, and a leaked AI key can burn hundreds of dollars of quota overnight. We wrote a full guide on finding exposed secrets in AI-built bundles, and on which Supabase key belongs where.

The AI did what you asked. You asked for a feature, and the shortest path to a working feature runs through the frontend. Nobody asked for the key to stay server-side. So it did not.

The Security Issues We Find Most in Bolt-Built Apps

We scan live URLs, not repos. Our scanner fingerprints Bolt apps directly: a .bolt.new domain is matched at 0.99 confidence in platformFingerprintScanner.js:22. Across the first 100 vibe-coded apps we scanned, the average Launch Readiness Score was 42 out of 100. On Bolt apps, the same gaps repeat.

• Secret keys in the frontend bundle. Stripe, OpenAI, and service role keys readable in the browser. The most common critical finding, and the browser-first trade-off made real.
• Supabase RLS disabled. The public anon key can then read whole tables. See our Supabase RLS guide.
• Missing rate limiting. No cap on login, signup, or AI endpoints. A script can hammer them for free.
• Missing HTTP security headers. No HSTS, no CSP, no clickjacking protection.
• Bolt-on auth that does not verify. A login form in front of pages that never check the session on the server.
• Unpatched dependency CVEs. Known holes in packages the AI picked for you.

This pattern has a public case study. CVE-2025-48757 hit apps built with Lovable, Bolt's closest rival: 170 projects were readable through the public anon key alone, because RLS was off. Same stack, same default, same failure. Our postmortem breaks down how it happened. Nothing about it is unique to Lovable.

The wider research agrees. Carnegie Mellon's SusVibes benchmark tested AI-written code on 200 real tasks across 77 flaw types. The code was correct 61% of the time. It was secure only 10.5% of the time. Correct and safe are not the same thing.

Beyond Security: Reliability, Performance, and Monitoring

Security is one of four things we check. The other three break launches too, and a prompt-to-app builder skips them just as often.

• Reliability. No error handling. No retries. One failed API call, and the page hangs on a spinner.
• Performance. N+1 queries and missing indexes. Fast with 10 demo rows. Slow at 10,000 real ones.
• Monitoring. The big one. No error tracking at all. When production breaks, you hear it from an angry user, not an alert.

How to Run a Bolt.new Security Audit (the 30-Second URL Scan)

You have three ways to check a Bolt app. They see different things.

The URL scan takes about 30 to 60 seconds. Paste your live URL. The scanner spots your platform and checks all four areas. You get a score out of 100 with the exact findings. No code access, no install, nothing to connect. For the full method, read our vibe coding security audit guide.

Your Pre-Launch Bolt.new Security Checklist

Run this list before you ship. Each item is a check you can do today.

1. No secrets in your frontend bundle. Search your build output for sk_live, sk-, and every VITE_ variable. Only the Supabase anon key belongs there.
2. RLS on for every table. Open Supabase, check each table, and test a query with the anon key. Denied means safe.
3. Server-side checks on paid actions. Any Stripe or OpenAI call should run through a backend route or edge function, never the browser.
4. Rate limits on auth and AI endpoints. Burst 30 requests at your login. If you never see a 429, you have none.
5. Auth verified on the server. Log out, then hit a protected page and API route directly. Both should refuse.
6. Security headers set. HSTS, CSP, and X-Frame-Options at minimum.
7. Error tracking live. Break something on purpose. If no alert arrives, you are flying blind.
8. Dependencies patched. Run an audit on your lockfile and fix the criticals before launch.

When to Bring In a Human: From Free Scan to Fractional CTO

Start with the free scan. It gives you a score out of 100 and the top findings in about 30 seconds. If you want the full picture, the Launch Readiness Audit ($499, one-time) covers all four areas in depth. You get a branded report, a benchmark against 200+ audited apps, and a ranked fix plan with time estimates.

Would you rather have someone fix it for you? Our Code Care tier assigns a human Fractional CTO. Every change arrives as a pull request you approve. And if your app handles EU users or AI features, check the compliance side too. The Bolt security audit page has the platform-specific details.

Frequently Asked Questions