Is my Bolt app secure? A plain check before you launch

01

Run Bolt’s own security checks first

Bolt has two checks worth running before anything else.

• The project security audit (paid plans). Click Publish, then Run security audit. Bolt’s help page says it reviews who can see and change your data, what your app makes public, how people sign in, ways the app can be misused, the input it accepts, and whether private keys sit in your code or get sent to browsers. It fixes most problems on its own and lists anything it can’t fix under a “Needs your action” heading. Use the button rather than asking in chat: the button doesn’t cost tokens, and a prompt does.
• The database security check (all plans). Click the database icon at the top of your project, then Security. Bolt says this page uses the same checks as Supabase’s Security Advisor and lists the most serious issues first. If a warning’s name means nothing to you, the Supabase advisors docs explain each one.

Bolt’s July 2026 announcement recommends running the audit on every publish, “because the risky change is usually the one you made at 2am.” We’d add one habit: read the summary of what it changed. If a fix breaks something, version history can take you back, but that undoes the security fix too, so describing the problem in chat is usually better.

Two warnings deserve a moment. RLS Policy Always True means a rule lets anyone through. Bolt flags it on every project, even where public access is intended, so don’t panic and don’t dismiss it. That is check 2. Leaked Password Protection Disabled means people can sign up with a password already seen in a data breach. It is on by default for Bolt databases, but Bolt’s authentication page says it is off, and unavailable, if you connected or claimed a Supabase project on Supabase’s free plan.

02

Decide who each table is for

This check needs no tools, and it is the one we would least like you to skip. A scan can tell you a rule exists. It can’t know that your orders table should only ever show customers their own orders. Only you know that.

Open your list of tables (database icon, then Tables, or Table Editor in the Supabase dashboard) and, for each one, pick one of the three answers Bolt’s database security page suggests:

• Visitors can only view it. A portfolio, a menu, blog posts. Anyone may read, nobody outside may add, change or delete.
• Visitors can submit to it. Contact forms, waitlists, reviews. Anyone may add a row, but nobody may read what other people sent.
• It has to stay private. Orders, messages, profiles, anything with an email address in it. Bolt is clear that rules can only limit data to specific people when your site knows who each visitor is, so this needs sign-in.

Then ask Bolt to make the rules match. These two prompts come straight from Bolt’s docs, and you can adapt the table names:

Check that row-level security is on for every table in my database, and that each policy allows only the access my site needs.

Add email sign-in to my site. Then update the policies for the orders table so only signed-in people can view, add, change, or delete their orders.

If you add sign-in, Bolt’s authentication page notes that projects start with localhost:3000 as the Site URL. Bolt usually updates it when you publish, but if reset or confirmation links send people somewhere odd, look there first.

03

Ask your database for data as a stranger

Now test what you decided. Open your live app in Chrome, open DevTools, and go to the Network panel. Reload and click around so the app loads some data, then type rest/v1 in the filter box. Each request is your app asking the database for something. Click one: the address starts with your project URL, and under Headers there is a request header called apikey. That is your public key.

Now ask for one row the way any visitor could, from a terminal:

curl -s "https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY"

Try it for every table you marked private in check 2. Real rows from a private table mean anyone on the internet can read it right now, and that is the thing to fix first. An empty list, [], means the rules filtered everything out or the table is empty. An error about permissions is also fine, if that is what you intended.

This only tests reading, on purpose. Don’t test writes by changing or deleting things on your live app. Read the rules instead. Supabase’s row level security docs say a table without RLS “is readable and writable by any role with a grant on it,” and that a rule saying using (true) for anonymous visitors hands every row to every stranger. Look for those, and check the rules for adding, changing and deleting too.

Last, the test no scanner can do for you. Make two accounts. Signed in as the second, try to open something that belongs to the first, for example by putting its order ID into the address bar. You should see nothing of theirs. This catches a rule that is switched on but too loose.

If this pattern sounds familiar, it is the same one behind CVE-2025-48757, which was about Lovable apps. Different builder, same database, same lesson.

04

See which keys your page carries

