LetMeCheck.ai
    Start free

    BOLT SECURITY CHECK

    Is your Bolt app secure? Run a free security check

    Paste your published Bolt address into the quick check and see what a stranger can see in about a minute. It is free, needs no sign-up and changes nothing.

    Run a free checkConnect GitHub for the full check
    SHORT ANSWER
    • The most common slip in AI-built front ends is an API key that the browser can read. Check yours first.
    • Bolt turns on database rules for the tables it creates. Tables you add yourself need rules too.
    • A published Bolt site is public by default, so an admin page with no login check is open to everyone.
    • Bolt has its own Security Audit. An outside check gives you a second view.

    What Bolt is and how its apps are deployed

    Bolt logo

    Bolt is a hosted AI app builder. Its own help centre says it builds websites and apps, including marketing sites, dashboards and internal tools. Bolt Cloud is the backend and hosting built into Bolt, covering hosting, domains and databases. When you publish, the site goes live in about a minute on a free bolt.host address, or on a custom domain on a paid plan. Bolt also lets you choose another hosting provider, with Netlify among the options. Each project can have a built-in database, and Supabase is an alternative on some plans. Bolt syncs your project to a GitHub repository, which starts as private on a main branch.

    Common security issues in Bolt apps

    These are patterns that are common in AI-built apps, not claims about any one app. The rating is what LetMeCheck would typically give the issue (Critical, High or Medium).

    1. CRITICALCHECK: SECRET KEYS SAVED IN CODE

      1. An API key called straight from the browser

      What it is: The page itself talks to a paid service (an AI model, payments, email) and carries the key to do it. That makes it an exposed API key. Anyone who opens the browser tools can read it.

      Why it happens here: The quickest way to make an AI feature work is to call the provider from the page. Bolt’s docs point the other way: secrets are for server functions, so private information never ends up in users’ browsers. A prompt that skips that step puts the key in the page.

      How bad it can get: Someone copies the key and uses it at your cost, or reads data it was meant to protect.

    2. HIGHCHECK: SECRET KEYS SAVED IN CODE

      2. Environment variables that end up in the shipped files

      What it is: An environment variable is a setting kept outside the code, often used for keys. Front-end build tools usually copy any variable the front end can read into the files sent to visitors.

      Why it happens here: It feels safe to put a key in a settings file. If the front end reads it, the build can bundle it, and the key travels with the page.

      How bad it can get: The key is public even though it never appears in your source code. Rotating it is the only fix once it has been seen.

    3. CRITICALCHECK: WHO CAN READ AND CHANGE EACH DATABASE TABLE

      3. Database tables you added with no rules

      What it is: Database rules decide who may read and change each row. A table without them can be read by anyone holding your public connection details. See row level security.

      Why it happens here: Bolt’s docs say it turns on RLS for the tables it creates, and that tables you add yourself need it turned on. Bolt’s own Security Audit also warns about rules that are always true.

      How bad it can get: Customer data can be read or changed by strangers.

    4. HIGHCHECK: PAGES AND ROUTES THAT SKIP THE LOGIN CHECK

      4. Admin and account pages that anyone can open

      What it is: A page that should be for signed-in users, or for you, loads for anyone who knows the address.

      Why it happens here: Bolt sites are public by default when published, and private sites are a paid feature. A page built for “just me” with no login check is then public too.

      How bad it can get: Visitors can see internal dashboards or trigger admin actions.

    5. HIGHCHECK: PAGES AND ROUTES THAT SKIP THE LOGIN CHECK

      5. Server functions with no sign-in check

      What it is: A server function runs code on the server, away from the browser. If it does not confirm who is calling, anyone with its address can use it.

      Why it happens here: Server functions are where Bolt apps hold secrets and call other services. They are generated quickly, and a quick prompt seldom adds a check on the caller.

      How bad it can get: Others can run actions you pay for, or reach data the function fetches with extra rights.

    6. MEDIUMCHECK: LIMITS ON LOGIN ATTEMPTS

      6. Weak sign-in settings and no limit on login attempts

      What it is: Without a cap, a script can try thousands of passwords against one account. Bolt’s Security Audit also flags the “leaked password protection” setting being off.

      Why it happens here: Sign-in works out of the box, so nobody opens the settings. Nothing in a typical prompt asks for attempt limits.

      How bad it can get: Passwords can be guessed over and over, and weak or leaked ones get through.

    7. MEDIUMCHECK: PACKAGES WITH KNOWN SECURITY HOLES

      7. Packages with known security holes

      What it is: Your app depends on open-source packages. Some versions have publicly known holes.

      Why it happens here: The AI tool chooses versions when it installs packages, and they stay as chosen until someone looks.

      How bad it can get: Usually a smaller risk than a leaked key, but known holes are easy for others to find.

    How LetMeCheck checks a Bolt app

    Quick check: give it your published Bolt address (the bolt.host one, your own domain, or wherever the site is hosted). It looks at the live site from the outside and can flag things any visitor can see, such as a key in the page code. It is free, read-only and needs no sign-up.

    Full check: this needs your code. Bolt can sync to GitHub, so connect that repository to LetMeCheck with read-only access. It then reads the code for secret keys (including ones deleted since but still in the history), who can read and change each database table, packages with known holes, and routes that skip the login check. These are the things a website check cannot see.

    Each fix prompt is written to be pasted into the Bolt chat. Ask Bolt to move a key into Secrets and call the service from a server function, then run the check again to confirm the key is gone from the page.

    The quick check is free, needs no sign-up and is read-only. See pricing for what the paid plans add, or try the free website audit now.

    Example report entry

    EXAMPLE, NOT A REAL CUSTOMER RESULT

    HIGH

    A secret key is visible in your site

    A key for an AI service is part of the code your site sends to visitors. Someone could use it to run up your bill. This is a made-up example to show the format of a report entry.

    FIX PROMPT (SHAPE) · PASTE INTO BOLT

    In my Bolt project, my OpenAI key is used in the browser. Move it into Secrets, create a server function that calls the service, make the page call that function instead, and remove the key from client code. Tell me which files changed.

    5 steps to harden a Bolt app before launch

    1. 1Search your project for any key or token in front-end files. Replace each with a call to a server function that reads it from Secrets.
    2. 2Rotate every key that has ever been in client code, because removing it from the code does not undo being seen.
    3. 3Run Bolt’s Security Audit on the database, then check by hand that each table you added has rules.
    4. 4Before publishing, list every page that is not meant to be public and confirm each one checks that the visitor is signed in.
    5. 5Connect GitHub, run the full check, fix what it finds, and run it again.

    When to get a developer

    Moving keys to the server and tightening database rules touches many files. If you are not sure you can do it without breaking the app, a vetted developer who knows Bolt can do it for a fixed quote you agree before work starts, and LetMeCheck re-checks afterwards. See hire a developer.

    Frequently asked questions

    Is Bolt.new safe to use?

    Bolt provides tools such as Secrets and a Security Audit, but whether your app is safe depends on how it was built. A key in the browser or an open table is the usual problem, and a check shows whether yours has one.

    Where should API keys go in a Bolt app?

    Bolt’s docs say secrets are for server functions, so private information never ends up in users’ browsers. Call the service from a server function and keep the key in Secrets.

    Do Bolt apps need database rules?

    Yes, if they store user data. Bolt turns on row level security for tables it creates, but tables you add yourself need it switched on.

    Is my published Bolt site private?

    Not by default. Bolt’s docs say published sites are public, and private sites need a paid plan. Pages that should be private need their own login check.

    Can LetMeCheck check a Bolt app if it is hosted elsewhere?

    Yes. The quick check works on any live address, wherever the app is hosted. The full check works from the GitHub repository.

    Check your Bolt app now

    Run the quick check on your live site in about a minute, with no sign-up. Connect GitHub (read-only) when you want the full check.

    Run a free checkConnect GitHub for the full check

    Other platforms

    Sources

    Platform behaviour changes fast. Last reviewed: . Spotted something out of date? Tell us.