Vibe coding security scanners for Lovable, Bolt and v0 apps
Nine security scanners for vibe-coded apps, ranked by the layer each one sees: the live site, the builder's code, the database or the repository.
LLaunchScaler·Published ·10 min read
The security scanners worth running on a vibe-coded app are LaunchScaler's free scan for the deployed site, the builder's own check (Lovable's Quick and Deep scans, Bolt's security audit, v0's secret checks), Supabase's Security Advisor for the database, and a repository scanner such as GitHub code scanning or Snyk for code and dependencies. No single tool sees every layer, so the useful question is which layer each one reads.
A Lovable, Bolt or v0 app fails in predictable places: a secret shipped to the browser, a table with no row-level security, a missing security header, a /.env file served from the web root. Each of those lives in a different place (the bundle, the database, the host's response), and a scanner can only find what it can see. Every product fact below was checked on the vendor's own pages in September 2026.
Which layer does each security scanner check?
There are four layers. The deployed site is what an attacker or a crawler meets: headers, TLS, DNS and files reachable by URL. The builder's project holds the generated code. The database holds the access rules. The repository holds dependencies and source. The table maps each scanner to what it reads.
Scanner
Layer it reads
When it runs
Cost
What it cannot see
1. LaunchScaler free scan
Deployed site, from outside
Any time, on any URL
Free, no account
Your source code and database policies
2. Lovable Quick and Deep scan
Questions, answered
What people ask about this
01
What is the best security scanner for a vibe-coded app?
Use one scanner per layer. An outside-in scan such as LaunchScaler's free scan checks the deployed site's headers, exposed files, TLS and DNS; the builder's own check (Lovable's Quick and Deep scans, Bolt's security audit) reads the code and database it generated; and a repository scanner such as GitHub code scanning or Snyk reads dependencies and source.
Environment variables and secrets in generated code
Automatically
Not priced separately
Database policies and live headers
5. Supabase Security Advisor
Database schema and RLS settings
Automatically in Studio
Included
Whether a policy matches who should see what
6. GitHub code security
Repository: dependencies, secrets, code
On push and pull request
Free on public repos
The live site
7. Snyk
Repository: code, dependencies, containers
On import, CLI or CI
Free plan, paid from $25 a month
Most live-site configuration
8. ZAP
Running web app, dynamic testing
When you run it
Free and open source
Source code and database rules
9. MDN HTTP Observatory
Live site's security headers
When you run it
Free to use
Anything beyond headers and related config
What are the best security scanners for vibe-coded apps?
LaunchScaler leads the list because it is the only scanner here that checks the live site's headers, exposed files, TLS and DNS together from nothing but the URL, with no repository access, builder account or install. MDN's Observatory also takes just a URL but grades headers only, and ZAP has to be installed and run. The builder-native checks come next because they see the code and database the builder generated, then the database and repository scanners, then two narrower outside-in tools.
1. LaunchScaler: the deployed site from the outside, with no account
LaunchScaler's free scan takes the URL of your live app and checks it from the outside, the way an attacker's script or a search crawler meets it. There is no account and nothing to install: "No account needed, just the address." It runs 156 checks across 6 of its 7 categories, and security is one of them.
The security checks read what the deployed site actually sends and serves:
It reads the response headers: Strict-Transport-Security (and whether it is preload-eligible), Content-Security-Policy and whether unsafe-inline or unsafe-eval weaken it, clickjacking protection via frame-ancestors or X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and a wildcard Access-Control-Allow-Origin.
It flags session cookies missing Secure, HttpOnly or SameSite.
It looks for files that should never be public: a reachable .git repository, .env and config files at conventional paths, database dumps and archives, published JavaScript source maps, open directory listings, and admin or debug endpoints.
It checks TLS for deprecated protocol versions and a valid, complete, unexpired certificate chain, plus the HTTP to HTTPS redirect.
It checks DNS for SPF, DKIM and DMARC on your domain's email, CAA records, DNSSEC, and dangling records that point to a subdomain takeover.
It also flags server and framework version disclosure in headers, mixed content, a security.txt contact file and Subresource Integrity on third-party scripts.
The same scan also checks search, AI visibility, speed, compliance and whether the site works, which matters for AI-built apps because the usual failures there (a client-rendered page that crawlers see as empty, a robots rule that blocks the whole site) sit beside the security ones. Why AI-built apps don't get indexed covers those.
What it does not see: your source code, your repository's dependencies and your database policies. It cannot tell whether a Supabase table has RLS turned on. It is the first check to run because it needs only the URL; it is not the only one.
2. Lovable: Quick scan on every publish, Deep scan on demand
Lovable runs two built-in scans. The Quick scan "runs automatically every time you publish" and covers database access rules ("tables without per-record access control (row-level security), access rules that let everyone through, and leaked-password protection turned off") plus known vulnerabilities in npm dependencies. It also checks MCP server exposure.
The Deep scan "reviews all your application code for issues specific to your app's logic, permissions, and data." Its areas include access control, unauthenticated endpoints, unsafe input and injection, leaked secrets, payment and billing bypasses, sign-in weaknesses and personal data exposed in errors and logs. It runs when you start it from the Security view or the Security center.
Lovable says running either scan is free. Fixing findings with "Try to fix all" draws on 10 free fixes that reset 24 hours after use, and asking the chat to "review my app's security" uses credits. Scheduled Deep scans are Enterprise only. Only dependency vulnerabilities rated critical become findings. Lovable's own caveat is that these tools "do not replace a thorough security review."
The scans read the project, not the host's responses, so a missing Strict-Transport-Security header or a stray file on a custom host is outside what they report.
3. Bolt: a project security audit from the Publish menu
Bolt's project security audit "reviews your whole project, including your code and database, fixes what it can, and flags anything you need to handle." You start it from Publish, then Run security audit, and Bolt says neither the audit nor its fixes use your tokens. It is available on paid plans, with a limit of 30 audits a day.
Bolt lists what it checks: who can see and change data, what the app makes public in errors and sign-in screens, sign-in and session handling, misuse such as changing a price or skipping a step, input from visitors including file uploads, and keys and security settings, including "which other websites can talk to your app."
A lighter database security check is available on all plans. It flags issues such as a missing RLS policy, an "RLS Policy Always True" warning and leaked-password protection turned off, with an "Ask Bolt to fix" button. Bolt recommends running a check at least once before you publish.
4. v0: secret and environment variable checks
v0's documentation says it "analyzes NEXT_PUBLIC_ usage and warns users about potential security risks," because in Next.js any variable prefixed NEXT_PUBLIC_ is sent to the browser. The AI can move code into Route Handlers or Server Actions so a key stays on the server.
Vercel's post on vibe coding securely lists the automated checks as exposed secrets in client code or public repositories, NEXT_PUBLIC_ misuse, tokens written to logs, prompt injection from unsanitised input, misconfigured third-party APIs and unsafe defaults for authentication, routing and database access. It reported blocking over 17,000 deployments on Vercel in 30 days for exposed secrets alone. The documentation does not describe a check of the live site's headers or of database policies.
5. Supabase Security Advisor: the database access rules
Most Lovable and Bolt apps store data in Supabase, and Supabase ships its own advisors: "programmatic checks that ship with the platform" that "inspect the live schema." They run automatically in Studio, and the same checks are available from the CLI with supabase db advisors.
The security lints include 0013 rls disabled in public, 0024 permissive rls policy, 0007 policy exists rls disabled, 0008 rls enabled no policy, 0010 security definer view, 0015 rls references user metadata and 0002 auth users exposed. That is the layer where vibe-coded apps leak data most directly, because Supabase's publishable key is "safe to expose online" only because "Row Level Security decides what this client can reach."
6. GitHub code security: dependencies, secrets and code in the repository
If the builder syncs to GitHub, the repository gets its own scanners. GitHub says "code scanning and secret scanning are enabled for public repositories by default," and Dependabot alerts are included in all plans. For private repositories, the advanced features are paid add-ons.
GitHub Secret Protection is priced at $19 per active committer a month, and GitHub Code Security (CodeQL scanning, Copilot Autofix and dependency review) at $30 per active committer a month. These read files in the repository. A header your host adds, or forgets, never appears there.
7. Snyk: code and open-source dependencies
Snyk scans source code (Snyk Code), open-source dependencies (Snyk Open Source), containers and infrastructure-as-code, and it also sells a separate web and API testing product. Its pricing page offers a free plan and paid plans from $25 a month. Like GitHub's tools, the core products read the repository.
8. ZAP: dynamic testing of the running app
ZAP describes itself as "the world's most widely used web app scanner. Free and open source." It tests the running application rather than its code. The quickest start is the baseline scan, which "runs the ZAP spider against the specified target for (by default) 1 minute and then waits for the passive scanning to complete," without attacking the site:
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://www.example.com
Its active scans do send attack traffic, so run those only against an app you own, ideally a staging copy.
9. MDN HTTP Observatory: security headers only
Mozilla's HTTP Observatory grades a site's HTTP headers and related configuration from a URL. Its FAQ is clear about the limit: it tests preventative measures against cross-site scripting, manipulator-in-the-middle attacks, insecure cookies and similar issues, but "it does not test for outdated software versions, SQL injection vulnerabilities, vulnerable content management system plugins, improper creation or storage of passwords, and more." Scan history for each domain is public.
Which layer do none of them fully cover?
Database access rules. Lovable's Quick scan, Bolt's database check and Supabase's advisors all flag RLS turned off and policies that let everyone through, but none of them knows who is supposed to see which rows. Supabase's own guidance is to "confirm each finding against the intended schema and access model." Only you have that model.
Test it directly. For each table, sign in as one user and try to read, update and delete another user's rows through the client library with the publishable key. Then try with no session at all. Any request that succeeds and should not is a policy bug, whatever the scanners said. Check that no secret or service_role key sits in client code, because Supabase warns that key "bypasses every Row Level Security policy you have."
The second gap is business logic: a price changed in the request, a paid feature reached without paying, a single-use code claimed twice. Bolt's and Lovable's code reviews look for these patterns, and a manual walk through your own checkout is still the only test that proves it.
In what order should you scan a vibe-coded app?
Scan from the outside first, because it needs nothing but the URL and finds the problems a stranger finds first. Then work inward. The full pre-launch list, including the manual RLS test above, is in the vibe-coded app security checklist.
Scan the deployed URL from outside for headers, exposed files, TLS and DNS.
Run the builder's own scan: Lovable's Deep scan, or Bolt's security audit from the Publish menu.
Open Supabase's Security Advisor and clear every ERROR-level lint.
Test RLS by hand with two accounts and no account.
Turn on Dependabot alerts and secret scanning for the repository, or connect Snyk.
Re-scan the deployed URL after every deploy that changes hosting, headers or routing.
If the outside scan finds a reachable /.env or /.git/, treat every secret in it as leaked: rotate it first, then remove the file. Exposed .env and .git files walks through that clean-up. For a broader comparison of outside-in scanners beyond vibe-coded apps, see website security scanners.
Scan the live app before anyone else does
The builder's scans read what the builder generated. What your users and attackers get is whatever your host serves at the URL, and that is where missing headers and exposed files show up. Run the free scan on LaunchScaler with your app's live address: no account, no repository access, and the security checks above run alongside the search, AI visibility, speed, compliance and does-it-work checks, each with a verdict.
02
Does Lovable have a security scanner?
Yes. Lovable's Quick scan runs automatically when you publish and checks database access rules (tables without row-level security, rules that let everyone through) and npm dependencies, while the Deep scan reviews all your application code on demand. Lovable says running either scan is free.
03
Can a security scanner check my Supabase RLS policies?
Partly. Lovable's Quick scan, Bolt's database check and Supabase's own Security Advisor flag tables with RLS disabled and policies that allow everyone. None of them can know who is supposed to see which rows, so you still test the policies against your intended access model.
04
Is the Supabase anon key safe to expose?
Supabase says publishable keys are safe to expose in a web page or app, because Row Level Security decides what that client can reach. The secret or service_role key bypasses every RLS policy and must never reach a browser or source control.
05
Do code scanners check HTTP security headers?
Generally not. Dependency and static-code scanners read the repository, not the headers your host sends. To check Strict-Transport-Security, Content-Security-Policy or exposed files like /.env, scan the deployed URL from the outside.
AVIF is usually smaller than WebP at the same quality but encodes more slowly. All major browsers now support both, so serve AVIF with a WebP fallback.
