Is my Replit app secure? A plain check before you launch

01

Run Replit’s own scan, and know what it can’t see

Start with what Replit already gives you. In your project, open Tools → Security Center and select Run scan. Replit’s scan levels page explains the three choices:

• Level 1 is free and checks the packages your app depends on for known vulnerabilities. The docs are careful to add that “a clean dependency scan does not mean your own code has no vulnerabilities.”
• Level 2 needs a paid plan and adds an Agent review of your source code, using static analysis tools such as Semgrep alongside the model.
• Level 3 adds a black-box test of your running Preview from the outside. For apps on Clerk Auth, it also signs in as a synthetic user, and creates a second one when it needs to check whether one account can reach another’s data.

Then open Publishing → Adjust settings and make sure Block publishing of critical vulnerabilities is on. Replit’s publishing page says it always runs a security scan before publishing; this setting decides whether a critical finding actually stops the release. In your account’s Settings → Advanced, consider turning on Auto-Protect, which the Security Center docs say is off by default. It has Agent prepare patches when a new vulnerability turns up in one of your packages. A patch only reaches your live app after you apply it and publish again.

Now the part that matters for the rest of this guide. Replit’s docs say plainly that “a scan is not a complete security review.” Its own white paper on securing AI-generated code found that AI-only scans are nondeterministic: “functionally equivalent code can receive different security assessments depending on syntactic form or prompt phrasing.” So treat a clean scan as a starting point. Rerun it after big changes, read each finding before you accept or dismiss it, and keep going.

02

Decide who the app is for before you publish

This sounds too simple to matter. It is the one that got thousands of apps into the news.

In May 2026, WIRED reported on research by the security firm RedAccess. It found more than 5,000 apps built with Lovable, Replit, Base44 and Netlify that had “virtually no security or authentication of any kind.” Around 40 percent of them seemed to expose sensitive data, though WIRED notes it couldn’t confirm the data it reviewed was real. The researchers didn’t break anything to find them. They searched Google and Bing for the builders’ hosting domains. Replit’s CEO, Amjad Masad, replied that “Replit allows users to choose whether apps are public or private. Public apps being accessible on the internet is expected behavior.” Both things are true. The setting exists, and plenty of people never touched it.

Replit’s access docs list four options under Sharing in the Publishing tool:

• Public: anyone on the internet with the address. Apps in a personal workspace start here.
• Password protected: anyone with one shared password, no Replit account needed. Fine for a beta, but it is one password for everybody, not a login.
• Workspace only and Invite only: Replit puts a sign-in screen in front of the app and only lets in people you’ve allowed. Use one of these for anything internal.

So ask the plain question: who is this app for? If the answer is “my team” or “me and a few clients,” it shouldn’t be Public. Changing it on a live app means unpublishing, choosing the new option, and publishing again. If the answer is “anyone who signs up,” Public is right, and your app’s own login is the lock. That is what checks 4 and 5 test.

Two smaller things while you’re here. Your replit.dev preview is private by default. If you ever switched off Private preview under Networking to show someone, switch it back on. For webhooks, Replit’s docs recommend an external access token instead. And look at who you’ve invited to the project. Replit’s Secrets page says a collaborator can see secret values, and even organization members who can’t view them “can access their values by printing the environment variables.” People who remix a public app are different: they get your secret names with empty values and a fresh database.

03

Keep keys in Secrets, and out of anything named VITE_

Every API key, token and password belongs in the Secrets tool (Tools → Secrets), not in your code. Replit encrypts secrets and passes them to your server as environment variables. Its Configurations section is for harmless settings like log levels, and the docs are firm: “Do not store API keys, passwords, or authentication tokens as configurations.” Replit’s publishing page adds that secrets sync to your published app each time you publish, and you can review them under Production app secrets in Adjust settings.

One rule decides whether a secret stays secret: its name. If your front end is built with Vite (look for a vite.config file in your project), any variable whose name starts with VITE_ is copied into the JavaScript that every visitor downloads. Vite’s docs say these variables “should not contain sensitive information such as API keys,” because “the values of these variables are bundled into your source code at build time.” It doesn’t matter that the value sits encrypted in Replit Secrets. Once it’s named VITE_, it’s public the moment you publish.

The quickest check is in Replit’s Shell. These print names only, never values:

# In Replit's Shell: the names (not the values) of every VITE_ variable
printenv | cut -d= -f1 | grep '^VITE_'

