Is Bolt.new Safe? What Its Security Audit Can and Cannot Prove

Bolt.new is a legitimate product with real security controls. Whether the app it built for you is safe is a separate question, and Bolt’s own audit cannot settle it.

The platform gives you hosting, a database, authentication, secrets, logs, and two security checks. Those are the right primitives. The published app still does not inherit a safety verdict from the platform, because its account permissions, data rules, payment logic, and expensive workflows live in the code and configuration generated for that one project.

One naming note first, because these brands get mixed up constantly. bolt.new is StackBlitz’s AI app builder and the subject of this article. bolt.com is an unrelated payments company that also publishes a security page, which is why a search for Bolt security often returns it. BoltAI is a separate desktop app. If you came here looking for passkeys and one-time login codes, you wanted bolt.com.

Bolt’s current security tooling is stronger than older descriptions of the product suggest. Every plan includes a database security check, and paid plans can run a whole-project security audit. The useful question is what those checks establish, what remains untested, and how to verify the boundary with the app you actually built.

Bolt.new security: what the platform checks

As of 6 August 2026, Bolt’s project security audit documentation describes two related checks:

1. Database security check: available on all plans, focused on database settings, permissions, and row-level security.
2. Project security audit: available on paid plans, covering the project’s code and database. It fixes some issues automatically and lists actions that need review.

The project audit looks for data-access mistakes, publicly exposed information, authentication and session problems, unsafe inputs, leaked keys, and security settings. Its business-logic checks also look for price manipulation, skipped workflow steps, and replayed actions. Bolt says these audits and their fixes do not use project tokens, with a current limit of 30 audit runs per day.

The audit is started manually from the Publish area. Run it on the version intended for release and review the resulting actions. Do not describe an old clean result as coverage for code or database rules that changed afterward.

The plan split is worth stating exactly, because Bolt’s two pages read differently at a glance. The database security settings page says its check is available on all plans and, in its own words, checks only your database and not your whole project. The whole-project audit, the one that reads your code as well, is the paid-plan feature. If someone tells you they ran Bolt’s security audit on a free plan, they ran the database half.

Bolt’s audit can succeed while some business behavior remains untested. The separate verification column covers account states and external-service behavior that a static or agentic review cannot establish for every project.

If you only have ten minutes, do these four things against the published app:

1. Open it in a private window and request a URL that should belong to a signed-in account.
2. Create a second ordinary account and put the first account’s record IDs into its requests.
3. Search the built browser bundle for your key prefixes and the names of your sensitive variables.
4. Call the endpoint that costs you money twenty times in a row and see whether anything stops you.

The full eight-step version is at the end of this article.

What Bolt’s security audit does not check

Bolt’s audit is genuinely useful and it is not a penetration test. These are the classes a clean result does not speak to, named the way you would find them in a report.

Missing security headers. Bolt’s documented audit categories cover credential storage and cross-origin settings, not the response headers your published app sends. A Content-Security-Policy limits which scripts a page may load. Strict-Transport-Security stops a downgrade to plain HTTP. X-Frame-Options, or CSP’s frame-ancestors, stops your app being framed inside someone else’s page for a clickjacking attack. Bolt does provision SSL certificates automatically for every connected domain, so published sites are served over HTTPS by default. HTTPS is transport. Headers are policy. Only the first one is handled for you.

Production source maps left enabled. A source map turns your minified bundle back into readable source, including internal function names, comments, and every API route the browser code touches. Build tools ship them because they make debugging bearable, and nobody turns them off before launch. Open dev tools on the published app and look at the Sources panel: if you can read your own component tree the way you wrote it, the maps shipped. That is not a vulnerability on its own. It is a map handed to whoever is looking for one, and a code audit reads your repository rather than what your build step emitted.

No rate limit on the endpoints that cost money. Generated apps almost never add one, because nothing in a demo asks for it. The endpoint that calls a paid model, sends an email, or renders a report will answer as fast as it is asked, forever.

Password policy and leaked-password protection. Bolt’s docs say the Prevent Leaked Passwords setting is on by default for Bolt databases and may be off or unavailable on a free Supabase plan. Confirm which state yours is in. Minimum length, lockout after repeated failures, and a limit on login attempts are separate settings again, and a scanner that reports the toggle cannot tell you whether your login route survives ten thousand guesses.

