Built it in Bolt? Check it before you share the link.
Bolt gets you from idea to live app in minutes, which is exactly why a quick outside check is worth doing before real users arrive. The free scan shows your score and how many problems you have; the Full Scan adds the evidence, a fix prompt for each one, and the deeper checks (database, exposed files, HTTPS/TLS, email spoofing, admin panels) after you verify you own the app.
The 8 most common Bolt problems
Private keys in front-end code
Bolt apps often call AI and payment services directly from the browser. If the key in that code is a secret one, anyone can copy it and spend your money. The free scan checks this.
Exposed .env files
An environment file that can be downloaded from the live site usually holds database passwords and API keys. Part of the Full Scan.
Open Supabase tables
If your Bolt app uses Supabase, a table without Row Level Security can be read with the public key that is in your website code. We rate this high, and critical when the table holds personal or payment data. We only count rows. Part of the Full Scan.
API routes that answer without login
A route found in your site code returns user data to anyone who asks, with no sign-in needed. Part of the Full Scan.
Overly open CORS
An API that echoes any website’s origin back while allowing credentials lets other sites make requests as your logged-in users. Part of the Full Scan.
Outdated JavaScript libraries
An old copy of a library such as jQuery, Bootstrap, AngularJS, Lodash, Moment.js or Handlebars with a publicly known security flaw, found in your page or its JavaScript files. The free scan checks this.
Weak HTTPS or email protection
HTTP that does not redirect to HTTPS, a certificate that is about to expire (rated high if it is not trusted or already expired), a missing SPF or DMARC email record (so anyone can send email that looks like it came from your domain), or an admin login page open to the public. Public source maps are reported too, as low. Part of the Full Scan.
Missing security headers
No Content-Security-Policy, HSTS or clickjacking protection. Low risk on their own, but easy to add, and they make other bugs harder to exploit. The free scan checks these.
How to fix them in Bolt
- 01Run a free scan to see your score, then get the Full Scan for the location and a fix prompt for each red item.
- 02Pick Bolt in the fix-prompt switcher and copy the prompt for each red item.
- 03Paste it into the Bolt chat. Keep private keys in a server or edge function that reads them from environment variables.
- 04If a key leaked, make a new one in that service. The old one must be treated as stolen.
- 05Publish again, then re-scan until the light is green.
Doesn’t Bolt already check this?
Builders keep adding their own review features, and you should use whatever yours offers. Those look at your project from the inside. Greenlight Scan checks the live app from the outside and confirms, after you republish, that the fix actually worked.
Full comparison →Questions
Do you change anything in my app?
No. Every check is read-only. For databases we only count rows.
Do I need to share my Bolt project?
No. We only need the public web address of your app.
Does it matter where the app is hosted?
No. We check whatever is reachable at the address you give us.
What does the free scan check, and what needs the Full Scan?
The free scan is passive. It reads what any browser downloads and checks it for leaked keys, security headers, cookie flags, mixed content and outdated JavaScript libraries. It shows your score, how many problems of each severity were found, and the title and why-it-matters of your top problem; the evidence, location and fix are hidden. The Full Scan unlocks every finding and fix prompt, and, after you verify you own the app, adds database and storage access, exposed files such as .env or .git, API routes that answer without login, Firebase rules, HTTPS and TLS certificate checks, SPF and DMARC email protection, open admin panels and public source maps.