# And every place the front end reads one
grep -rn "import.meta.env.VITE_" --include=*.ts --include=*.tsx --include=*.js --include=*.jsx \
  --exclude-dir=node_modules --exclude-dir=dist .

A VITE_ name holding a site address or a publishable key is fine. One holding an OpenAI, Anthropic, Stripe secret, or database value is not. Then check what your live app really ships. This script downloads the scripts your homepage loads, plus the files for screens that load later, and searches them for key-shaped strings. Run it in a terminal on your computer:

APP=https://YOUR-APP.replit.app

# 1. The scripts your homepage loads
curl -s "$APP/" | grep -oE '(src|href)="/[^"]+\.js"' | cut -d'"' -f2 | sort -u \
  | while read -r f; do curl -s "$APP$f"; done > app.js

# 2. Code for screens that load later (Vite keeps it next to the rest, in /assets/)
grep -oE '"\./[A-Za-z0-9_.-]+\.js"' app.js | tr -d '"' | sed 's#^\./#/assets/#' | sort -u \
  | while read -r f; do curl -s "$APP$f"; done >> app.js

# 3. Anything shaped like a secret key or a database password
grep -ohE "sk-(proj|ant)-[A-Za-z0-9_-]{20,}|sk_live_[A-Za-z0-9]+|rk_live_[A-Za-z0-9]+|whsec_[A-Za-z0-9]+|AKIA[0-9A-Z]{16}|postgres(ql)?://[^\"' ]+|mongodb(\+srv)?://[^\"' ]+" app.js | sort -u

We tested it on a small Vite and Express app with two fake keys passed to the build as VITE_ variables. One was an OpenAI key used on the homepage, the other a Stripe secret key used only on a lazily loaded admin screen. The script found both. When we moved the keys to the server and rebuilt, it found nothing. Nothing printed is what you want. A real key in the output means you should treat it as already public. Rotate it at the provider first, put the new one in Secrets under a name without VITE_, and have Agent move the call to the server:

Find every place the front end reads a variable that starts with VITE_. For each one that holds an API key, token or password, move the code that uses it into a server route, read the key there with process.env from Secrets, and delete the VITE_ variable. List what you moved. Don't change anything else.

Then publish again, and run the script once more. Our guide to leaked API keys in your frontend bundle has a longer script that follows every file name, which keys are public by design, and the order to rotate in. One more habit, straight from Replit’s shared responsibility page: “Don’t paste API keys, tokens, or credentials into the chat.” Agent can use a secret without ever seeing it.

04

Knock on your API routes without signing in

Your server answers requests at addresses like /api/notes or /api/orders. The page uses them to fetch data, but they aren’t part of the page. Anyone can call them directly, with no browser and no login, and the only thing between a stranger and your data is the check at the top of each route. Replit’s security checklist says to “add authentication to sensitive endpoints.” Its Replit Auth page says to “always validate user authentication server-side before performing sensitive operations.” Hiding a button for signed-out visitors doesn’t count.

First, list your routes. In Replit’s Shell:

# In Replit's Shell: every API route your server defines
grep -rnE "\.(get|post|put|patch|delete)\(\s*[\"'\`]/api" \
  --include=*.ts --include=*.js --exclude-dir=node_modules --exclude-dir=dist .

Each line shows one route. If your app uses a sign-in guard, its name usually sits on that same line, between the address and the handler, so routes without one stand out (unless the app guards a whole group of routes in one place, which Agent can tell you). If you ran the script from check 3, this lists every API address your front end mentions, which is what a stranger sees:

# Every API address your front end mentions (run after the script in check 3)
grep -oE "[\"'\`]/api/[A-Za-z0-9_/-]+" app.js | cut -c2- | sort -u

For each route that returns data, ask for it the way a stranger would, with no cookie at all:

curl -i https://YOUR-APP.replit.app/api/notes

On our test app, the route written carelessly answered 200 OK with every user’s notes and email address. The one that checked for a session answered 401 Unauthorized. A route meant for signed-in users should give you the second. If you get data back, ask Agent to fix it, then knock again:

Go through every route in the server under /api. For each one that reads or changes user data, make sure it checks that someone is signed in before doing anything, and returns 401 if not. List every route, whether it needed the check, and what it checks now. Don't change anything else.

Stick to plain GET requests like the one above. Don’t send POST or DELETE requests at your live app to see what happens, because they really run.