Authorization enforced only in the interface. This is the big one, and no static check can settle it. A hidden button, a disabled menu item, and a route guard in the browser are all suggestions. The server has to make the decision.

What Bolt’s own warning strings mean

The database check reports issues by name. These come up constantly and none of them explain themselves.

• Missing row-level security. The table has no policy at all, so access is decided by whatever key the request carried. With a public anonymous key, that generally means everyone.
• RLS Policy Always True. A policy exists and its condition is true for every row and every caller. It satisfies “RLS is enabled” and protects nothing. This is the most common way a generated app passes a policy check and still leaks.
• Overly open permissions. A role has been granted more on a table than the app needs, so the policy above it is doing all the work and a mistake in that policy has no second line of defense.
• Function Search Path Mutable. A Postgres function does not pin its search_path, so which schema a name resolves to can be influenced by the caller. It matters most in functions that run with elevated rights.
• Leaked Password Protection Disabled. The Prevent Leaked Passwords setting is off, so your users can choose a password that already appears in a public breach list.

Clearing all of them tells you the database configuration is sane. It does not tell you the policy compares the row to the right person, which is the check that decides whether one customer can read another’s data.

Does Bolt.new have SOC 2, GDPR, or HIPAA compliance?

As of 17 August 2026, I could not find a published SOC 2 report, ISO 27001 certificate, or HIPAA program from Bolt. Bolt’s current Privacy Policy applies to Bolt.new and the Bolt app. It describes GDPR rights and says customer-app data is governed by applicable customer agreements and data processing addenda. That is privacy documentation, not a compliance attestation. If a buyer needs an audit report or contract, write to security@bolt.new and keep the reply.

Two builders in the same category do publish. Lovable’s security page states SOC 2 and GDPR support and cites ISO 27001 in the context of its audit-ready reports. Base44’s trust center lists SOC 2 Type II, ISO 27001, and GDPR. Neither of them names HIPAA. The sourced versions of both sit in the Lovable safety review and the Base44 compliance breakdown, which also explain what each of those certificates actually covers.

Now the separation buyers get wrong. A vendor attestation covers the vendor’s own systems and processes inside a declared scope. It is an auditor’s opinion about how the vendor runs the vendor. Nobody in that audit looked at the ownership rule on your orders table, or at the server function your agent wrote yesterday. A Lovable certificate does not make a Lovable app safe either. The certificate answers one line of a questionnaire.

Here is the rest of that questionnaire, regardless of who built the app:

If you are selling into a regulated buyer or handling health data, a missing platform attestation is a genuine blocker and no amount of app-level testing substitutes for it. If you are selling to consumers or small businesses, the second column is what gets you through review, and all of it is within your control.

Are Bolt.new databases and authentication safe?

Bolt’s managed database includes authentication, logs, secrets, server functions, and security settings. Those are the right primitives for a secure application. The project still needs policies that match its ownership model.

An application can require a valid login and remain unsafe between customers. A policy such as “any authenticated user can read invoices” protects the table from logged-out visitors while allowing every customer to read every other customer’s invoice. The decisive test uses two ordinary accounts:

1. Create different records for account A and account B.
2. Capture account A’s real read, update, and delete requests.
3. Repeat them while authenticated as account B, substituting account A’s record identifiers.
4. Expect an authorization error or no returned rows.

Run the same test against storage objects and server functions, not only visible tables. A hidden button is not an authorization boundary, and changing an identifier in a direct request can reach code the interface never exposes. The class has a name worth knowing when you read a report: IDOR, an insecure direct object reference, also called broken object-level authorization. The step-by-step version of this test covers the request-capture part in more detail.

Generated backends fail this test constantly, because the version that produces a working demo and the version that produces a safe one read almost the same:

// Trusts whatever the client claims about itself:
app.get('/api/orders', (req, res) => {
  const orders = db.orders.findByUserId(req.query.userId)
  res.json(orders)
})

// Derives identity from the verified session instead:
app.get('/api/orders', requireAuth, (req, res) => {
  const orders = db.orders.findByUserId(req.session.userId)
  res.json(orders)
})

The first version passes every test a founder is likely to run, because your own test traffic always sends your own honest ID. It fails the moment a second account edits that same field and asks for someone else’s orders.

