Is Replit safe? What we found in 3,042 live Replit apps

You built something on Replit, it works, and you are about to put real people on it. Somewhere in that week you typed "is replit safe" into a search box, and what came back was either a page about Replit's certifications or a page about an AI agent that deleted a database. Neither one said a word about the app you are about to publish.

Here is the part most of those answers get wrong: "is Replit safe" is three questions wearing one sentence, and the one that decides whether strangers can read your users' data is the one almost nobody measures.

We can measure it. Between 12 and 14 August 2026 we ran the same nine external checks anyone can run free on our homepage over 30,998 live apps, and 3,042 of them were published on Replit. This is what came back for those, and where our view stops.

Is Replit safe?

As a host, it was not where the findings were. The two things we can see about the hosting from outside came back clean on every app that answered, and the nine apps that graded D or F all got there through something inside the app.

Think of Replit as a rented shop with a workshop at the back. The landlord owns the building and the lock on the street door. Whoever fitted the shop out decided where the shelves went and how the back room connects to the front. And what a passer-by can reach from the pavement is decided by you, every time you open. Those are three different questions, and a good answer to the first two says nothing about the third.

1. The platform. Does Replit host your app properly: a valid certificate, a domain that will not lapse, secrets kept encrypted and out of your files. This is the landlord.
2. The agent. Is the code Replit's AI writes safe. This is the fitter, and no scan from outside can see the wiring.
3. The app you published. What a stranger can reach from the street: a key in the code a browser downloads, an API route that answers with no login, a file that should never have had a URL.

Our checks read the third. On the first, the certificate was valid on all 3,028 apps where we could read one, and no domain out of 3,042 was near expiry. On the second we have nothing to measure, and the section on it below says so.

What we found in 3,042 Replit apps

Nine checks, run from outside, with no login and no access to anyone's account. We never read a row: where a database answered, we asked how many rows it would hand over and stopped there. No app is named here or anywhere else we publish. Every share below is of the apps that check answered on, because a check that could not finish is unknown rather than passed, and that rule is why the denominators move. The method and the data are in the report.

The grades: 2,789 A, 183 B, 61 C, 8 D and 1 F. Thirty-one apps had no finding at all.

Why "99% had a finding" means little here

Because 2,924 of those findings are the same one, and it is the least urgent line a report can carry.

Browser security headers are sent by whatever serves your page. On a builder's own domain that is the builder, which is why the number is 96% here, 99% on Lovable and 100% on v0, and why every app on the same host gets the same answer. Replit is one of the few places where you can change it: if your app runs its own server, that server is the thing sending the headers, and adding them is a few lines. It is worth doing and it is not what a D is made of.

Leave that row out and 1,798 of the 3,042 apps had nothing that followed from what was built. The other 1,244 are where the rest of this post lives.

The finding that is Replit-shaped: an API route of your own

The commonest thing we found that an owner had put there was a route on the app's own server that answered a stranger with data. 1,050 of 3,037 apps had at least one.

A Lovable app is a front end plus a database that somebody else runs. A Replit app is usually the whole shop: the page, and a server behind it that talks to the database, in the same project and often written in the same session. The seventh of our nine checks reads the API paths written into your app's JavaScript, /api/orders, /api/users, whatever it finds, and asks each one, with no login, whether it will answer. On Lovable that fired on 8 apps out of 18,518, because there is usually no server of the owner's to ask. On Replit it fired on 1,050.

It is graded medium because sometimes that is exactly right. A route that returns your public list of products should answer everyone. It is wrong when the route is /api/users and the answer is your users with their email addresses, and the way you find out is that anybody can open that address in a tab and read it. A route that should be private needs a login check, and everyone without one gets a 401.

In the shop, this is the back door that opens from the street. If you have used Supabase, it is the same failure you have seen described as a table without Row Level Security, in a different shape. The rows are readable because nothing between the stranger and the data asked who they were.

Two smaller findings sit beside it. 76 apps told any website in the world it may call their API, and 56 more allowed that with the visitor's login cookies attached, which is the version that lets another site act as your user and the one that is rarely right.

What "7% shipped a secret" is made of

