To run a security scan on a Bolt.new app, cover five areas that AI builders commonly leave weak: secrets in the client, backend access control, security headers, CORS, and dependencies. Bolt.new generates a working full-stack app quickly, but it does not automatically add these protections, so a scan is where you find what is missing. The most common issues are a hardcoded or exposed key, a Supabase backend without Row Level Security, missing security headers like a content security policy, and an over-permissive CORS configuration. Use a tool for each area rather than expecting one scanner to cover everything, and fix what each surfaces before you ship.
Short answer
Scan a Bolt.new app across secrets, backend, headers, CORS, and dependencies, since none of those is secure by default. Per the Bolt.new project, it generates full-stack apps from prompts, and the generated output needs a security pass. Check the client for hardcoded keys, verify Row Level Security on any Supabase backend, and confirm security headers and CORS are configured safely, in line with the OWASP secure-headers guidance. Scan dependencies for known vulnerabilities, and scan any compiled app build for embedded secrets. The most common Bolt.new problems are an exposed key, missing backend Row Level Security, absent security headers, and a wildcard CORS policy. Fix each before shipping.
Why Bolt.new apps need a security scan
Bolt.new optimizes for generating a working app fast, which is a different goal from generating a secure one. The tool produces a functioning full-stack application from a prompt, but the controls that a security-minded developer would add, such as backend access rules and hardened headers, are not required for the app to run, so they are easy to leave out. The result is a predictable set of gaps a scan can catch.
This is why scanning is not optional for these projects. The same speed that makes Bolt.new attractive is what skips the security steps, so the review has to happen after generation, before real user data is involved. Treating a generated Bolt.new app as needing a security pass, rather than assuming it is safe because it works, is the mindset that catches these issues before users do.
What vulnerabilities Bolt.new apps commonly have
The common vulnerabilities cluster in a few areas. Hardcoded or exposed secrets come first, since a generated app can inline an API key or place a secret in client code that ships to the browser. A backend without proper access control is next, most importantly a Supabase database missing Row Level Security, which exposes its data to anyone with the public key. Both are high-impact and frequent.
Beyond those, missing security headers leave the browser side unprotected, an over-permissive CORS configuration can allow unintended cross-origin access, and vulnerable dependencies can be pulled in without notice. Input handling issues such as reflected cross-site scripting can also appear if generated code renders untrusted input unsafely. Scanning for secrets, backend access, headers, CORS, and dependencies covers the great majority of what actually goes wrong in a Bolt.new app.
Security headers and CORS
Security headers and CORS are two web-specific areas a Bolt.new scan should check explicitly, because they are configuration rather than visible features and are easy to omit. Security headers are HTTP response headers that harden the browser, and missing ones like Strict-Transport-Security, a content security policy, and X-Frame-Options leave common attacks open even when the rest of the app is fine. Check them with a headers scanner and add the ones that are absent.
CORS controls which origins may make cross-origin requests, and a generated app can ship with an over-permissive policy, such as allowing any origin, which is especially risky for endpoints that handle credentials. Review your CORS configuration so it allows only the origins you intend, and never combines a wildcard origin with credentialed requests. Getting headers and CORS right closes a set of gaps that a code-only review can miss, since they live in the server response, not the source you read.
How to run the scan
Running the scan means covering each area with a suitable tool, since no single scanner spans them all. For secrets in the source, a scanner such as gitleaks reads your code and history for hardcoded keys. For the backend, a service like Supabase provides advisors that flag tables missing Row Level Security, alongside testing your policies as the anonymous role. For headers and CORS, a headers scanner and a request tool let you inspect the actual server responses.
Complete the set with dependencies and the built app. A dependency audit flags packages with known vulnerabilities, and if your Bolt.new project produces a compiled app, a build scanner checks the shipped artifact for embedded secrets and misconfigurations. The point is coverage: assign a tool to secrets, backend, headers, CORS, and dependencies, so nothing important goes unchecked before you ship.
Backend and secrets checks
The two highest-value checks are the backend and secrets, because they cause the most serious exposures. For the backend, confirm Row Level Security is enabled on every table your client can reach and that policies restrict each role to what it should access, then test as the anonymous role using the public key to confirm you cannot read or modify protected data. A backend without RLS is the single most damaging Bolt.new gap.
For secrets, ensure no API key, database credential, or other secret is present in client code or the shipped build. Keep the service_role or other secret keys strictly server-side, and use only the intended public key in the client, governed by RLS. If you find an exposed secret, rotate it, since it should be treated as compromised. Getting these two right addresses the exposures that a Bolt.new app most often ships with.
Scan categories
Covering each category with a tool is the structure of a good scan. The table below maps each area to an example tool and what it catches.
| Area | Example tool | What it catches |
|---|---|---|
| Compiled app build | PTKD.com, MobSF | Secrets and misconfigurations in the artifact |
| Secrets in code | gitleaks | Hardcoded keys and credentials |
| Backend access | Supabase advisors | Missing Row Level Security |
| Security headers | A headers scanner | Missing HSTS, CSP, X-Frame-Options |
| CORS and dependencies | A request tool and dependency audit | Wildcard CORS and vulnerable packages |
Read the table as a coverage map rather than a ranking. The goal is one tool per area, so that secrets, the backend, headers, CORS, and dependencies are all checked, since a Bolt.new app can fail in any of them.
Scan checklist
A concrete checklist turns the categories into a pre-ship routine. The list below covers the essentials.
| Check | Action | Done? |
|---|---|---|
| Secrets | Confirm no hardcoded keys in the client or build | [ ] |
| Backend RLS | Enable Row Level Security and test as the anon role | [ ] |
| Headers | Set HSTS, a content security policy, and X-Frame-Options | [ ] |
| CORS | Restrict origins; never wildcard with credentials | [ ] |
| Dependencies | Resolve packages with known vulnerabilities | [ ] |
The two rows people skip are backend Row Level Security and headers or CORS, which is exactly why they are so often the source of a Bolt.new app's exposure. Run each check before shipping, and re-run them when you add features, since a new screen or dependency can reintroduce a gap you already closed.
What to take away
- Bolt.new generates a working app fast but not a secure one, so scan it across secrets, backend, headers, CORS, and dependencies before shipping.
- The most common vulnerabilities are an exposed key, a Supabase backend missing Row Level Security, absent security headers, and an over-permissive CORS policy.
- Check security headers and CORS explicitly, since they are server-side configuration a code-only review can miss.
- Prioritize the backend and secrets checks, since a missing RLS or a leaked key causes the most serious exposure; rotate any exposed secret.
- For the compiled app build, a scanner like PTKD.com reports embedded secrets and misconfigurations mapped to OWASP MASVS, while separate tools cover the web layer.
