Is Bolt.new Safe? Vulnerabilities to Check Before You Ship

Bolt.new is genuinely useful. You describe what you want, it scaffolds a working app, and you're deployed in minutes. But before you share that URL, there's a question worth asking: is the app actually safe? Almost every Bolt app ships with the same handful of security gaps — not because Bolt is broken, but because the model optimizes for "does this work," not "can a stranger abuse this."

Here are the four most common issues, why they happen, and what to do about each one.

Is Bolt.new safe? The honest answer

Bolt itself is a legitimate platform. The risk is in the code it generates for you. Research on AI-generated applications consistently finds that roughly 45% of samples introduce an OWASP Top 10 vulnerability, and a 2025 analysis of AI-built apps found that around 10% of tested Supabase integrations exposed vulnerable endpoints due to missing access controls. These aren't edge cases — they're the default output of a model that has never seen your users or your threat model.

The four security gaps in almost every Bolt app

1. API keys hardcoded in the frontend

When you ask Bolt to "integrate OpenAI" or "add Stripe payments," it often writes the key directly into frontend JavaScript — meaning anyone who opens DevTools can read it. Scrapers find exposed keys within hours of a deploy, and the bill arrives shortly after. One reported case had an OpenAI key scraped overnight, pushing the account bill up by hundreds of dollars before the owner noticed.

The fix: proxy every paid-API call through a server function (Netlify Functions or Supabase Edge Functions) and store the key in an environment variable that never ships to the browser. If you use Supabase, also watch for the service-role key — it bypasses Row-Level Security entirely and must never appear in client code.

2. Missing Supabase Row-Level Security

Bolt generates Supabase migration files that create your tables, but it frequently skips the RLS policies. The Supabase dashboard flags these tables with a yellow "RLS disabled" warning — a warning the model never sees. Without RLS, your anon key can read or write every row through the auto-generated REST API, not just the rows that belong to the logged-in user.

Enabling RLS is straightforward in the Supabase dashboard: turn it on per table, then add a policy that gates reads and writes to auth.uid() = user_id. Don't assume Bolt wrote those policies — open the dashboard and verify them yourself before you share the app.

3. Frontend-only authentication

Bolt often generates a login screen and a redirect, but skips the server-side check. If your route handlers or Edge Functions don't verify the session on the server, someone can bypass the login screen entirely by calling your API directly. The UI shows "only your data," but the API hands out everyone's.

• Verify the user session inside every server function — never trust the client to say who is logged in.
• With Supabase, use supabase.auth.getUser() on the server, not getSession(), which can be spoofed with a modified JWT.

4. No security headers

Bolt rarely adds Content-Security-Policy, Strict-Transport-Security, or X-Frame-Options headers. Without them, the door is open to cross-site scripting, clickjacking, and downgrade attacks. On Netlify you can add these in netlify.toml; on Vercel, under headers in vercel.json. Bolt won't prompt you to do this — you have to add them manually.

Bolt's built-in publish audit

Bolt now ships a free security audit triggered when you click Publish. It reviews your code and database for broken access control, secrets in code, and missing database policies, and it applies automatic fixes where it can. That's a real improvement over shipping blind.

The limitation: the audit runs only at publish time, only on what Bolt can see in its own context, and it won't catch issues that only appear in your live deployed URL — like a misconfigured CORS policy or an endpoint that opened up after a deploy. It's a useful first pass, not a final green light. The same caveat applies to Lovable's built-in checks — these tools catch the obvious stuff, but an external scan catches what they miss.

What an external scan catches that Bolt's audit misses

Trust scans a live URL using DAST — running 10,000+ Nuclei templates against your deployed app — and scans a GitHub repo for secret detection, static analysis, and dependency vulnerabilities. It sees things that are only visible from the outside: misconfigured headers, open redirects, and exposed endpoints that weren't open when you hit Publish but are now.

It also catches secrets that were committed to your repo at any point, even if they were removed later. If Bolt wrote an OpenAI key matching sk-, a Stripe live key matching sk_live_, or a Supabase service-role JWT into your codebase at any commit, it surfaces it. You can find the full list of detected secret patterns on the detectors page.

If you also develop in Cursor or Claude Code, you can wire Trust in as an MCP integration — same scanner, right inside your editor, so you can catch issues before they ever leave your machine.

Quick checklist before you share a Bolt app

1. Open DevTools → Network tab and confirm no API keys appear in requests or bundled source files.
2. Open the Supabase dashboard and verify RLS is enabled on every table that holds user data, with policies that scope rows to the current user.
3. Check each server function or route handler: does it re-verify the session server-side before touching the database?
4. Add security headers to your netlify.toml or vercel.json — Bolt won't do this automatically.
5. Run Bolt's publish audit, then run an external scan to catch what it missed.

Bolt makes app development genuinely fast — don't give up that speed. Just close the short list of predictable blind spots it ships with. Check the list, run the scan, and you'll know exactly what state your app is in before anyone else does.