Bolt app security: what to check before you publish

Abstract render of a database as stacked glass rows, each covered by a glowing orange shield layer

By the FixMyVibe team · Last reviewed 16 October 2026

A Bolt app with a Bolt Cloud or Supabase database lets visitors send requests to that database directly, so row-level security (RLS) policies decide what they can read and change. Before launch, make sure every table has RLS on with policies scoped to the right users, and that private API keys live in Secrets and server functions, never in frontend code.

Scan my repo free (read-only)See an example report

How a Bolt app handles data

New Bolt projects use a built-in Bolt database by default; on paid plans you can use Supabase instead or claim the Bolt database into your own Supabase account. Bolt's own documentation puts the key point plainly: anyone who visits your site can send requests to your database directly, without using your site's screens. RLS is what decides which rows those requests can read or change.

The typical risks

1. Policies that let every visitor in

Bolt's docs say that if you haven't asked Bolt to add sign-in, it might write policies that allow any visitor to view, add, change and delete the data. Its Security Audit flags these as RLS Policy Always True. That can be fine for truly public data; for orders, profiles or messages it is a leak.

2. Tables you added yourself

Bolt turns on RLS for the tables it creates. For tables you add, Bolt's docs tell you to turn RLS on yourself: a table without RLS can be read and changed by anyone.

3. Secret keys in frontend code

Bolt stores private keys as Secrets that only server functions read, so they never reach the browser. Problems start when a key is pasted into the code instead. If your project uses Vite, note that every variable prefixed with VITE_ is bundled into the client code and readable by anyone. See leaked API keys.

4. Only checking the database

Bolt's Security Audit page checks only your database, not your whole project. Run Bolt's project security check on the code as well.

What the free FixMyVibe scan checks

Paste the URL of a public GitHub repository. The free scan reads the code read-only on a temporary copy that is deleted afterwards, and looks for:

  • Hardcoded secrets in the current files: API keys, tokens, Supabase secret/service_role keys, private keys, and secrets exposed through NEXT_PUBLIC_/VITE_ variables or committed build output.
  • Supabase database rules in your committed SQL migrations: tables without RLS, USING (true)/WITH CHECK (true) policies, policies that trust user_metadata, and similar patterns.

What it does not do: it does not scan your git history (only the current files), it does not connect to your database or your live Bolt app, and it cannot see private repositories. Dependency checks against the OSV vulnerability database are part of the paid audits, not the free scan. It is an automated code scan, not a penetration test.

Pre-launch checklist

  1. Open the database Security Audit in Bolt and resolve every warning, including each 'RLS Policy Always True' you did not intend.
  2. Confirm RLS is on for every table, especially tables you created yourself.
  3. Make each policy match the data: owners only for private data, read-only for public content.
  4. Run Bolt's project security check on the code.
  5. Move every private key into Secrets and call it from a server function; search the code for keys and VITE_ variables holding secrets.
  6. Connect the project to GitHub and run an independent scan of the repository.
  7. Test the app logged out and as two different users.
Scan my repo free (read-only)See an example report

FAQ

Does Bolt turn on RLS for me?

Bolt's documentation says it turns on RLS for the tables it creates, and that you need to turn it on yourself for any table you add. RLS being on is not the whole story: the policies also have to limit each user to the right rows.

What does the 'RLS Policy Always True' warning mean?

Bolt's docs explain that it flags a policy with no conditions limiting who can access a row. If you haven't added sign-in, Bolt might write policies that let any visitor view, add, change and delete data. That is only acceptable if you're fine with every visitor doing exactly that.

Is Bolt's Security Audit enough?

Bolt's database Security Audit checks only your database, not your whole project; Bolt has a separate project security check for the code. Use both. A second, independent scan of the code is a cheap extra check, but neither is a penetration test.

Where do API keys go in a Bolt app?

In the database Secrets settings. Bolt's docs describe secrets as values your server functions read so private keys never end up in your users' browsers, and advise never storing secrets in plain text in your code.

Can FixMyVibe scan my Bolt project?

Yes, if the code is in a public GitHub repository. Bolt can connect a project to a GitHub repo and sync commits. The free scan does not connect to your Bolt database.

Sources

FixMyVibe is an automated code scan, not a full penetration test, and cannot guarantee that an app is secure. What happens to your code during a scan: see our privacy policy.