Security Checklists

Replit security checklist: Secrets, exposed ports, and everything you're probably missing.

Mr. BallazMr. Ballaz
April 17, 20265 min read
Focus
Checklist
Risk
High
Stack
Supabase/Next.js
Detection
Ubserve Runtime Simulation
Replit app security checklist before production deployment.

This Replit security checklist helps you avoid public-repl leaks, hardcoded secrets, and always-on endpoint abuse before bots and scrapers find your app first.

A team shipped an MVP from Replit with the repl left Public. The URL got shared, and so did the full source — including database credentials in code comments.

A Replit security checklist covers four vulnerabilities Replit's prototype defaults create when you ship to production: public repl source exposure, hardcoded secrets in code and comments, always-on endpoints with no rate limiting, and missing server-side authentication. Setting repl visibility to Private and migrating all credentials to Replit Secrets are the two steps that eliminate the majority of Replit security exposures. These prototype habits ship fast — a public repl with credentials in code comments exposes your source, database connection strings, and API keys to anyone who finds the URL.

Key Security Risks in Replit-Built Apps

Public repl source exposure: A public repl shows your full source code to anyone with the URL — including database connection strings, API keys in comments, and any credentials left in code from rapid prototyping.

Hardcoded secrets in code and git history: Founders move fast in Replit and leave credentials in .env files committed to the repl's git history, in comments, and in seed scripts. Migrating to Replit Secrets does not clean up existing commits.

Always On endpoints with no rate limiting: Replit's Always On feature keeps your server running 24/7, but any endpoint it exposes is publicly callable without throttling unless you add it yourself. Login routes, data exports, and AI calls are especially vulnerable.

Missing object-level authorization: Replit MVPs frequently protect routes with session checks but skip ownership validation. A logged-in user can often read or modify another user's records by changing an ID in the request.

Database credential sharing across environments: Replit prototype habits often use one database connection string for development, staging, and production. A compromised dev credential gives access to production data.

What Replit doesn't tell you by default

  • Free-tier prototype habits leave repl visibility too open for production use.
  • Hardcoded keys in early iterations persist in git history even after moving to Replit Secrets.
  • Always On endpoints are publicly accessible and can be brute-forced without explicit throttling.
  • Database access paths are often exposed without ownership checks in MVP builds.
  • Public repls expose full source code including comments, seed data, and connection strings.

Repl Visibility & Source Exposure

  • Set your repl to Private before going to production — Public repls expose full source code.
  • Audit who has Collaborator access to the repl and remove anyone who should not have production access.
  • If the repl URL was shared publicly during development, rotate all credentials immediately.
  • Use a custom domain via Replit Deployments rather than sharing the raw repl URL.

Secrets & Environment Variables

  • Move all credentials to Replit Secrets — not .env files in the repl file tree.
  • Search every file, comment, seed script, and test helper for hardcoded tokens and rotate them.
  • Rotate any credential that was ever committed to the repl's git history or in a Public repl.
  • Block secret values from appearing in error responses, logs, and debug output.
# Search for hardcoded secrets before deploy
grep -r "sk-" . --include="*.js" --include="*.ts" --include="*.py"
grep -r "password" . --include="*.js" --include="*.ts"
grep -r "secret" . --include="*.js" --include="*.ts"

Authentication & Route Protection

  • Require auth middleware on every route that reads or mutates user data — not just the dashboard page.
  • Enforce resource ownership checks: verify that the requesting user owns the resource being accessed.
  • Reject client-sent role claims unless revalidated from the server-side session.
  • Test unauthorized access with modified resource IDs, stale tokens, and missing auth headers.
// Common Replit MVP pattern — session check only, no ownership validation
app.get('/api/document/:id', requireAuth, async (req, res) => {
  const doc = await db.find(req.params.id); // ← any authenticated user can fetch any doc
  res.json(doc);
});