A disclosure before the numbers. My own audit tally sits at 26 apps built with AI tools, and exactly one of them was a Bolt.new export: a static dashboard with no backend or database at all. A Bolt-specific defect rate is not mine to give you honestly, because one thin app cannot stand in for the database-and-payments builds this question is really about. What I have instead is the shared mechanism, drawn from the third-party apps built on the generators that scaffold the same kind of project.

Across the fixed AxonBuild cohort of 21 third-party AI-built apps reviewed in June and July 2026, 9 had an RLS gap and 7 had a confirmed path where one signed-in user could read or change another user’s data. Those figures span multiple builders and do not estimate Bolt’s defect rate. They identify the behavior worth testing after any generated database policy. The full breakdown of that cohort shows how the rest of the findings distribute.

How Bolt.new handles secrets

Bolt’s secrets documentation places sensitive values in server functions and prompts the project owner to add the values rather than writing them into code. Use that path for payment, AI-provider, email, database-admin, and other privileged credentials.

Then test the boundary. Search the source and built browser assets for recognizable key prefixes and the exact names of sensitive variables. Inspect browser network responses, logs, prompt history, and Git history. If a real secret was ever committed or returned to the browser, remove it from the current code and rotate it at the provider. Deleting one copy does not invalidate copies already stored elsewhere.

A key compiled into a Vite bundle ships to the browser like every other line on the page, visible to anyone who opens dev tools.

Client-safe configuration is different. A public URL or the intentionally public anonymous key (the anon key) may need to reach the browser. The server must still enforce row policies, role checks, and privileged actions. Keeping a value out of the bundle cannot repair an endpoint that grants the caller whatever they request.

What changes if the project uses Supabase?

Bolt Database is the default for new projects, while Supabase remains an integration option. Bolt’s current Supabase guide warns that connecting a separate Supabase project to an app already using Bolt Database replaces the database connection and may cause data loss. For a current Bolt Database, the documented safer route is to claim that database in Supabase rather than attach a different project as though the data will merge.

Before any connection change, identify the database the deployed app currently uses, export or back up important data, and record the rollback plan. Afterward, verify row counts, authentication, storage, server functions, and one complete customer workflow against the intended database.

For Supabase projects, review both grants and row-level security. Supabase’s RLS documentation explains that policies are evaluated per table and that privileged views or functions need separate attention. Bolt’s database security check is a useful first pass. The two-account request remains the behavioral proof.

Is the Bolt.new build environment safe?

Bolt’s current product introduction says Bolt runs in the browser on StackBlitz WebContainers, with no local installation or development-environment setup required. That browser-based access model differs from installing an autonomous coding agent on the local computer.

That does not make every project input harmless. Treat imported repositories, packages, scripts, and third-party integrations as code with their own permissions and supply-chain risks. Review what a script is allowed to read, which credentials exist in the project, and which external services receive data.

It also does not settle the published app’s security. Bolt Hosting runs the output for real users, while the WebContainer describes the editing and preview environment. Keep those trust boundaries separate when answering whether Bolt is safe.

Does Bolt.new train on your code, and what happens to your data?

Bolt’s current Privacy Policy gives a qualified answer. It says Bolt processes prompts, code, configuration files, and generated output. It may use aggregated, anonymized, or de-identified AI inputs and outputs to improve the service. The ability to limit or opt out of model training or improvement depends on the account type or plan. Attached files may be sent to third-party AI providers to generate a response.

The same policy says active-account content is retained while the account remains active. After voluntary account closure, Bolt says it deletes or anonymizes associated data within 30 days, subject to backup retention, legal duties, and security requirements.

The public policy does not identify which plans expose the opt-out, give a fixed lifetime for backup copies, or state the encryption and breach-notification terms a buyer may need. If real customer personal data is going through a Bolt project, review the applicable DPA and put those remaining questions to security@bolt.new before launch. Keep the written answers.

One part of this you control today: what you feed it. Prompts, pasted logs, and imported repositories all become project content. Keep production dumps, real customer records, and live credentials out of them whatever the retention answer turns out to be.

Do you own the app, and what happens if Bolt shuts down?

Treat this as a security question rather than a product-review question, because continuity of access is a security property. If the only running copy of your customers’ data sits behind one vendor’s login, an outage, a billing lapse, or a company failure becomes an incident with your name on it.

