Bolt.new Security Audit

By Jai Mittal, CTO · Launch Ready Code · August 18, 2026

The vulnerabilities described here align with the OWASP Top 10, the industry-standard list of the most critical web security risks, and MITRE CWE Top 25. Severity uses CVSS v3 scoring from NIST's National Vulnerability Database.

Auth middleware gaps, exposed credentials, rate limiting, and missing security headers — what Bolt builds and what it leaves unconfigured.

Why Do Bolt.new Apps Need a Security Audit?

Bolt.new is designed to get a working application in front of users as fast as possible. That goal is in direct tension with security configuration, which slows down the build loop and produces no visible output. The result: Bolt generates a deployable app, and the security layer is simply not there.

This is not a criticism of Bolt.new. It is the expected behaviour of any AI code generator optimised for speed. The problem is that many founders deploy without running any audit, assuming the generator handles security automatically. It does not. For a complete pre-launch checklist, see our Bolt.new security guide or the deeper Bolt.new security audit guide.

What Does a Bolt.new Security Audit Check?

Every audit covers four dimensions. Each maps to a specific set of checks with documented severity scoring.

Security

The largest dimension. Checks every protected API route for authentication middleware, scans the client bundle and Git history for committed secrets (API keys, service_role keys, database credentials), verifies that rate limiting exists on /login, /signup, and /reset-password, confirms CSRF protection on state-changing routes, and validates HTTP security headers — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Strict-Transport-Security. Input validation checks confirm that server-side validation exists, not just client-side form logic.

Reliability

Bolt-generated code often has happy-path error handling and no fallback for service failures. Reliability checks cover: uncaught promise rejections that crash the server process, missing try/catch around database queries, no graceful degradation when Supabase or external APIs are unavailable, and error responses that leak stack traces, internal file paths, or database schema to the browser.

Performance

AI code generators are prone to N+1 query patterns — a loop that makes one database call per item instead of a single bulk query. Performance checks include: N+1 query detection, missing database indexes on foreign keys and columns used in WHERE clauses, oversized JavaScript bundles from unoptimised dependency imports, and synchronous blocking operations on the request thread.

Monitoring

The most commonly skipped dimension. Bolt apps frequently ship to production with no error tracking, no uptime monitoring, and no alerting. Monitoring checks confirm whether an error tracking integration (detected by outbound request signatures) is present and configured, whether uptime checks are in place, and whether logging captures enough context to debug production incidents without attaching a debugger.

What Bolt.new Builds vs. What It Leaves Unconfigured

The distinction between what Bolt generates and what it skips is where every security finding lives.

What Are the Most Common Bolt.new Findings, Ranked by Severity?

What Is CVE-2025-48757, the Database Exposure Class That Affects Bolt Too?

CVE-2025-48757 is frequently cited as a Lovable vulnerability. The root cause — Supabase tables with RLS disabled — is equally present in Bolt-generated apps. Bolt creates Supabase schemas without enabling row-level security. The Supabase anon key is present in the client bundle. The result is identical: a direct GET request to the Supabase REST endpoint returns all data in unprotected tables, with no authentication required.

170+ apps across vibe-coding platforms were found to be exposing user data through this class of misconfiguration. Bolt apps using Supabase are in the same exposure category as Lovable apps and apps built directly against Supabase.

The SQL to check your Bolt app's RLS status in Supabase:

-- Check your Bolt app's Supabase RLS status:
SELECT schemaname, tablename, rowsecurity
FROM pg_tables WHERE schemaname = 'public'
ORDER BY rowsecurity, tablename;

-- Any row showing rowsecurity = false is publicly accessible
-- Fix: ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

For a fully automated check, use the free Supabase RLS Checker — enter your Supabase project URL and get a table-by-table RLS status report in seconds.

How to Run a Bolt.new Security Audit?

Three options depending on how much depth you need.

Option 1 — Free Launch Readiness Score

URL-based scan. No code access, no signup required. Enter your app's URL at launchreadycode.com and get a Launch Readiness Score out of 100 in under 60 seconds. The score covers all four dimensions and flags the highest-severity findings. This is the right starting point before launch.

Option 2 — Launch Readiness Audit Report ($499, One-Time)

