Free Security Self-Audit for AI-Built Apps

Built an app with Lovable, Bolt, Cursor, Replit, or V0 and have no security background? Start here. Five free scanners, each for one vulnerability class, with no signup or card.

Items 1 and 2 catch problems that expose all users’ data. Items 3 through 5 catch problems that let one user reach others.

Run this before your first paying user. If the app isn’t deployed yet, use the pre-launch checklist instead.

The five free scanners

1. Supabase RLS Checker →

Tests every public Supabase table with your anon key. Reports which tables return rows without authentication - those are publicly readable.

Catches. The most common failure in Lovable, Bolt, and Cursor apps. 59% of apps in the 2026 benchmark had at least one RLS gap.

What the report looks like. A list of every table the anon key can reach, color-coded by whether it returned data. Tables in red are publicly readable; tables in yellow allow anon writes; tables in green require auth. A typical case is a profiles table that returns every user’s email and avatar to anyone with curl - see Supabase RLS misconfiguration atlas for the patterns.

Fix prompt. “For each table flagged in the RLS report, generate a Supabase migration that enables RLS and adds a SELECT policy restricting rows to auth.uid() = user_id. Add equivalent INSERT, UPDATE, and DELETE policies that require ownership. Output the SQL migration file and the CLI command to apply it.”

Time. ~10 seconds to scan, ~5 minutes to fix per table.

2. Token Leak Checker →

Loads your URL like a normal visitor and runs 100+ key signatures against the JavaScript bundle. Catches Stripe secret keys, Supabase service-role keys, AWS keys, OpenAI keys, and 90+ more formats.

Catches. 41% of apps in the benchmark ship at least one secret key in their frontend bundle.

What the report looks like. A list of every match by key type, with the file and line where it was found. Each finding includes the rotation URL for the relevant provider Rotate a leaked key first, then remove it from code.

Fix prompt. “Move every secret found in the token leak report from the client bundle to a server-side environment variable. Replace the direct API calls with calls to a new server route that proxies the request. For Stripe, use STRIPE_SECRET_KEY only on the server; for Supabase, use the service-role key only in server functions; for OpenAI, never call from the browser. Update .env.example accordingly.”

Time. ~15 seconds to scan, ~10 minutes per key to rotate and remediate.

3. Firebase Scanner →

If you used Firebase as your backend, this checks firestore.rules and storage.rules for the open-read patterns that ship in default AI-generated Firebase apps.

Catches. The Firebase equivalent of missing RLS. Firebase apps were a smaller share of the benchmark but had the highest critical rate of any backend. The recurring default is match /{document=**} { allow read, write: if true; } - a wildcard that opens every collection to the public.

What the report looks like. A flat list of every rule block, marked safe / risky / open. The “open” ones are the priority; the “risky” ones (e.g., if request.auth != null without a tenant check) are the second pass.

Fix prompt. “Rewrite firestore.rules to require request.auth != null on every collection, and to require request.auth.uid == resource.data.user_id on collections that are owned by a single user. Reject the wildcard match /{document=**} rule unless explicitly justified. Output the new rules file and the deploy command.”

Time. ~5 seconds to scan, ~15 minutes to rewrite the rules file.

4. Security Headers Checker →

Inspects HSTS, CSP, X-Frame-Options, X-Content-Type-Options, and CORS. Reports which headers are missing or set to permissive values.

Catches. CORS allow-all on credentialed endpoints (23% of apps), missing HSTS (most apps shipping their first deploy), no CSP (almost every app at first deploy).

What the report looks like. A grade per header (A through F), with the recommended value alongside the current one. CORS is the highest-impact item - see CORS credentials misconfig for why a credentialed allow-all is exploitable.

Fix prompt. “Add the following headers to the production deploy config: HSTS with max-age=31536000; includeSubDomains; preload; CSP starting with default-src 'self'; X-Frame-Options: DENY; X-Content-Type-Options: nosniff. Replace any Access-Control-Allow-Origin: * with an allowlist of our actual frontend origin. Provide the config diff for Vercel / Netlify / Cloudflare based on what is currently in use.”

Time. ~3 seconds to scan, ~10 minutes to apply via deploy config.

5. Vibe Code Scanner →

Audits the AI-generated repo for common patterns - exposed config files, default secrets, debug routes left open, and other patterns specific to AI-generated apps.

Catches. Patterns other scanners skip: source maps shipped to production, /_next/static/ paths leaking the framework version, .env.example committed with real keys, exposed Vercel deployment URLs that bypass auth, debug-only API routes left enabled.

What the report looks like. Findings grouped by source (frontend bundle, deploy config, public path leaks), each tagged with severity. Severity reflects exploitability: a leaked source map is high severity because it makes other attacks easier.

Fix prompt. “For each finding in the vibe-code scan report, generate the minimum config change that resolves it. For source maps, set productionBrowserSourceMaps: false in next.config.js. For exposed config files, add them to .gitignore and remove from git history. For debug routes, gate them behind NODE_ENV === 'development'.”

Time. ~30 seconds to scan, ~20 minutes to apply the cluster of fixes.

More single-purpose checkers

Beyond the core five, five narrower checkers cover specific exposure classes. Run whichever match your stack:

• CORS Misconfiguration Checker - wildcard and reflected origins, credentialed allow-all.
• Source Map Exposure Checker - .map files and .git directories reachable in production.
• .env Exposure Checker - reachable .env variants and env vars leaked into the JS bundle.
• JWT Security Checker - alg=none acceptance, weak signing secrets, missing expiry.
• Package Hallucination Scanner - phantom dependencies the AI invented, before someone registers them.

What the five together do not catch

The free suite covers the top five categories in the benchmark. It does not cover:

• BOLA - Broken Object-Level Authorization across roles requires authenticated probing. Manually tested in the pre-launch checklist, automated in the full VibeEval scan. See also the BOLA in AI-generated CRUD pattern.
• Self-editable role fields - requires authenticated probing of the profile / settings endpoints with a modified payload. Manual test: change is_admin: true in a profile-update request and see if it sticks.
• SSRF, IDOR variants, LLM prompt injection - require an agent with credentials and stateful probing. Detail in the SSRF / open redirect / OAuth pattern and indirect prompt injection.
• Dependency CVEs - requires source-code or package-manifest access. The Package Hallucination Scanner is the closest free equivalent for the AI-specific subset (phantom packages); for full CVE coverage, run npm audit and pip-audit locally.
• Rate limits on auth endpoints - requires sending bursts of traffic safely. The full scan probes this safely; manual bursts risk taking your own app down.
• Race conditions in money paths - see race conditions in money paths. These need concurrent requests with timing control to surface.
• Webhook trust - see Stripe webhook and paid-trust. The bug is trusting the redirect URL instead of the webhook, and it takes a paid-flow test to surface.

Those gaps are what the full VibeEval agent covers - 310 probes, scheduled, with diff alerts when something regresses. If you only need a one-shot pre-launch verdict, the five free scanners are enough.

The 30-minute self-audit playbook

Run all five scanners, then work through the findings in this order:

Minute 0–2: scan all five. Open each tool in a tab, paste the URL, kick off the scan. Collect every finding before fixing, so you triage by priority.

Minute 2–5: rotate any leaked keys. If the Token Leak Checker finds anything, stop and rotate the key in the provider dashboard before doing anything else. A leaked key may already be in an attacker’s hands. Rotation closes that window; removing it from code comes second.

Minute 5–15: fix RLS / Firebase rules. Every “red” table in the RLS report or every if true rule in the Firebase report. This category has the largest data-loss impact, and the fix is a short migration per table.

Minute 15–25: fix headers and CORS. Apply the recommended values from the Security Headers report. CORS first (highest impact), HSTS second, CSP last (the most likely to break a feature, so deploy and watch for browser console errors).

Minute 25–30: triage the Vibe Code Scanner findings. Anything tagged “high” gets a fix on the same day; anything “medium” goes into a backlog; “informational” findings can wait. Remove source maps from production immediately if found.

Minute 30: re-scan. Re-run all five and confirm the categories you fixed turned green. Anything still red goes onto a follow-up list with a single owner and a deadline.

Green scanners do not replace a pentest, but they confirm these five categories are clean.

Run order

1. Run the Supabase RLS Checker - fix anything red before continuing.
2. Run the Token Leak Checker - rotate any leaked key immediately, before fixing anything else.
3. Run the Firebase Scanner if applicable.
4. Run the Security Headers Checker - fix CORS and HSTS.
5. Run the Vibe Code Scanner - work through findings in severity order.

After all five are clean, run the full VibeEval scan to verify the long tail.

What to do with the output

Every finding from every scanner ships with a fix recommendation phrased as a paste-ready prompt for Claude Code or Cursor. Copy the prompt, paste it into your AI editor, accept the change, redeploy, re-scan to confirm.

The loop is scan, prompt, fix, re-scan. The AI editor that built the app can also apply the fixes.

Two practical notes on this loop:

The model that wrote the bug often cannot see it. Treat the scanner as the second opinion. If the AI editor pushes back on a fix prompt (“this is already secure”), trust the scanner over the model - re-scan after the change and look at the result, not at the assistant’s claim.

Fix one finding per turn. Do not paste the entire report into one prompt. AI editors handle one focused change well; they make a mess of bundled changes.

After the audit: what to monitor

Findings regress. RLS, BOLA, leaked keys and CORS drift whenever you add a feature or change deploy config. Three habits help:

• Re-scan after every deploy. Bookmark the five tools.
• Re-run the playbook before any external launch. Product Hunt, press, paid traffic - anything that brings strangers to the URL.
• Watch the categories most likely to regress in your stack. Supabase apps regress on RLS when new tables ship. Firebase apps regress on rules when the schema changes. v0 / Bolt apps regress on token leaks when new env vars land.

Scheduled scans in the full VibeEval scanner cover this. Switch to them once you ship two deploys without re-running the manual playbook.

Related

• 2026 AI App Security Benchmark
• Solo Founder Pre-Launch Security Checklist
• Is My Lovable App Secure?
• Vibe Coding Security: The Complete Risk Guide
• Best security scanner for AI-generated apps - full comparison
• Why gapbench - the reproducible-scenario approach behind every pattern article