The mechanical part is straightforward. Bolt’s GitHub integration commits your work automatically as you build and checks the repository every thirty seconds for changes made outside Bolt, so the source can live in a repository you own rather than only inside the editor. That documentation covers code. It does not cover the database, and code is the easy half. A repository full of components restores nothing without the schema, the row policies, the storage objects, the secrets, and the rows themselves. Bolt’s terms of service are not part of its help center, so if the legal ownership question is going into a contract, get it answered in writing rather than inferred from a GitHub button.

The published app is a third dependency. If it runs on Bolt Hosting against Bolt Database, then Bolt staying up is a hard requirement for your app staying up, no matter who owns the repository.

Run the continuity test once, before you need it: clone the repository onto a clean machine, restore an export of the database into one you control, and run the app as a real user against your own environment. The full step-by-step, database and all, is migrating off Bolt.new; a continuity plan you have never executed is a hypothesis.

When a token bill is a security bug

Most public complaints about Bolt are about cost rather than breaches, and it is tempting to file those under a different heading. Some of them belong here.

An endpoint in your published app that calls a paid model, sends an email, generates an image, or runs a report is an endpoint that spends your money on demand. If it does not check who is calling and does not limit how often, anyone who finds the URL can spend your budget for you. That is a missing authorization check. It arrives as an invoice instead of a data leak, and it is the same defect either way. The version that empties your API budget overnight and the version that hands a stranger another customer’s orders are the same missing line of code.

Bolt’s audit documentation names abuse and unintended user actions among the things it looks for. Treat that as a prompt to test, not as a result. Call every metered action while logged out. Call it fifty times in a row as an ordinary user. If nothing refuses you, the limit does not exist and neither does the authorization. The same reasoning covers paid features that only a browser-side check is guarding.

Cost complaints are worth reading for that reason, and they are most of what people post about Bolt in public.

What Bolt’s Trustpilot score measures

Bolt’s customer rating answers a different question than any of the above, and it’s worth taking on its own terms rather than folding into “safe.” As of early August 2026, bolt.new sat at 1.5 out of 5 across 195 Trustpilot reviews, labeled “Bad”; recheck the current figure before quoting it. Read the complaints and a pattern shows up fast: token consumption that burns through a subscription mid-project, an error loop that spends the same tokens twice fixing what it just broke, hosting that drops a site at the wrong moment. Real grievances, worth knowing before you buy a plan. None of them touch whether the app Bolt hands you checks who’s allowed to see a row before returning it. A reputation score measures whether paying customers had a good experience; a security question asks whether the app verifies ownership before handing back data. The two don’t move together, and collapsing them cuts both ways.

How Bolt’s pre-publish checks compare with v0 and Lovable

What separates the platforms in this category is what each one does, if anything, before your build goes live:

Vercel’s own account of v0’s launch check, published August 2025, puts a number on the middle row: over 100,000 insecure deployments blocked since the check launched, 17,000 in a single month for exposed secrets alone. None of the three checks correctness, which is what actually decides whether an app is safe. v0’s block-on-secrets is the most proactive at the moment you ship, and it still can’t tell you whether the RLS policy it left alone compares the row to the right person. Lovable’s scan confirms a policy exists without reading what it says. Bolt’s audit is the most detailed of the three on paper, and it only runs when someone remembers to start it.

A practical Bolt.new safety test

1. 01 Run the database security check and, on a paid plan, the full project security audit against the exact release candidate.
2. 02 Review every action item and rerun the relevant check after changing authentication, database policies, server functions, dependencies, or payment logic.
3. 03 Create two ordinary accounts and repeat each account-sensitive read, update, delete, file, and function request across the account boundary.
4. 04 Call sensitive and metered server actions while logged out, then repeat them rapidly enough to verify the intended quota or rate limit.
5. 05 Search source, browser bundles, responses, logs, prompts, and Git history for privileged credentials, and rotate any value that crossed the server boundary.
6. 06 Change price, plan, role, user, and workflow-state values in direct requests. The server should derive or verify each security-sensitive value.
7. 07 If connecting Supabase, confirm which database is active before and after the change, protect the existing data, and test authentication and a complete workflow.
8. 08 Record the audit date, release identifier, account tests, and unresolved decisions so the result can be rerun after a material change.

Why AI coding tools ship security holes explains why authentication, authorization, quotas, and payment verification are easy to miss when generation is optimized around the happy path. The broader AI app security guide covers threat boundaries that apply regardless of builder.

