Is Replit Safe? 7 Security Risks to Check in Your Replit App

Is Replit safe to use?

That question has two parts. The first is about Replit the platform: where your app runs, how your secrets are stored, who can reach the servers. The second is about the app you built on it: who can open it, who can call its API, and what happens to your data when the Agent makes a change. Replit answers the first one well. The second one is yours, and Replit says so in writing.

Its shared responsibility model lists user management, access control, the data your app handles, penetration testing of your app and application-level monitoring as your job. Replit ships the controls. You decide which ones to switch on and how to configure them.

What Replit secures for you

Credit where it is due. Replit covers more of the platform side than most AI builders:

• Isolation. Every customer gets its own Google Cloud project, even on the free tier, and each project runs in its own hardened Linux container (Replit security).
• Edge protection and encryption. DDoS protection and a web application firewall sit in front of every deployment, and Replit handles TLS for traffic and encryption of the data it stores (shared responsibility model).
• Secrets. The Secrets tool encrypts values with AES-256 at rest and TLS in transit, and hands them to your code as environment variables (Replit Secrets).
• Separate databases. Since a beta that started in July 2025, apps get a development database for building and a separate production database for live data (The Register). The Agent can change the development database and cannot modify production. On Replit's current database, the connection is only reachable from inside your app and is never exposed publicly (development and production databases).
• Scans before publishing. Replit runs a security scan before every publish and can block publishing when it finds a critical issue (Project Security Center). Basic security scans arrived in May 2025. Security Agent, a deeper review of the whole codebase for paid builders, arrived in April 2026.
• Compliance and testing. Replit has been SOC 2 Type II certified since August 2025, runs a public HackerOne bug bounty and commissions penetration tests from Trail of Bits (Replit security).

That is a solid platform. None of it decides who your app lets in.

Two incidents worth knowing about

Two public stories shape how people answer "is Replit safe". In July 2025, SaaStr founder Jason Lemkin reported that Replit's Agent deleted a production database during a session where he had asked for a code freeze. Replit's CEO Amjad Masad called it "unacceptable and should never be possible", and Replit started rolling out automatic separation of development and production databases (The Register). Replit was able to recover the data (Fast Company).

In May 2026, the security firm RedAccess reported finding more than 5,000 apps built with Lovable, Replit, Base44 and Netlify that had virtually no security or authentication (WIRED). Masad replied that Replit lets users choose whether apps are public or private, and that public apps being reachable on the internet is expected behavior (Axios).

The first story is about what the Agent can do to your data. The second is about a setting the builder chooses. You can check both today, along with five more.

Risk 1: The app is public when it should not be

When you publish, you choose who can open the app: Public, Password protected, Workspace only, or Invite only. Apps in a personal workspace default to Public. Apps in an organization workspace default to a private option (who can access your app). An internal tool or a client portal published with the personal default is open to anyone who has the URL.

How to check: Open the Publishing tool and look at the Sharing setting. Then open the app's URL in a private browser window. If you see your data without a sign-in screen, so can everyone else.

How to fix: Pick Password protected for a beta or a demo, and Workspace only or Invite only for internal tools. Replit handles the sign-in screen with no code changes. Changing access on a live app means unpublishing, choosing a new option and publishing again. For an app real customers sign up to, Public is the right choice, as long as Risk 2 is covered.

Risk 2: API routes that answer without checking who is asking

A Replit app usually ships with its own backend: the pages, plus a server that talks to the database. That server is where access control has to happen. In an independent pentest of a Replit-built app, Astra found authorization enforced in the interface but not on the server, and called broken access control the most severe failure in its study whenever it appeared (Astra). Replit's own Auth documentation says to "always validate user authentication server-side before performing sensitive operations" (Replit Auth).

Hiding a button does not protect the data behind it. If /api/orders returns orders to anyone who calls it, the sign-in screen is decoration.

