Repo scan vs URL scan: which one does your app need?

Updated Oct 22, 20265 min read

A URL scanner looks at your live site from the outside, like a visitor would. A repo scan reads your source code and its history. In security jargon that's DAST (dynamic testing) and SAST (static analysis). Each one sees things the other can't, and vibe-coded apps often have bugs right in those gaps. Here's what a repo scan vs URL scan catches, with sources.

What a URL scanner sees

OWASP describes these tools as scanners that test web applications "normally from the outside" for problems like cross-site scripting, SQL injection, path traversal and insecure server configuration. You give them a URL, and they see what the internet sees:

• Security headers, cookie flags, HTTPS redirects and TLS. Mozilla's HTTP Observatory grades the headers and cookies.
• Files that shouldn't be public, such as /.env, /.git/ or source maps.
• Keys inside the JavaScript bundle, for example a secret in a VITE_ or NEXT_PUBLIC_ variable.
• Some scanners made for AI app builders also call your Supabase API with the anon key from your frontend and report tables that answer.

A URL scan reflects the live state. A policy someone changed in the Supabase dashboard shows up here and never in the repo.

What only the code shows

A URL scanner can only test what it finds. Many of the bugs we see in AI-built apps are on paths a crawler rarely reaches or can't judge from outside:

• Server actions and API routes without a login check. A crawler usually can't discover or meaningfully test a Next.js server action, and from outside a missing ownership check looks like a working app. See server actions are public endpoints.
• Keys in git history. A key deleted from the code is still in old commits. GitHub's docs say to revoke or rotate a leaked secret as the first step. Rewriting history is a separate step with its own side effects. A URL scan never sees the history.
• Policies that let any account edit any row. A logged-out scan sees nothing wrong, because you need a second account to notice. The migration shows it in one line, see Supabase delete policies.
• Security definer functions and views that skip RLS, plus roles read from user_metadata.

Where a repo scan is blind

OWASP lists the weak spots of static analysis plainly: high numbers of false positives, and it is "frequently unable to find configuration issues, since they are not represented in the code." Both apply to us.

• Tables, policies and buckets made in the Supabase dashboard aren't in the repo.
• Hosting settings, headers added by your host and DNS aren't in the repo either.
• Some flags are on purpose. In our sample of 99 public Bolt repos, 14 projects had a (true) write policy. In 4 of them it was used mainly for public forms like orders and contact messages, where an open insert is the point (method and numbers).
• A repo scan flags code to read, not confirmed exploits.

Repo scan vs URL scan side by side

Typical coverage. Individual tools vary, so read what yours checks.

How to use both before launch

1. Check your live site from outside

   Run Mozilla's HTTP Observatory on your domain for headers and cookies. If you want more, run ZAP's baseline scan against your own site.

2. Check the live database

   Open the Supabase Security Advisor. Supabase's docs warn that some findings may be intentional, so check each against what you meant.

3. Read the code

   Run a repo scan, or work through the vibe coding security checklist by hand: auth in every route, ownership checks, keys in history, policies in migrations.

4. Test with two accounts

   Sign in as user A, copy a request, and replay it as user B and logged out. This catches missing ownership checks that neither scanner is likely to flag.

Fix prompt you can paste

We're about to launch. 1) List every API route and server action and
say which ones check the login and the owner of the record. 2) List every
Supabase policy in supabase/migrations that uses (true) or only checks
for a login. 3) Search the code for secrets in VITE_ or NEXT_PUBLIC_
variables. 4) Tell me which settings live outside the repo (headers,
dashboard policies, buckets) so I can check them on the live site.
File and line for each finding, smallest fix first.

How Leakcade checks this

Leakcade is a repo scan. We read a public GitHub repo as text, run gitleaks over the last 50 commits, Semgrep, OSV-Scanner for known vulnerable packages, our own Supabase, payment and server-action checks, and an AI review. We never run your app or send requests to your site, so headers, hosting and dashboard settings are out of scope. Pair the report with a URL scan and the Supabase Security Advisor. Building in Lovable? Its built-in scan also reviews your database rules, see Lovable security scan vs Leakcade.

Sources

1. OWASP: Source code analysis tools (strengths and weaknesses of SAST)
2. OWASP: Vulnerability scanning tools (DAST)
3. ZAP: Baseline scan
4. MDN: HTTP Observatory tests and scoring
5. GitHub Docs: Removing sensitive data from a repository
6. Supabase docs: Database advisors

FAQ