Common questions about Bolt.new safety

Is Bolt.new legit?

Yes. Bolt.new is a functioning StackBlitz product with documented hosting, database, authentication, secrets, logging, and security-audit features. Product legitimacy does not certify the security of every generated project, so evaluate the platform controls and the app’s behavior separately.

Is Bolt.new safe to use?

Bolt provides meaningful security controls, including an all-plan database check and a paid whole-project audit. Use them, keep privileged values in server-side secrets, and verify account isolation and business rules with real requests. The result is specific to the project and release you tested.

Is Bolt.new trustworthy?

As a vendor, yes on the evidence available: it is a StackBlitz product with documented hosting, database, authentication, secrets, logging, and two security checks. Its current Privacy Policy describes AI-content use, plan-dependent opt-out availability, third-party AI processing, and account-closure retention. It does not supply a public compliance report. Most public complaints about Bolt are about cost rather than breaches.

The trust that matters for your customers is a different question again, and the platform cannot answer it for you. A trustworthy builder can still generate an app whose row policy compares nothing, and the two-account test in this article is what settles that.

Is Bolt.new SOC 2 compliant?

No published SOC 2 report was findable as of 17 August 2026. Bolt’s Privacy Policy is not a compliance report. Read that as “not published” rather than “does not exist”, and write to security@bolt.new for an answer you can show a buyer. A builder’s SOC 2 report would cover Bolt’s own systems in any case, never your app’s access rules.

Does Bolt.new train on my code?

Bolt’s Privacy Policy says it may use aggregated, anonymized, or de-identified AI inputs and outputs to improve the service. It says the ability to limit or opt out of model training or improvement depends on the account type or plan. The public page does not identify those plans, so confirm the setting available to your account before putting customer personal data into a project.

Does Bolt.new expose API keys?

Bolt provides server-side secrets for server functions, which is the correct place for privileged credentials. Exposure can still occur if generated or edited code sends a value into browser code, a response, a log, a prompt, or Git history. Search those locations and rotate any credential that was exposed.

Does Bolt.new set security headers for my app?

Bolt automatically provisions SSL certificates for connected domains, so published apps are served over HTTPS by default. Response security headers are a separate layer, and Bolt’s documented audit categories cover credential storage and cross-origin settings rather than Content-Security-Policy, Strict-Transport-Security, or X-Frame-Options. Check your published app’s response headers yourself and add the ones it needs.

Does Bolt.new automatically run a security audit before publishing?

Bolt documents the project security audit as a manual action in the Publish area. Run it on the release candidate rather than assuming a previous or automatic result covers the current build. The database security check is available on all plans; the whole-project audit requires a paid plan.

Do I own the code Bolt.new generates?

Bolt’s GitHub integration commits your project to a repository you control as you build, which is the practical form ownership takes: you can clone the source and run it somewhere else. That covers code only. The database schema, row policies, storage objects, and rows are a separate export, and the published app’s dependence on Bolt Hosting is separate again. Bolt’s terms are not part of its help center, so confirm the legal answer in writing if it matters to a contract.

What happens to my app if Bolt.new shuts down?

If your app runs on Bolt Hosting against Bolt Database, Bolt staying up is a hard requirement for your app staying up. Reduce that exposure by keeping the source in your own GitHub repository, exporting the database schema, policies, and data on a schedule, and proving once that a clone plus a restored database actually runs outside Bolt. A continuity plan you have never executed is a hypothesis.

Is Bolt.new safe for production?

Safety is one part of production readiness. This article establishes how to assess the platform and the app’s security boundary. A production decision also needs evidence for monitoring, payment lifecycle, deployment, load, and recovery, which belong to a separate production-readiness assessment.

Is Bolt.new the same as Bolt the ride-hailing app?

No, and they share no owner. Bolt.new is StackBlitz’s AI app builder, the subject of this article. The ride-hailing Bolt is operated by Bolt Technology OÜ, an Estonian company at bolt.eu that describes itself as a European mobility super-app covering rides, scooters, car sharing, food delivery, and business travel, checked 16 August 2026.

Three unrelated companies use the name, which is why searching for Bolt security returns answers to a question you did not ask. bolt.com is a payments company and publishes its own security page. BoltAI is a separate desktop app. When you search, type the .new: everything on this page is about that one product and none of it applies to the other three.