05

Check that every record belongs to the person asking

Check 4 asks “is anyone signed in?” This one asks the harder question: “is this theirs?” It’s the mistake we’d bet on finding in a new app. A route checks for a login, then fetches note number 42 for whoever asked, without checking that note 42 belongs to them. Change the number in the address and you’re reading someone else’s note. Replit’s shared responsibility model puts “usage policy / access control” squarely with you, and asks you to “tell Replit Agent who should have access to which functionality of your app.” Agent can only build the rule you describe.

In code, the fix is to put the user in the query itself, so the database only ever returns or changes their rows. Here is what that looks like in Express with Drizzle, the stack from Replit’s example. Your app will name things differently. With Replit Auth or Clerk, the signed-in user comes from their library rather than req.session.userId. The shape is the same:

import type { Express, NextFunction, Request, Response } from "express";
import { and, eq } from "drizzle-orm";
import { db } from "./db";
import { notes } from "./schema";

// 1. No signed-in user, no data.
function requireUser(req: Request, res: Response, next: NextFunction) {
  if (!req.session.userId) return res.status(401).json({ message: "Unauthorized" });
  next();
}

export function registerNoteRoutes(app: Express) {
  // 2. Only the caller's own notes, never everyone's.
  app.get("/api/notes", requireUser, async (req, res) => {
    res.json(await db.select().from(notes).where(eq(notes.userId, req.session.userId!)));
  });

  // 3. Only delete the note if it belongs to the person asking.
  app.delete("/api/notes/:id", requireUser, async (req, res) => {
    const deleted = await db
      .delete(notes)
      .where(and(eq(notes.id, Number(req.params.id)), eq(notes.userId, req.session.userId!)))
      .returning({ id: notes.id });
    if (deleted.length === 0) return res.sendStatus(404);
    res.sendStatus(204);
  });
}

The important part is and(eq(notes.id, …), eq(notes.userId, …)). Drizzle’s filter operators combine the two conditions, so a note that isn’t yours simply isn’t found. We ran this against a test database with two users. Signed in as the second user, deleting the first user’s note returned 404 and the note was still there. The careless version, which filtered on the note’s ID alone, returned 204 and the note was gone. To get Agent to apply the rule everywhere, describe who should see what in your own words:

Here is who should see what in this app: [describe it, e.g. "each customer sees and edits only their own bookings; staff can see all bookings; only I can change prices"]. Go through every server route and every database query. Make sure each one only returns or changes records the signed-in user is allowed to touch, by filtering on their user id or checking their role in the query itself. List each route you changed and the rule it now enforces.

Then do the test no code reading replaces. Make two accounts. Sign in as the second, and try to open something that belongs to the first, for example by pasting the address of the first account’s booking or profile, or changing the ID in it. You should get nothing. If you have an admin screen, sign in as an ordinary user and try its address too. A page that only hides the admin menu isn’t a lock. The route behind it has to check the role. Do all of this in the browser, on your own test accounts.

06

Know which database your live app uses, and who can touch it

Replit’s database setup is different from most builders’, and it changed after a very public bad day. In July 2025, the SaaStr founder Jason Lemkin was building an app with Replit Agent. During what he had declared a code freeze, the agent wiped his database. Masad posted that the “agent in development deleted data from the production database. Unacceptable and should never be possible.” He said Replit was rolling out automatic separation of development and production databases “to prevent this categorically.” As The Register reported, Replit’s announcement admitted that until then, Replit apps “used a single database for both development and live customer data.”

Today, Replit’s database docs say “Agent is not able to modify the production database.” That is a real improvement. Here is what is still worth checking:

• What gets copied when you publish. Agent can still change the structure of your development database, and the docs say those changes, like added or deleted columns and tables, “are applied to your production database” when you publish. Before publishing a change that removes or renames a column, ask Agent what it will do to existing data.
• Test data. Older Neon-based setups offer to copy your development data into production. Replit warns to do that only if the data is safe for the live app, because it “can include test accounts.” A leftover test admin with password test123 is a classic way in.
• Which connection string you have. Open the Database tool’s Settings tab. If your development DATABASE_URL contains neon.tech, you’re on the legacy setup, which Replit says “used a full connection string. If leaked, anyone could access and modify your database.” A helium one is the current setup, which is “only accessible from within your app.” Your production database is different. Its connection string works from any PostgreSQL client, so treat it as a password. Never put it in code, in a prompt, or behind a VITE_ name. If it leaks, the connection details page explains how to regenerate the credentials.
• Backups. A checkpoint rollback can restore your development database, but Replit notes it doesn’t restore production. Production has point-in-time restore, seven days by default, and you can turn on daily backups in the Database tool, per the data recovery docs. Check it’s on before you have customers.

