REPLIT SECURITY CHECKLIST

Replit makes shipping a single file to a real URL trivial — and most security incidents in Replit apps come from that same shortness. The default repl is public, .env is plain text in the file tree, Replit DB has no row-level security, and Replit Agent / Ghostwriter cheerfully wires secrets into client-visible code. The checklist below is what we look for first when we audit a Replit deployment.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once you have users.

How to use this checklist

Walk it once on the deployed repl, ticking items as you go. After each fix, confirm by reloading the deployed URL — the dev preview and the deployed URL can behave differently because they read different env scopes. After the whole list passes, run a black-box scan against the deployment.

Critical (fix before launch)

1. Move secrets from .env into Replit Secrets

Why it matters. .env is a text file in the repl tree. If the repl is public — and the default is public on the free tier — every value in .env is visible to anyone who opens the repl URL. Replit Secrets, by contrast, are encrypted and only readable by the repl’s owner.

How to check. Open the file tree. If .env exists and contains anything other than placeholders, treat the contents as compromised. Cross-check the Secrets pane (lock icon) for what should be there instead.

How to fix. Move each variable to Secrets. Delete .env from the file tree and from .gitignore-untracked history. Rotate every credential that ever lived in .env on a public repl.

2. Make the repl private if it touches real users or production data

Why it matters. Public repls are crawled. The repl URL, the file contents, and any committed .env history end up indexed. We routinely find production database credentials in repls whose owners forgot the visibility toggle.

How to check. Repl settings → Privacy. If the toggle says “Public” and the app handles real data, switch it.

How to fix. Switch to “Private” (Core/Teams plan required). For free-tier accounts, treat every repl as if anyone might read it and keep production secrets out.

3. Audit Replit Database keys for sensitive info

Why it matters. Replit DB is a key/value store with no row-level security. Whoever holds the database URL can read every key. The URL is exposed to your app via env, but it’s also visible if the repl is public or if it ever logged the URL.

How to check. In the Replit DB pane, list keys. If any key contains user IDs, emails, session tokens, or PII, the entire database is one URL leak away from compromise.

How to fix. Don’t use Replit DB for multi-tenant production data. Move to Postgres (Replit-managed or external) with row-level security. If you must use Replit DB, never log the database URL and never expose it to the client.

4. Lock down deployment-domain CORS

Why it matters. Replit deployments expose your app at *.replit.app (or your custom domain). The Express/Flask scaffolds Ghostwriter generates use wildcard CORS, which lets any other site read your authenticated API responses.

How to check. From a different domain in DevTools: fetch('https://your.replit.app/api/users', { credentials: 'include' }).then(r => r.json()). If you get data, CORS is too open.

How to fix. Replace cors() with cors({ origin: ['https://your-domain.com'], credentials: true }). List every domain your frontend will run on; reject everything else.

5. Disable always-on for repls that don’t need it

Why it matters. Always-on keeps the repl process running 24/7, which means an attacker who finds an exploit has a stable target. Repls that wake-on-request have a much smaller exploitation window for slow attacks (cron-driven exfiltration, timing channels).

How to check. Deployment settings — confirm always-on is off unless your app needs it (a Discord bot does, a contact form doesn’t).

How to fix. Switch to autoscale or background deployments instead of always-on where the workload allows it.

6. Replace the auth scaffold’s localStorage tokens with cookies

Why it matters. Replit Agent / Ghostwriter scaffolds auth flows that store JWTs in localStorage. Any XSS — including from a vulnerable npm/pip package — exfiltrates the token. Tokens in cookies marked HttpOnly; Secure; SameSite=Lax cannot be read by JavaScript.

How to check. DevTools → Application → Local Storage on the deployed repl. If you see token, access_token, or anything resembling a JWT, you’re vulnerable.

How to fix. Move the auth callback to a server route that sets the token as an httpOnly cookie. The frontend sees no token at all.

High (fix in the first week)

7. Configure auth provider OAuth redirects to the deployment URL only

In your OAuth provider, the redirect URL allowlist must contain only your real *.replit.app or custom domain. Wildcards and localhost entries left over from development let attackers complete OAuth flows on a domain they control.

8. Add rate limiting via middleware

Replit deployments don’t add rate limiting for you. Add express-rate-limit, Flask-Limiter, or your framework’s equivalent on every public route — especially auth, password reset, and any LLM-calling endpoint.

9. Pin Python/Node versions in replit.nix

Replit’s autodetect can drift to a newer language version after a system upgrade. Pin Python and Node versions in replit.nix so production matches what you tested.

10. Disable Ghostwriter / Agent for files containing secrets

Ghostwriter sends file context to the model. For files with credentials in scope (env loaders, secret config), disable Ghostwriter or move the secrets out before any AI session.

11. Set up automatic backups for Replit DB before launch

Replit DB has no built-in backup. Write a daily dump to object storage (Replit Object Storage, R2, S3) so a misclick or a bad migration doesn’t permanently lose data.

12. Remove sample data and test users before public deploy

Repl templates ship with seed users like admin@example.com / password. Delete these from the database before going public.

Medium (fix when you can)

13. Set security headers in your framework

Add CSP, HSTS, X-Frame-Options, and X-Content-Type-Options via helmet (Express) or your framework’s equivalent. Replit doesn’t add them at the proxy.

14. Restrict who can edit the repl

In repl settings → Multiplayer, audit who has edit access. Anyone with edit access can change deployed code. Remove anyone who shouldn’t be there.

15. Audit installed packages for known vulnerabilities

Run npm audit / pip-audit periodically. Repls accumulate dependencies fast because Ghostwriter installs them as needed; old vulnerable packages stick around.

16. Verify webhook handlers check signatures

Stripe, Discord, GitHub all sign webhooks. Replit-scaffolded handlers usually skip signature verification.

17. Move long-running secrets to a secret manager

For production deployments, prefer HashiCorp Vault, AWS Secrets Manager, or 1Password Connect over Replit Secrets — they support rotation and auditing that Replit Secrets does not.

18. Set up audit logging on auth events

Whatever auth provider you wired up, ship its audit logs to where you can query them long after default retention.

After every Ghostwriter / Agent session

• Re-check .env for newly added secrets.
• Search the diff for cors(), localStorage.setItem, and dangerouslySetInnerHTML.
• Confirm the lockfile (or replit.nix) didn’t change unexpectedly.
• Re-test every privileged route with no auth header.
• Verify the repl is still private if it was supposed to be.

Common attack patterns we see in Replit apps

The public repl with a .env. Developer building a side project leaves the repl public, commits .env with a Stripe live key. Repl URL gets indexed, Stripe key gets used.

The wildcard CORS data dump. Express scaffold uses cors() with no args. Attacker on a different domain reads the entire users endpoint with credentials. Logs look normal.

The Replit DB URL leak. App logs process.env.REPLIT_DB_URL for “debugging”. Logs are accessible to anyone with edit access; suddenly the database is too.

The always-on bot with a stale dependency. Discord bot runs always-on with a 2-year-old library. CVE published; exploit takes minutes. Bot is a persistent foothold inside your account.

Related Resources

How to Secure Replit

Step-by-step guide for hardening a Replit deployment — Secrets vs .env, deployment options, auth migration patterns, and the framework hardening above in long form.

Is Replit Safe?

In-depth analysis of Replit’s defaults — what’s encrypted, what’s public, what Ghostwriter sees, and what we find when we scan a typical Replit deployment.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed repl right now. VibeEval drives a real browser through the deployment, attempts the wildcard-CORS exfiltration and unsigned-webhook attacks above, and reports what got through.