Security scanning for Replit apps
Replit makes deploying trivial, which means the gap between prototype and production is one click.
What a Replit app is made of
- Anything, but often a JS front end with a small server
- Replit-hosted, on a replit.app subdomain or your own
- Secrets managed in Replit's own panel
Prototype settings that shipped
The things that make a prototype quick — test-mode database rules, a config file committed for convenience, debug output left on — are the same things that become exposures the moment the app is real and public.
We check the paths a crawler would ask for anyway: robots.txt, sitemap.xml, and the config files that should never be reachable. A .env is only reported when its CONTENT proves it is really that file, because a single-page app answers 200 for everything and a status code alone proves nothing.
The checks that matter here
- Publicly served config fileA .env or .git/config reachable over the web, confirmed by content.
- Exposed secret / misconfigurationIncluding keys left in client-side code during the build.
- Insecure transport (no HTTPS)The unglamorous one that turns a small mistake into an incident.
- Insecure session cookie flagsMissing HttpOnly or Secure on a session cookie is how a session gets stolen.
- Database readable by anyoneIf you connected Supabase or Firebase, test-mode rules are the usual culprit.
What this does not cover
- A scan describes your app as it is right now. A Repl that changes after the scan is not covered by it.
- We do not read your Replit secrets panel, only what your deployed app actually serves.
Free, no signup, and it reads your bundle. About a minute.
We name Replit because the scanner was built and graded against apps built with it, including a real one we deliberately broke and a real one we built normally. We do not claim a partnership with Replit and we are not endorsed by them.