Bolt Database features (auth, secrets, server functions, security audit) are documented under Bolt Cloud. The docs do not state which frontend framework new projects use by default.
Bolt runs in the browser and generates JavaScript web apps. When a project needs a database, Bolt creates a Bolt Database with built-in authentication, secrets kept in server functions, and publishing to a bolt.host URL by default.
Bolt's docs describe a project security audit and a database security audit that flag missing row-level rules and always-true policies. The checks below cover what those audits do not: how your app's logic behaves with a second account, what the bundle reveals, and how the Stripe integration handles webhooks and plans.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| Frontend | Bolt supports JavaScript-based web technologies: Node.js backends and any JavaScript framework that runs in the browser. PHP or Python backends are not supported. | docs · verified 2026-09-21 |
| Backend / database | Bolt creates a Bolt Database automatically if the project needs one, unless you ask for local storage instead. Supabase can be selected at project setup as an alternative. | docs · verified 2026-09-21 |
| Auth | Bolt Database includes built-in authentication management for adding user sign-up, plus user management and file storage settings. | docs · verified 2026-09-21 |
| Hosting | New projects publish with Bolt hosting by default to a random bolt.host URL. On the free plan all published sites are public and indexable; paid plans can choose private. Netlify is an alternative target. | docs · verified 2026-09-21 |
| Secrets / env vars | Secrets live in the Bolt Database Secrets tab and are read by server functions at run time so that, per the docs, private values do not end up in users' browsers or devices. | docs · verified 2026-09-21 |
| Source access | GitHub integration: the repository starts private on a main branch; Bolt commits automatically and pulls outside changes every 30 seconds. Only the project owner can manage the integration. | docs · verified 2026-09-21 |
| Database access rules | The database Security Audit reports missing RLS policies and RLS policies that are always true. Leaked password protection is on by default for Bolt databases. | docs · verified 2026-09-21 |
| Payments integration | Stripe integration creates Supabase edge functions for checkout session creation, webhook processing and subscriptions; the docs state webhook registration and signature verification are handled automatically. | docs · verified 2026-09-21 |
Documentation home: support.bolt.new/
46 patterns in the catalogue name Bolt; the most severe are listed here across secrets and keys, data access, login and permissions, payments, ai features. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
Signed-out visitors or other customers can read rows meant for one account, while the owner sees an empty page and nobody notices.
Anyone who creates a free account can page through every other customer's records, which is a data breach with a sign-up form as the only step.
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
The table looks protected in the dashboard, yet any visitor with the public anon key can read, insert, update and delete every row.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone who reads the code or guesses a common placeholder can sign in as the administrator.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Anyone who finds the webhook URL can post a made-up payment-succeeded event and get an order fulfilled or a plan activated for a user of their choosing, without paying.
Anyone who views the page source can copy the key and run their own workloads on your account until the bill or the provider stops them.
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
A scan of 1,645 Lovable-built apps found 170 (about 10.3%) with database endpoints readable without login because Supabase row-level security policies were missing or too broad; recorded as CVE-2025-48757, CVSS 9.3.
May 2025 · Matt Palmer (Replit, Inc.) · all sources
Moltbook, a social network for AI agents built with AI-generated code, ran a Supabase database without row-level security policies, leaving 1.5 million API tokens and 35,000 email addresses readable and writable without login.
Feb 2026 · Wiz Research · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
Project security audit
Reviews who can see and change data, what the app makes public, sign-in handling, misuse paths such as changing a price, accepted input, and keys and settings. Up to 30 audits per day, and the audit button does not use tokens on paid plans.
Where it stops: The docs recommend running it at least once before publishing; it skips checks that do not apply and does not state exclusions beyond that.
vendor docs · verified 2026-09-21
Database security audit
Available on all plans; finds missing RLS policies, always-true policies, mutable function search paths and disabled leaked password protection.
Where it stops: The docs state this page checks only the database, not the whole project or its code.
vendor docs · verified 2026-09-21
Secrets in server functions
Secret values are hidden as you type and are read only by server functions when they run.
Where it stops: Covers values stored as secrets; the docs do not describe checks for values placed elsewhere in code.
vendor docs · verified 2026-09-21
Version history
Restore a previous point in the project from version history.
Where it stops: Version history does not support Supabase database restores, and there is no supported flow to migrate a Supabase database into Bolt Database.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env files, list every variable whose name starts with NEXT_PUBLIC_.NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script..env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.service_role and then for sb_secret_.supabase.co, and read the apikey header under Request Headers.Bolt pre-launch checklist
46 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your app and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
A Bolt app inherits the security posture of its database rules, its server functions and its published URL. Check that every table has row-level rules, that secrets live only in the Secrets tab and never in frontend code, and that server functions verify the caller. Bolt's built-in audits report the first item; an independent test covers the rest.
We test a Bolt app from the outside with two accounts: read the JavaScript bundle for keys, call the database API as a stranger and as each user, probe server functions and payment webhooks. Findings come with a fix direction that works inside Bolt's chat.
Run Bolt's database security audit, then the self-check on this site. If tables show missing or always-true rules, fix those first. Then a security sweep confirms the fixes hold against a real second account.