The full diagnostic. All findings, each with CVSS v3 severity, file-and-line references, and a specific recommended fix. Every finding gets a senior AI (Opus) final review before the report is delivered — in under 2 minutes. Includes a prioritised fix roadmap with time estimates, a benchmark comparison against the vibe-coded apps we've audited, and a branded PDF report. The LRA is the definitive answer to "what does my Bolt app actually need to be production-safe?"

Option 3 — Manual Supabase RLS Check

If your most urgent concern is the CVE-2025-48757 class of database exposure, run the SQL above in your Supabase SQL editor. Any table showing rowsecurity = false is world-readable. Fix: ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; then write owner-scoped policies. This addresses one P0 finding — a full audit covers the other seven patterns in the findings table.

What's on the Pre-Launch Security Checklist for Bolt.new Apps?

Six steps that address the most common critical and high-severity findings before your app reaches real users. The same failure modes turn up in Copilot-generated code and in Claude Code output flagged by CVE-2025-66032 — AI code generators share this blind spot regardless of which one wrote the code.

• Add auth middleware to every protected API route. Verify the JWT on the server, not the client. A missing check on one route is sufficient to expose all users' data.
• Move all secrets to server-side environment variables. Search your bundle: grep -r "sk-\|service_role\|secret" ./dist ./public 2>/dev/null. Rotate any key that was ever in a client file.
• Enable Supabase RLS on every table and write owner-scoped policies. Run SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; — every false is a public database. CVE-2025-48757 class.
• Add rate limiting to /login, /signup, /reset-password, and any AI or payment endpoint. Use a middleware package (express-rate-limit, upstash/ratelimit) or your hosting platform's built-in rate limiting.
• Set HTTP security headers. Four headers that block the most common attack classes: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security: max-age=31536000.
• Add error tracking and uptime monitoring. An error tracking integration takes 15 minutes to configure and means you know about failures before customers do.

Frequently Asked Questions

Is Bolt.new secure?

Bolt.new is a capable builder that generates production-deployable applications. It does not configure the security layer: authentication middleware, rate limiting, CSRF protection, HTTP security headers, and server-side input validation require manual implementation after Bolt generates the code. The Cloud Security Alliance documented 20 security incidents in AI-powered applications in February 2026 alone. All of these gaps are standard hardening steps, fixable once identified.

What does a Bolt.new security audit check?

An LRC Bolt.new security audit covers four dimensions: Security (auth middleware, credential exposure, CSRF, rate limiting, HTTP headers, input validation), Reliability (error handling, uncaught exceptions, graceful degradation), Performance (N+1 queries, missing indexes, bundle bloat), and Monitoring (error tracking, uptime checks, alerting). Methodology: OWASP Top 10, CWE Top 25, CVSS v3 severity scoring.

What are the most common Bolt.new security issues?

In order of severity: missing authentication middleware on API routes (P0), credentials in the client bundle or Git history (P0), Supabase RLS disabled — the CVE-2025-48757 class (P0), no rate limiting on auth endpoints (P1), CSRF protection absent (P1), HTTP security headers not configured (P1), server-side input validation missing (P2), no production error tracking (P2).

Does Bolt.new need a database security check?

Yes. Bolt apps that use Supabase have the same RLS exposure as Lovable apps. Supabase ships with RLS disabled by default on every table. Bolt-generated schemas do not enable it. Any user with the public anon key — which is in the client bundle by design — can read all data in unprotected tables. Use the free Supabase RLS Checker or run SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; directly in your Supabase SQL editor.

How much does a Bolt.new security audit cost?

A free Launch Readiness Score is available at launchreadycode.com — URL-based, no signup, 60 seconds. The full Launch Readiness Audit Report is $499 one-time, 100% agent-delivered with a senior AI (Opus) final review on every finding, in under 2 minutes. Ongoing monitoring starts at $149/month. Code Care DFY Technical Setup ($1,999 setup fee + $2,999/mo) implements every fix with a named Fractional CTO reviewing every change before it merges.

Sources: CVE-2025-48757 (NVD / Matt Palmer, May 2025); Cloud Security Alliance AI Application Security Report, February 2026; OWASP Top 10 2021; CWE Top 25 2024; Supabase documentation. This page provides general security guidance, not a certification or guarantee.