SCAN YOUR REPLIT APP FOR VULNERABILITIES

Replit Agent turns a prompt into a full application — server routes, database queries, auth flows — and deploys it to a live *.replit.app URL in one session. The platform is mature: container isolation between projects, automatic HTTPS, built-in Secrets, SOC 2. What catches builders out is the combination of public-by-default repls, Agent output that ships without review, and a fork model that carries code but not security configuration.

The Agent ships working code, not audited code. Generated endpoints frequently lack an ownership check, generated SQL sometimes uses string concatenation, and generated forms often skip server-side validation. Treat Agent output like a junior engineer’s first draft: a useful start that must be reviewed before it faces real users. Meanwhile, on the free tier the repl itself is public — source, .env, and git history included — and key-harvesting bots scrape the discovery feed, so a Stripe key committed even briefly gets tested against the API within minutes.

A black-box scan against the deployed URL tests what an attacker reaches: exposed keys in the bundle, endpoints with no auth, BOLA across users, missing rate limits, and stray dev routes — none of which the Replit workspace preview reflects, because it runs as you with your own data.

Common vulnerabilities we find in Replit apps

Hardcoded secrets in Agent output and public repls

The Agent writes API keys straight into config files to get a working run, and .env is plain text in a repl tree that is public by default. Even after you move a value to Replit Secrets, the original sits in git history, which forks inherit and bots scrape. Move every credential to Secrets, make the code crash loudly when a Secret is missing rather than fall back to a hardcoded default, and rotate anything that ever appeared in source. The Token Leak Checker finds what shipped in the bundle.

Agent endpoints with no auth or ownership check

app.get('/api/users/:id', ...) returns user data without verifying the requester owns it — the BOLA pattern, and the most damaging class in Agent-built apps. requireAuth middleware confirms a valid session but not ownership; those are two separate lines, and the Agent most often forgets the second. Sign in as user B, request user A’s ID, and if A’s data returns you have a BOLA.

app.get("/api/projects/:id", requireAuth, async (req, res) => {
  const p = await db.projects.findOne({ id: req.params.id });
  if (!p || p.owner_id !== req.user.id) return res.status(403).end();
  res.json(p);
});

Replit Database used as a multi-tenant store

Replit DB is a key/value store with no row-level security — whoever holds the database URL reads every key. That URL reaches your app via env, but leaks if the repl is public or if the app ever logs it “for debugging.” For real user data, use Postgres (Neon, Supabase, RDS) with proper access policies; never log the DB URL or expose it to the client.

Exposed dev, debug, and seed routes

Agent scaffolds often leave /dev, /debug, /seed, or an admin shortcut that dumps data or resets the database, plus seed users like admin@example.com / password. Promoted to production, these become an open door. Remove debug and seed routes from the production build and delete demo users before deploy.

Wildcard CORS and localStorage tokens

Ghostwriter/Agent Express and Flask scaffolds ship cors() with no args, so any site reads your authenticated API from a visitor’s browser; test with a cross-origin fetch(..., { credentials: 'include' }) and pin the origin to your domain. The same scaffolds store JWTs in localStorage, where any XSS exfiltrates them — move tokens to HttpOnly; Secure; SameSite=Lax cookies. See CORS credentials misconfig.

No rate limiting or WAF on deployments

Replit Deployments include HTTPS and DDoS mitigation but no WAF or per-endpoint rate limiting. An unauthenticated login endpoint is a brute-force target; an AI-inference endpoint without a per-user quota is a wallet-drain target. Add express-rate-limit (or Flask-Limiter) with separate limits on auth and inference paths, and put Cloudflare in front for higher traffic.

const authLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 5 });
app.post("/api/login", authLimiter, loginHandler);

How VibeEval works with Replit

1. Enter your deployed Replit URL (*.replit.app or a custom domain). Optionally provide two test logins for authenticated and cross-user checks.
2. The agent drives a real browser and the API surface. It maps routes, hits endpoints with no auth header, replays one user’s requests as another to probe BOLA, fires cross-origin requests to test CORS, reads the bundle for exposed keys, checks security headers, and looks for exposed dev/debug/seed routes.
3. You get a report of findings by severity, each with the request that proved it and a paste-ready fix — the ownership check, the rate limiter, the CORS config — you can feed back into the Agent.

Manual testing vs VibeEval

Manual review still owns logic and data-model decisions the Agent can’t reason about. The scanner wins on repeatability: every Agent session can rewrite security-critical code, so the check that counts is the one you can rerun in full after each session.

Frequently asked questions

Can VibeEval scan private or deployed Repls?

VibeEval scans deployed applications. If your repl is deployed — even privately — the agent can scan it with authenticated access using test credentials you provide.

Why scan if the app runs fine in the workspace?

The workspace preview runs as you, with your data, and reads different env scopes than the deployment. It never tests what an anonymous request reaches, what a second user can read, or what shipped in the public bundle — which is where Agent-generated gaps land.

How do I keep secrets out of a scan finding?

Use Replit Secrets for every credential, never .env on a public repl, and rotate anything that touched source or git history. VibeEval checks for the exposure patterns; fixing them is moving keys to Secrets and rotating.

Can I scan a Replit template before building on it?

Yes — deploy the template and scan it. Forks inherit code but not the parent’s Secrets, middleware, or infra protections, so a “secured” template can ship insecure. Scanning the fork confirms what actually carried over.

Related Replit resources

• How to Secure Replit — full hardening guide, Secrets to deployment.
• Is Replit Safe? — public repls, secrets, forks, and Agent risks.
• Replit Security Checklist — pre-launch checklist, critical-first.
• Token Leak Checker — find exposed keys in your deployed repl.
• BOLA in AI-Generated CRUD — the ownership-check failure in depth.

Test your Replit app before launch

Replit Agent gets you from prompt to a live URL fast, and it ships working code before audited code. Scan the deployed URL before you publish — exposed keys, auth on every endpoint, cross-user BOLA, and stray debug routes, in one pass.