Your page should carry one key: the public one. Supabase’s API keys guide calls the publishable key (it starts with sb_publishable_) safe to expose in a web page, because it only reaches what row level security allows. Older projects use the anon key, a long string starting with eyJ, for the same job. The secret key (sb_secret_) and the older service_role key bypass row level security completely and must never reach a browser.

Look at the apikey header from check 3. If it starts with sb_publishable_, good. If it starts with eyJ, decode it in the Console tab of the same DevTools window to see which role it carries:

// Paste into the Console of your own browser. The key never leaves your machine.
const key = "PASTE_THE_KEY_HERE";
JSON.parse(atob(key.split(".")[1].replace(/-/g, "+").replace(/_/g, "/"))).role;
// "anon" is the public key. "service_role" means stop and read on.

Then look for anything that shouldn’t be there. Bolt’s introduction to databases names the usual settings VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY, and that prefix matters. Vite’s docs say anything starting with VITE_ is bundled into the code visitors download and should not hold secrets like API keys. Supabase says of its server-only keys: “Never prefix these, or your bundler will ship the key.” So VITE_SUPABASE_ANON_KEY is fine, while VITE_OPENAI_API_KEY would be public the moment you publish.

To search your live site, press Ctrl+Shift+F in DevTools (Cmd+Option+F on a Mac) to open the Search panel, which looks through every file the page has loaded. Try each of these, plus the name of every service you gave a key to:

sb_secret_
service_role
sk_live_
sk-proj-
sk-ant-
secret

Code that only loads on certain screens won’t show up until you visit them, so click through first. For a thorough look, download your project from Bolt and search the built files on your computer. We ran these commands on a Vite test app with fake keys: the last line found the fake Stripe secret we had prefixed with VITE_, and the unprefixed one never reached the build.

# Inside the project folder you downloaded from Bolt
grep -n "^VITE_" .env
npm install
npm run build
grep -rnoE "sb_secret_[A-Za-z0-9_-]+|sk_live_[A-Za-z0-9]+|sk-[A-Za-z0-9_-]{20,}|service_role" dist

Vite builds into a folder called dist; if yours differs, use that name. Treat any real-looking key as public already. Move the code that needs it into a server function, keep the key in Bolt’s Secrets so, in Bolt’s words, “private information never ends up in your users’ browsers,” then revoke the old key and make a new one. Our guide to leaked API keys in your frontend bundle covers the order to do this in, plus a script that checks every file your live site serves.

05

Make your server functions ask who is calling

Server functions do the work that needs a secret: payments, emails, AI calls. Being on a server makes them safer, not private. Anyone can call a function’s address directly, so the question for each one is what happens when a stranger does.

Bolt’s troubleshooting guide says server functions expect authenticated requests by default. There is a catch. Supabase’s docs on authorization headers explain that this platform check also lets through a caller who only sends your public key, and say plainly that “the check alone doesn’t authenticate a caller that sends only an API key.” Your public key is in your page, so the default check keeps out people who don’t look, not people who do.

That matters most for functions that cost you money or touch other people’s data. A chatbot function that forwards whatever it receives to OpenAI would happily spend your credits for a stranger. A function that reads from your database with the admin client is worse: Supabase’s guide to securing functions warns that one which doesn’t filter by the caller’s ID “returns every user’s rows.”

To test one as a stranger, find its address in the Network panel (filter for functions/v1) and call it with only the public key:

curl -i -X POST "https://YOUR-PROJECT.supabase.co/functions/v1/YOUR-FUNCTION" \
  -H "apikey: YOUR_PUBLIC_KEY" \
  -H "Authorization: Bearer YOUR_PUBLIC_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

This really runs the function, so pick one that is cheap to run, or use a copy of your project. A function meant for signed-in users should refuse with a 401 or similar. If it sends an email, returns data, or answers like your chatbot, ask Bolt to make it check that the caller is signed in and allowed to do this, then test again.

One exception is expected. Webhooks from services like Stripe can’t send a sign-in token, so Bolt’s troubleshooting guide tells you to turn off that check for the webhook function and “add your own checks inside the server function”, such as verifying the provider’s signature. If you used Bolt’s built-in Stripe integration, Bolt says it handles webhook signature verification for you. If you wired up a webhook some other way, ask Bolt in Plan mode whether it verifies the signature.

06

Look at your file storage

