Replit Agent security: 6 things to check before going public.

2026-05-08 · vibecheck team · 7 min read · Platform · Replit Agent

Quick answer Replit Agent ships full-stack apps faster than the alternatives because it owns the entire stack — backend, frontend, database, auth, deployment. That breadth is also why the security surface is bigger. The six checks: Secrets correctly stored but referenced wrong (most common), Repl visibility set to public when it shouldn't be, the Agent's auto-generated auth bypass routes left enabled, the deployment URL exposing the IDE, third-party services configured with default ports/credentials, and the database connection string in client-side code.

Replit Agent will scaffold an app with auth, payments, a database, an admin dashboard, and a deployment in about ten minutes. That's incredible. It also means there are about ten places where it can leak.

The good news: Replit's primitives are sound. The Secrets system, the deployment model, and the database integration are all designed to be secure. The bad news: the Agent doesn't always wire them right.

1. Secrets stored but referenced wrong

The Replit Secrets system is correct. You add a secret named STRIPE_SECRET_KEY and it's available in process.env.STRIPE_SECRET_KEY on your server. The Agent uses this correctly for backend code.

The bug shows up when the Agent generates frontend code that needs to call Stripe. It can't access process.env.STRIPE_SECRET_KEY from the browser, so it sometimes works around the limitation by inlining a placeholder — and the placeholder ends up being the real key.

Test: open the Repl in the IDE → Files panel → look at any file under client/ or src/:

# In the Replit shell:
grep -rE '(sk_live_|sk-(proj-)?[A-Za-z0-9]{20}|eyJ[A-Za-z0-9_-]+\.eyJ)' client/ src/ public/ 2>/dev/null

Or run vibecheck against your deployed URL — we'll surface anything in the bundle.

2. Repl visibility

Repls have two visibility settings: the Repl itself (the source code) and the deployment URL (the running app). They're independent. A public Repl with a private deployment exposes your source. A private Repl with a public deployment is normal and fine.

Test:

  1. Click the share icon at the top of the Repl. Confirm "Private" is selected unless you mean for the source to be public.
  2. Open https://<your-username>.replit.com/<repl-name> in an incognito window. If it shows your source, it's public — toggle it back.

For Repls that are public on purpose: scrub the .replit file, any .env or secrets.json in the tree (these should always be in .gitignore; Replit Secrets are not stored in files), and any committed test data.

3. Agent-generated auth bypass routes

When the Agent scaffolds auth, it sometimes leaves a backdoor for "iteration speed" — usually a /dev/login or /test-auth route that lets any visitor become any user. The Agent sometimes flags these in chat ("I added a dev login route — remove this in production") but the route ships if you don't.

Test:

for path in dev test admin debug login-as impersonate auth-bypass quick-login; do
  echo -n "/$path: "; curl -sIo /dev/null -w '%{http_code}\n' "https://your-repl.replit.app/$path"
done

Anything that returns 200 should either be deleted or gated behind a server-side check that rejects requests on production hostnames.

4. Deployment URL exposes the IDE

Replit deploys to <repl-name>.<username>.repl.co or <repl-name>.replit.app. By default the URL serves your running app — but earlier Replit versions and some specific configurations expose the file system or the IDE editor at predictable subpaths.

Test:

for path in '__repl' 'replit.nix' '.replit' '.env' '.git/HEAD' 'shell' 'console'; do
  echo -n "/$path: "; curl -sIo /dev/null -w '%{http_code}\n' "https://your-repl.replit.app/$path"
done

Any 200 here means your IDE state or repo internals are reachable from the internet. The fix is usually a route configuration in .replit that explicitly serves only your app's port.

5. Third-party services with default config

The Agent integrates Stripe, OpenAI, Resend, Clerk, Auth0, etc. by adding the SDK and reading credentials from Secrets. That part is right. What's frequently wrong:

Each of these is a five-minute fix once identified. Read the SDK's "Production checklist" docs.

6. Database connection in client code

Replit's PostgreSQL integration adds a DATABASE_URL Secret that contains postgres://user:pass@host:port/db. This belongs server-side only.

The Agent occasionally generates a db.js module that's imported by both server and client code. If you have a client/db.js or any client component importing the database client, the connection string is in the bundle.

Test from outside:

curl -sL https://your-repl.replit.app/ | grep -oE 'postgres(ql)?://[^\s"<]+'

If anything matches, the URL is leaked. Move the database client to a server-only module:

// server/db.ts — only imported by server routes
import 'server-only';
import { Pool } from 'pg';
export const pool = new Pool({ connectionString: process.env.DATABASE_URL });

Then rotate the database password — the leaked one is compromised.

The deployed-side check

Items 3, 4, 5, and 6 are exactly what the vibecheck scanner tests against any deployed URL. Items 1 and 2 require you to log into your Repl. Take ten minutes.

Inspect your Replit deploy

Related