If your app keeps its data in Supabase or Firebase instead, the browser may talk to the database directly, and the rules on that database become a second lock. Our Supabase RLS checklist and Firebase rules checklist cover those.

07

Make sure your server only hands out what you built

Your server sends the built front end to visitors from a folder. If it’s the wrong folder, or the build publishes more than it should, strangers can download things you never meant to share.

Source maps turn your compressed JavaScript back into readable source, comments and all. Vite turns them off for production builds by default, but one line in its config turns them back on. Project files leak when a server serves its whole project folder instead of the built one. Express helps a little. Its static file middleware ignores files whose names start with a dot by default, but its docs add that this default “will not ignore the files within a directory that begins with a dot.” We tried it. A test server pointed at its project folder answered /.env with a 404 but handed out /.git/config and package.json.

APP=https://YOUR-APP.replit.app
f=$(curl -s "$APP/" | grep -oE 'src="/[^"]+\.js"' | cut -d'"' -f2 | head -1)
for p in "$f.map" /.env /.git/config /.replit /package.json; do
  curl -s -o /dev/null -w "$p  %{http_code}  %{content_type}\n" "$APP$p"
done

Read the two columns after each path. For the .map line, 404 is what you want. A 200 with application/json means your source is public. For the rest, many apps send the homepage for any address they don’t know, so a 200 with text/html is just that, and fine. A JSON or octet-stream answer for /package.json or /.git/config means the server is handing out your project. If either turns up, ask Agent:

Make sure that in production the server only serves the built front-end folder, never the project folder, and that the production build does not publish source maps. Show me the lines you changed.

If your app takes uploads, the same idea applies. Keep files in Replit’s App Storage, as its checklist suggests, and serve them through a route that runs the checks from 4 and 5. Don’t use a public folder.

08

Add the headers and cookie settings Express leaves out

Headers matter less than everything above, and a missing one won’t leak data on its own. But they tell browsers how to protect your visitors, and a plain Express server sends almost none:

curl -sI -H "Origin: https://example.com" https://YOUR-APP.replit.app \
  | grep -iE "^(content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|x-powered-by|access-control-allow-origin|set-cookie)"

On our careless test app, three lines came back. X-Powered-By: Express, which Express’s security guide says it sends by default. Access-Control-Allow-Origin: *, from the cors package with no options, which its docs say means any origin. And a session cookie with no Secure or SameSite flag, because express-session’s defaults are httpOnly: true, secure: false. The fix is a few lines, and it is what Express’s own guide recommends: Helmet for headers, and explicit cookie settings.

import express from "express";
import helmet from "helmet";
import session from "express-session";

const app = express();

app.set("trust proxy", 1);
app.use(helmet());
app.use(
  session({
    name: "sid",
    secret: process.env.SESSION_SECRET!,
    resave: false,
    saveUninitialized: false,
    cookie: { httpOnly: true, secure: true, sameSite: "lax" },
  }),
);

With that in place, our test app sent a content security policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options and Referrer-Policy. X-Powered-By was gone, and the cookie came back as HttpOnly; Secure; SameSite=Lax. Ask Agent to merge it into your server rather than paste it over the top, because your app probably already has a session store you need to keep. Three notes:

• Helmet’s default policy is strict. It only allows scripts from your own site, which suited our test app. If yours loads Stripe, analytics or fonts from elsewhere, those need adding. MDN explains the directives. Try it in Preview and watch the browser Console for blocked requests.
• trust proxy is there because express-session won’t send a Secure cookie when it thinks the connection isn’t HTTPS, which is what it sees behind a proxy. Its docs show exactly this setting. If sign-in stops working after the change, check this line first.
• CORS is not a lock. The cors docs put it plainly: “CORS is not access control. Any HTTP client (curl, Postman, another server) can call your API regardless of CORS settings.” If your pages and API share one address, as they usually do on Replit, you may not need the package at all.

To see the cookie your app sets after sign-in, open DevTools → Application → Cookies and check the HttpOnly, Secure and SameSite columns. MDN’s cookie guide explains what each one stops.