Uploaded files, like avatars, invoices, or ID scans, live in storage buckets, and every bucket is either public or private. Bolt’s file storage page puts it simply: files in a public bucket can be seen by “anyone with the link, even if they’re not signed in to your app.” Supabase’s bucket docs add that a public bucket skips access control for downloading files altogether, while uploads, deletes and moves are still checked against your rules.

Public is right for product photos and logos, and wrong for anything a customer would hate to see on a stranger’s screen. Bolt says it is designed to make private buckets for user uploads, and also to “always confirm a bucket’s visibility yourself.” If a bucket of private files is public, Bolt’s docs suggest asking it to keep the bucket private, let each user see only their own files, and use signed links instead of public ones.

07

Check who can see the project, not just the site

This one is easy to forget because it isn’t about your live app at all. It takes two minutes.

• Your share link. Click Share in your project and look at what Anyone with the link can do. Bolt’s sharing page says Viewers can open the project, duplicate it, and see the preview and the code. Bolt hides environment variables from Viewers, but your code still shows how the app works. Bolt’s own tip is to choose Editor only if you want anyone with the link to change your project. If you ever posted a project link publicly, look at this setting.
• Your site’s visibility. In the Publish menu, sites are public by default. Bolt’s publishing page says paid plans can publish privately for invited people only, which is handy while you are still testing. Custom-domain sites and every Free plan site are public. Private hides the site, not a database whose address someone already knows, which is why checks 2 to 6 come first.
• Your GitHub copy. If you connected GitHub, Bolt says the repository starts out private. If you have since made it public, search it for real keys the same way as in check 4. Git keeps old versions, so a key deleted last week can still be in the history.

08

Read your headers and look for source maps

This matters less than the database, and a missing header won’t leak data by itself. It is still worth ten minutes, because headers tell browsers how to protect your visitors. Read yours from a terminal:

curl -sI https://YOUR-APP.bolt.host | grep -iE "^(content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy)"

We look for five:

• Content-Security-Policy, which MDN describes as instructions telling the browser what your page’s code is allowed to load and do. It is the main defence against someone else’s script running inside your app.
• Strict-Transport-Security, which tells browsers to stick to HTTPS for your site.
• X-Frame-Options (or a CSP with frame-ancestors), which stops another site from loading yours in a hidden frame to trick people into clicking.
• X-Content-Type-Options: nosniff and a Referrer-Policy, two small ones that are easy wins.

On Netlify, you set headers with a plain text file called _headers in the folder Netlify publishes, according to Netlify’s headers docs. In a Vite project, anything in the public folder is copied as-is into that output folder, so ask Bolt to create public/_headers with something like this:

/*
  Strict-Transport-Security: max-age=31536000
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Content-Security-Policy-Report-Only: default-src 'self'; connect-src 'self' https://*.supabase.co wss://*.supabase.co

We served a test app with this file through Netlify’s local dev server, and all five headers came back as written. The content security policy is in report-only mode on purpose: a strict policy can break an app, and MDN suggests this way of trying one first, where the browser reports what it would block in the Console without blocking anything. Once the Console stays quiet, ask Bolt to switch it to a real Content-Security-Policy.

On Bolt hosting, we couldn’t find a setting for custom response headers in Bolt’s docs, so check rather than assume: run the command above, and if something is missing, ask Bolt in Plan mode how to add it. For apps that run entirely in the browser, MDN notes that a CSP can also be set with a <meta http-equiv="Content-Security-Policy"> tag, though that route doesn’t support every feature, including report-only mode.

Source maps turn your compressed JavaScript back into readable original code: handy for debugging, and a gift to anyone curious about your app. Vite leaves them off by default, but one setting turns them on. To check:

# 1. Find the name of your main script
curl -s https://YOUR-APP.bolt.host/ | grep -oE '/assets/[^"]+\.js'

# 2. Ask for its source map (use the name you got above, plus .map)
curl -s https://YOUR-APP.bolt.host/assets/index-AbC123.js.map | head -c 60

We tried both cases on a test app. If the map is public, the second command prints text starting with {"version":3. If not, many hosts send your normal page instead, starting with <!doctype html. If you see the first, ask Bolt to turn production source maps off and republish.