What 290 public Replit apps are leaking
We ran Shippable's static source checks over 290 public GitHub repos built with Replit — reading committed code only, never touching anyone's live app. A mixed bag of hand-built projects. Issues skew to weak secret generation and hard-coded fallback secrets rather than backend misconfigs.
- 01Secrets made with Math.random() · 13.8% of appsPassword-reset tokens and API keys generated with a predictable random source an attacker can guess.high
- 02Hard-coded fallback secret · 10% of appsCode like process.env.SECRET || "dev-secret" that silently ships the weak default to production.high
- 03.env committed to git · 5.9% of appsReal API keys and database passwords sitting in the repo's history for anyone to read.high
- 04Hard-coded secret in source · 4.1% of appsA live secret key written directly into committed code.critical
- 05Stack traces leaked to users · 3.1% of appsErrors returned raw to the client, handing attackers table names and internals.low
- 06Injectable PostgREST filter · 2.8% of appsUser input dropped straight into a .or()/.filter() string, letting a caller rewrite the query.medium
- 07Account enumeration on auth · 2.4% of appsSign-in or reset flows that reveal whether an email is registered.low
Plus 17 more check types seen less often.
See which of these your app ships
Paste your app's URL. It's free, read-only, and takes about a minute.
Compare all five builders: which AI builder ships the safest apps.
How we measured this
We found public GitHub repositories carrying the .replit config file and ran Shippable's static source checks — the same code-level checks in npx shippable — over each one's committed files. We read source only: no live app was scanned and nothing was probed over the network. Figures are the share of 290 repositories where a given check fired at least once, aggregated so no repository, owner or finding is identified.