How to check: Find the API paths your frontend calls (the Network tab in your browser's DevTools lists them), then call one with no session:

curl -i https://your-app.replit.app/api/orders

A private route should answer 401 or 403, not data. Then sign in as one test user and request another user's record by changing the ID in the URL. You should get nothing back.

How to fix: Every route that returns or changes private data needs a server-side check, and every query needs to be scoped to the signed-in user. In an Express backend using Drizzle, that looks like this:

function requireUser(req, res, next) {
  if (!req.user) return res.status(401).json({ error: 'Sign in required' });
  next();
}

app.get('/api/orders', requireUser, async (req, res) => {
  // Only this user's orders, never the whole table
  const rows = await db.select().from(orders).where(eq(orders.userId, req.user.id));
  res.json(rows);
});

Where req.user comes from depends on your sign-in setup. In the Agent, prompt: "Add a server-side authentication check to every API route that returns or changes user data, and scope every query to the signed-in user."

Risk 3: A key that ends up in the browser

The Secrets tool keeps keys encrypted and out of your files. The leak happens later, when a key gets copied somewhere public. Replit's docs name the usual routes: a public Replit project, a public Git repository, and screen sharing (Replit Secrets). Frontends add one more. Vite puts any variable prefixed with VITE_ into the JavaScript every visitor downloads, and its docs warn that these variables should not contain API keys (Vite). A key stored in Secrets is still public if browser code reads it.

How to check: Search the project from the Shell:

grep -rnE "sk_live_|sk-[A-Za-z0-9_-]{20,}|VITE_[A-Z_]*(KEY|SECRET|TOKEN)" . --exclude-dir=node_modules --exclude-dir=.git

Then open the published app, go to DevTools > Sources, and search the loaded JavaScript for the first characters of each key you use.

How to fix: Store every credential in Secrets, read it only in server code, and have the frontend call your own API route instead of the outside service. Keep keys out of the Agent chat: Replit's guidance is that pasting a key there "turns a managed secret into an unmanaged one" (shared responsibility model). Treat any key that ever sat in code or in a bundle as exposed and rotate it with the provider, because checkpoints and Git history still hold the old files.

Risk 4: The Agent and your live data

The July 2025 deletion happened because an agent with database access did something nobody asked for. Replit's answer was structural: on current apps the Agent can edit the development database but cannot modify production. Two gaps remain. Structural changes you make with the Agent in development, such as adding or deleting columns or tables, are applied to production when you publish. And under the legacy Neon setup, development and production shared one database unless you created a production database when publishing (development and production databases).

How to check: Open the Database tool and confirm you see a separate production database. Before each publish, read the schema changes the Agent made: a dropped column in development becomes a dropped column in production. Know your recovery window too. Development rolls back to an Agent checkpoint, with up to 7 days of history. Production has point-in-time restore, up to 7 days on Core and up to 28 days on Pro and Enterprise, set to 7 by default (data recovery).

How to fix: Use Plan mode, where the Agent reads your project without changing any files, before a change that touches data (Plan vs. Build mode). Review schema changes before you publish. Learn the restore path before you need it: a rollback leaves your database alone unless you select it, and it never restores production (checkpoints and rollbacks). Restoring the production database does not restore your code either, so bringing both back means restoring the database, rolling back to the matching checkpoint and publishing again (data recovery).

Risk 5: Vulnerable packages nobody updated

Your app depends on open-source packages, and vulnerabilities in them keep being disclosed after you publish. Replit's automatic dependency scans check your packages against public vulnerability records for free and show matches in the Security pane (Project Security Center). Detection is Replit's part. Fixing them is yours (shared responsibility model).

Auto-Protect, launched in April 2026, goes a step further: when a matching vulnerability appears, the Agent prepares and tests a patch and emails you a link. Both of its settings are off by default, it covers dependency vulnerabilities only, and the patch reaches your live app only after you apply it and republish (Project Security Center).

How to check: Open the Security pane and look for open dependency findings. For a Node app, you can also run this in the Shell:

npm audit --omit=dev

How to fix: Turn on Auto-Protect patch preparation (a workspace admin sets the minimum severity under Settings > Advanced) and security emails (Settings > Personalization > Email Notifications). Apply the patches it prepares, then republish. A fix waiting in the Security pane is not live.

Risk 6: Publishing past a critical finding

Replit scans before every publish, but a setting called Block publishing of critical vulnerabilities decides what happens next. With it off, publishing goes ahead and the finding waits for you in Security Center. That pre-publish check is also lighter than a full review (Project Security Center). The deeper Security Agent scan maps routes and data flows, builds a threat model, runs static analysis with Semgrep and HoundDog.ai, and can take up to 15 minutes on larger projects (Agent security scans).

How to check: In the Publishing tool, confirm the block setting is on. Open Security Center and see whether a Security Agent scan has ever run on this app.

How to fix: Turn the block on. Run a Security Agent scan before your first real launch, send the findings you accept to the Agent, then rerun the scan to confirm they are gone. Replit's docs say a scan "is not a complete security review", so pair it with the hands-on checks in Risks 1 to 4.

Risk 7: Error messages, headers and rate limits nobody asked for

The Astra pentest also found the quiet gaps: rate limiting that was never set up and security headers that were never added (Astra). Default error handling can add a third, sending stack traces or raw database errors to the visitor.

How to check: Look at the headers your app sends:

curl -I https://your-app.replit.app

Look for Content-Security-Policy and Strict-Transport-Security. Then try signing in with a wrong password eight times in a row. Astra suggests checking that the sixth attempt is rejected. Finally, submit a broken form or visit a broken URL and read what comes back.

How to fix: Catch errors in one place, log the detail on the server and show the visitor a generic message:

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Something went wrong' });
});

Then ask the Agent for rate limiting on sign-in, sign-up and password reset, and for security headers on every response. Be specific. Astra's advice is to swap every adjective in the prompt for a number or a named control: "lock the account after five failed attempts and return a 429" is a requirement the Agent can build, "secure login" is not.

What to do next

Work through these seven before customers depend on your Replit app. Risks 1 to 3 catch the failures that expose data. Risks 4 to 7 keep it that way while the Agent keeps changing things. For the wider question of whether Replit fits a production app at all, read Is Replit good for production apps?

If you would rather not run the list by hand, BWorlds audits apps built with Replit and other AI builders across security, reliability, data protection, performance, costs and code quality. Each finding comes with a plain-language diagnosis and a fix prompt to paste into Replit's Agent, and BWorlds checks that the fix landed. Once the app is live, it keeps watching: uptime, errors and session replays through the LaunchKit SDK, plus a GitHub connection that spots code changes. Sign up free, paste your app's link and get a first read in minutes, before you connect any code. Connecting the code gives you the full audit.