Find out what your app shows the public — on every deploy.

Open-source security scanner for AI-built web apps. Paste a URL, or run it in CI on every deploy. High-confidence detection only — it will not waste your time.

Scan a URL

No signup. Takes about a minute. Only scan apps you own.

Or run it locally

$pip install overshare
$overshare https://myapp.com --fail-on high
View on GitHub ↗
  • Apache-2.0
  • No account required
  • Passive by default
  • Never scans apps you do not own
$overshare http://localhost:8000 --no-footprint
Overshare report: http://localhost:8000/
 Score: 0/100   Grade: F   Scanned 5 asset(s) in 0.5s
 Findings: 11 critical  2 high  5 medium  2 low  6 info
 Platform: backend=supabase, builder=lovable

 CRITICAL  Supabase service_role key in client bundle
   where: /assets/index-a3f2b891.js
   evidence: eyJhbGciOi**********c2Uy
   fix:
     Rotate the key in the Supabase dashboard, then move any code
     that needs it into an Edge Function or server route.

 INFO  Supabase anon key detected
   Public by design. Not a leak on its own.
Fig. 1Actual output, scanning the deliberately vulnerable test app included in the repo. You can reproduce it before trusting this on anything real.
01

What it finds

i

Secrets in your shipped JavaScript

Supabase service_role keys that bypass RLS entirely, Stripe live keys, AWS credentials, OpenAI and Anthropic tokens, database URIs with passwords. Plus public source maps and readable /.env and /.git paths.

ii

Misconfiguration

Missing or weakened CSP, absent HSTS, clickjacking exposure, cookies without Secure or HttpOnly, CORS that reflects any origin with credentials, outdated TLS, expiring certificates.

iii

Forgotten infrastructure

Certificate transparency logs mined for the staging and admin subdomains you shipped once and forgot. Plus SPF, DKIM and DMARC gaps that let anyone send mail as your domain.

02

A scan you run once is a scan you stop running.

Most scanners in this category are a one-time moment: paste a URL, get a score, forget about it. Your app changes every deploy. So does its public surface.

name: security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - run: pip install overshare
      - run: overshare https://myapp.com --fail-on high
Fig. 2The whole CI integration.
03

Every other scanner tells you how many checks it runs. We tell you how often we are wrong.

A security scanner that cries wolf gets ignored, and an ignored scanner is worth nothing.

So nothing here is flagged on entropy. Minified bundles are full of build hashes, SRI digests and UUIDs that look exactly like leaked secrets — every pattern we ship is anchored on a vendor prefix or an unambiguous structure instead.

The clearest example: a Supabase anon key and a service_role key are both JWTs with the same shape. We decode the role claim rather than pattern-matching, so we never flag the anon key — which is public by design and not a leak. Most scanners get this wrong.

The false-positive rate will be published with the methodology and the sample set.

Read the methodology →
04

What this scanner cannot tell you

Passive scanning cannot prove your Row Level Security is actually enforced. That needs a live read against your database. The report says so explicitly instead of showing you a green check and letting you assume you are fine.

It also cannot see route-level code loaded lazily at runtime, or anything behind a login.

05

Is it OK to scan an app I do not own?

The passive checks fetch only what the server already sends to every visitor — the same requests your browser makes when you load the page. No writes, no login attempts, no enumeration, no credential that was not already public.

Anything deeper requires the owner's written authorisation, and the tool will not do it without.

One thing we ask: do not scan someone's app and then contact them to sell them something. Unsolicited “I found a vulnerability in your site” is extortion-shaped no matter how good your intentions are. If you find something real by accident, tell them privately and give them time.

Read the acceptable use policy →
06

You can read every check that produced your score.

This whole scanner is Apache-2.0 on GitHub. There is a deliberately vulnerable test app in the repo — run the scanner against it and see exactly what gets caught and what gets missed before you trust it on anything real.

Scanning is free forever. That is not a trial.

View on GitHub ↗
07

When a customer asks for a security review

Finding problems is the free part. Overshare Cloud is for what comes next: history that shows what regressed between deploys, fixes written against your actual schema rather than generic advice, and a verifiable badge you can put in front of a customer who is asking whether you are safe to buy from.

One email when it launches. No newsletter, no sharing.

08

Questions

Do I need an account?

+
No. The free scan needs a URL and nothing else.

How is this different from the other scanners?

+
It is open source and it runs in CI. Most alternatives are closed, one-shot URL scanners. If a scan result is going to change how you ship, you should be able to read the code behind it.

Lovable already scans my app. Why use this?

+
Lovable's scanners are good, but running them before you publish is optional, and they only ever scan Lovable's own output. This works the same on Bolt, Cursor, Replit, v0, or hand-written code — and it is not graded by the same system that wrote the code.

Is the Supabase anon key a security problem?

+
No — it is public by design, and any scanner that flags it as a leak is wrong. It only matters if RLS is not enforced behind it, which is a separate check. The key that must never reach a browser is service_role, because it bypasses RLS entirely.

Will you store my scan results?

+

For 30 days, then they are deleted automatically. That applies to every scan, including one somebody else ran against your app — anyone can paste any URL into the box above, and we would rather say so than let you assume otherwise.

Secrets are redacted before anything is written down, so what is kept is a report, not a set of working keys. We do not contact the owners of scanned apps, and we do not sell scan data. If you want a result gone sooner than 30 days, ask and it will be.

What if it is wrong?

+
Open an issue. False positives are treated as bugs, not noise — a scanner people stop trusting is a scanner that failed.