// Correct — check ownership
app.get('/api/document/:id', requireAuth, async (req, res) => {
  const doc = await db.find(req.params.id);
  if (doc.userId !== req.session.userId) return res.status(403).json({ error: 'Forbidden' });
  res.json(doc);
});

Database & Storage Security

  • Ensure Neon or Postgres credentials are scoped and not shared across dev and production environments.
  • Restrict direct database operations behind authenticated server routes — no client-direct DB access.
  • Lock object storage access by owner and signed URL requirements.
  • Verify backup scripts and admin tools are not reachable from public-facing routes.
  • If using Supabase, enable RLS on all tables and test with anon and cross-user tokens.

Input Validation & XSS

  • Validate all incoming payloads with strict schemas before processing or storing.
  • Sanitize user content before rendering in templates or React views.
  • Reject unexpected fields and type coercions in JSON request bodies.
  • Test stored XSS in user profiles, comments, and rich text content fields.

CORS & API Configuration

  • Limit allowed origins to your Replit domain and production custom domain only.
  • Remove wildcard CORS from authenticated or write endpoints.
  • Disable verbose stack traces and internal error messages in production responses.
  • Confirm API introspection and documentation routes are not publicly accessible.

Rate Limiting Always On Endpoints

Always On endpoints are permanently exposed. Without rate limiting, they are permanently abusable.

  • Add rate limiting to login, signup, OTP, and password reset routes — these are brute-force targets.
  • Throttle expensive AI and data export endpoints by IP and by user session.
  • Alert on repeated 401 and 403 patterns — these indicate active probing.
// express-rate-limit for Replit Express apps
import rateLimit from 'express-rate-limit';
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 10, // 10 attempts per window
  message: 'Too many login attempts. Try again in 15 minutes.',
});
app.post('/api/login', loginLimiter, loginHandler);

After fixing Replit-specific visibility and secrets gaps, review the pre-deploy security checklist for vibe-coded apps for auth and database controls. If you also use Cursor to develop alongside Replit, the Cursor security checklist covers Workspace Trust and prompt injection risks.

Run Your Security Audit

Want to know which Replit-specific vulnerabilities made it into your production build?

Ubserve scans your codebase for hardcoded secrets, missing auth, unprotected routes, and every pattern on this checklist. Every finding comes with a fix prompt you can paste directly into Replit to resolve before launch.

Audit my Replit app for these vulnerabilities


Most Replit incidents are not caused by sophisticated attacks. They are caused by prototype habits that nobody cleaned up before the app went live.

Run the audit. Fix what it flags. Ship with confidence.

— Mr. Ballaz, Founder of Ubserve

Related resources

FAQs

How do I secure a Replit app before going live?+
Set repl visibility to Private, move all credentials to Replit Secrets, enforce server-side auth on every data route, and add rate limiting before exposing the app to public traffic.
What are the biggest Replit security vulnerabilities for MVPs?+
Public repl source exposure, hardcoded credentials in code and comments, unprotected database routes, always-on endpoints without throttling, and missing object-level authorization checks.
Does Replit Secrets fully solve secret exposure risk?+
Replit Secrets keeps keys out of the current codebase, but only if you actively remove all hardcoded values from code, comments, seed scripts, and git history. Past commits may still contain exposed keys.
Can people see my Replit code if I deploy publicly?+
If your repl is set to Public, yes — anyone can view your source code including environment setup, comments, and any hardcoded values. Always set production repls to Private.
How do I add rate limiting to a Replit Always On app?+
Use express-rate-limit for Express apps, or implement an IP-based counter in your request middleware. Replit does not add rate limiting automatically to any endpoint.
What database does Replit use and how do I secure it?+
Replit commonly pairs with Neon (Postgres), Supabase, or their built-in key-value store. Secure any database by restricting credentials to server-only code, enabling RLS on Supabase tables, and scoping connection strings to the minimum necessary permissions.
Next step

Turn this resource into a real security check.

Review the guidance, then run Ubserve to validate whether this issue is actually exploitable in your app and get fix-ready output.