Bolt app security checklist for a live site

Before you share a Bolt app, check three things. Your database rules, where your keys live, and what the published site sends to anyone who visits. Atlas, our example app at atlas.example, shows each step.

What does Bolt check for you?

Bolt's database settings include a Security section that finds problems like a missing row level security policy or a permission that is too open, on all plans. Fix what it flags before you publish. Bolt's project security check looks for private keys and passwords stored in your code or sent to visitors' browsers. Both are worth running, and both look at your project from the inside.

Where should keys live in a Bolt app?

Bolt keeps API keys and database passwords in Secrets, which only your server functions read. Bolt tells you to never store secrets in plain text in your code. A key that has to stay private never belongs in code that runs in the browser, because anyone can open that code and read it.

What does the live site show?

Your project and your live site are not the same thing. The live site is whatever your host serves to a stranger, including scripts, headers and any file that came along with the build. Check it from outside once it is published.

1. Publish the app and copy its public address.
2. Run a quick check on your published address to see what a stranger sees, then read how we check for what it covers.
3. Copy the fix prompt for each thing to fix into Bolt, review the change and publish again.
4. Check again to confirm the fix is live.

An outside check cannot see your Bolt project or your database policies. It can see what answers on the public address, which is the part attackers see.