Mostly Google keys. 219 of the 3,042 apps had something key-shaped in the code a visitor downloads, and 200 of those were a Google API key, which is usually fine once it has been restricted to your own domain. Thirty-two carried a key-shaped value we could not attribute to a provider. Three apps held a key that bills an account directly: an OpenAI, an Anthropic or an AWS key.

Three out of 3,042 is rare. It is also the finding that costs money on its own, the till key left on the counter, and it tends to surface as a usage bill arriving before anyone has noticed. A scanner that matches shapes would print all 219 as problems; we read what each key can do, because the alternative is teaching you to ignore the warning on the day it matters.

On Replit the route a key takes into the bundle is specific enough to have its own article. The Secrets tool keeps a value out of your files, which it does well. It cannot keep the value out of the browser if browser code is what reads it, and the way people make that work is to rename the variable VITE_ or NEXT_PUBLIC_, which is an instruction to the build tool to publish it.

The two you can fix in a setting

Source maps and a stray private file. Both are decided by how the project is built, and both are a setting rather than a rewrite.

168 apps published source maps, which means the original files behind the app, comments included, are readable from any browser's developer tools. On Replit the build configuration is in your project, so the switch is yours; what a published map does and does not expose is worth reading before you decide it does not matter.

Seven apps served a private file from a plain URL: a .env, a .git/config. Five of the nine apps graded D or F had this finding, and it is the shortest path to a bad day on the list, because a .env at a URL is every key in it in one request. In a private window, open your published address with /.env on the end. It should fail. If it shows text, rotate every key in that file today, then take the file out of what you deploy.

Is the code Replit's agent writes safe?

We did not measure it, and no scan from outside can. What a scan sees is the result: the 1,050 open routes and the three billing keys were written by somebody, an agent or a person, and published.

What is on the record is one event. In July 2025 Replit's agent deleted a production database in the middle of a session where it had been told to change nothing, and Replit's CEO acknowledged it publicly; separating development databases from production ones was part of the company's response. What follows for you is the same on every builder with an agent in it: keep the agent away from the live database, and keep a copy of your data somewhere the agent cannot reach.

Where that copy lives depends on where your data is. If your Replit app keeps it in Supabase, that is what Care holds. If it is in Replit's own database, we cannot back it up, and the thing to read before you need it is what Replit's database tool offers for a restore. Only 14 of the 3,042 Replit apps we scanned named a Supabase project, so for most of them the second case is the one that applies.

The five-minute check on your own Replit app

Each one is a URL you open or a search you run. Use a private window so your own login does not answer for a stranger.

1. Open your published address with /.env on the end, then /.git/config. Both should fail. If either shows text, rotate every key in it today.
2. Open one of your own API routes the same way, one you would not want a stranger reading. If it answers, that route needs a login check.
3. Search your project for VITE_ and NEXT_PUBLIC_. Each match is a value your build tool publishes on purpose, and each one has to be a key that was safe to publish.
4. Open your live app, then the Sources tab of your browser's developer tools. If you can read your original files with their comments, source maps are on.
5. Or let the scan do it. It runs these four and five more from outside, takes about 20 seconds, needs no account, and prints "Couldn't check" for anything it could not answer rather than a tick: scan your app.

What changes after you publish again?

Anything. Publishing on Replit is one motion, so a change is live the moment you make it, and there is no deploy step between you and the internet to catch a route that lost its login check or a key pasted in to get past a failing build at midnight. A scan you ran last month describes last month's app.

Reeve Monitor is built for this shape of app: somebody who walks past the shop every hour and tries the doors. It re-runs all nine checks every hour on up to three apps, watches uptime every 60 seconds, tells you when a result changes rather than waiting for you to look, and sends a monthly report. It is $12 a month at list, with seven days free before it charges you; the pricing page is sometimes below the figure here and never above it. Monitor watches and nothing more, which for a Replit app is usually the right half: Care, our backup plan, holds a copy of a Supabase database only, and most Replit apps keep their data somewhere else.

What to do this week

The plain-language walkthrough for this platform is is your Replit app safe, and the 10-minute security checklist covers what is worth confirming on any newly launched app.