Security

Replit Agent security checklist: 15 checks before you launch

Short answer

  • Most Replit Agent apps are not insecure because of Replit. They are insecure because the generated code skips checks a senior developer would add.
  • The three most common issues: API keys in code or in the browser, routes that never check who owns the data, and admin features protected only in the UI.
  • Run the 15 checks below in about an hour. Anything marked must-fix should be done before a single real user signs up.

Replit Agent can take an idea to a working app in an afternoon. What it can't do reliably is think like an attacker. The same handful of gaps show up again and again in AI-built apps, and none of them are visible when you click around your own app as the only user.

This is the checklist we run on every Ship-Ready Review. Each check comes with how to test it and how to fix it. Mark each one OK, fix soon or must-fix.

1. Secrets and API keys

Check 1: No keys in the code or its history

Test: search the project for strings like sk-, api_key, secret, password and Bearer. Also check the version history: a key that was committed once and removed later is still exposed.

Fix: move every value into the Secrets pane, read it with process.env or os.environ, and rotate any key that was ever in the code. Deleting the line is not enough. Full walkthrough: Replit Secrets: how to store API keys safely.

Check 2: No keys shipped to the browser

This one is subtle. Agent often calls third-party APIs (OpenAI, Stripe, Google) straight from frontend code. Even if the key sits in Secrets, a build step can inline it into the JavaScript bundle that every visitor downloads.

Test: open your published app, open the browser DevTools, and search the Sources and Network tabs for part of your key.

Fix: move the call to a backend route. The browser calls /api/generate, and the server calls the provider with the secret key.

Check 3: Production has its own secrets

Your published app runs separately from your workspace. Confirm that the published app has every secret it needs, and that it uses live keys in production and test keys in development, especially for payments.

2. Authentication and authorization

Check 4: Every private route requires login on the server

Hiding a page in the menu is not protection. Test: log out, then call your API routes directly (paste the URL in the browser, or use curl). Anything that returns data without a session is a must-fix.

Check 5: Every query checks ownership (the #1 bug)

This is the most common issue in AI-generated code. The route checks that someone is logged in, but not that the record belongs to them:

// Vulnerable: any logged-in user can read any invoice
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  res.json(await db.invoice.findById(req.params.id));
});

// Fixed: the query is scoped to the current user
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, ownerId: req.user.id },
  });
  if (!invoice) return res.sendStatus(404);
  res.json(invoice);
});

Test: create two accounts. Log in as user A, copy the URL or API call for one of A's records, log in as user B and replay it. If B sees A's data, it's a must-fix. Do this for reads, updates and deletes.

Check 6: Admin features are enforced on the server

Agent often protects admin pages with a check like if (user.isAdmin) in the React component only. Test: as a normal user, call the admin API routes directly. Fix: add a server-side role check to every admin route.

Check 7: Sessions and passwords are handled by a proven library

Prefer Replit Auth or an established provider over hand-rolled login code. If the app stores passwords, they must be hashed with bcrypt or argon2, never stored in plain text or with a fast hash like MD5 or SHA-1. Sessions should expire, and cookies should be HttpOnly and Secure.

3. Input and output

Check 8: Inputs are validated on the server

Frontend validation is a convenience for users, not a security layer. Validate every body, query and parameter on the server with a schema (Zod, Pydantic, Joi): types, lengths, allowed values.

Check 9: No raw SQL built from strings

Test: search for queries built with template strings or + concatenation. Fix: use your ORM or parameterized queries everywhere.

Check 10: Uploads are restricted

Limit file types and sizes, store uploads in object storage rather than next to your code, and never serve user uploads as HTML from your own domain.

Check 11: Errors don't leak internals

Stack traces, SQL errors and environment details must stay in your logs, not in API responses. Return a generic message to users.

4. Data

Check 12: Development and production data are separate

Replit now gives published apps a separate production database, and Agent works on the development one. Make sure your app actually uses it, that test data is not being copied to production, and that you know how schema changes get applied. We cover this in detail in Replit development vs production database.

Check 13: Backups exist and you have tested a restore

A backup you have never restored is a hope, not a backup. Know where your restore option is, and try it on a copy before you need it.

5. Dependencies, costs and deployment

Check 14: Dependencies have no known critical vulnerabilities

Run npm audit or pip-audit in the Shell. Fix critical and high issues, and remove packages the app no longer uses. Agent often leaves some behind.

Check 15: Expensive endpoints have limits

Any route that calls an AI model, sends email or SMS, or hits a paid API is a financial attack surface. Add per-user rate limits, a maximum input size, and a spending cap at the provider. One unprotected endpoint can empty a prepaid balance overnight.

Your scorecard

AreaChecksMust-fix if…
Secrets1–3Any key in code, in history or in the browser
Auth4–7User B can see user A's data, or admin routes work for normal users
Input8–11SQL built from strings, or unrestricted uploads
Data12–13Dev and prod share data, or there is no restore option
Ops14–15Critical vulnerabilities, or AI endpoints without limits

Want a quick score first? Take the free Replit Readiness Score. It takes about two minutes. When you're ready to publish, follow our step-by-step guide to deploying a Replit app to production.

Also run Replit's own scanners. Dependency scans run automatically in the Security panel, and paid plans can run a full scan with Security Agent. They catch code-level vulnerabilities well. They can't know your business rules, so checks 5, 6, 12, 13 and 15 still need a human.

Replit also publishes its own security checklist and secure vibe coding tips, which are worth reading alongside this one.

FAQ

Is Replit secure enough for production apps?

The platform gives you the building blocks: encrypted Secrets, separate development and production databases, HTTPS on published apps and built-in authentication. The risk is in the application code. AI-generated code often misses authorization checks, input validation and cost limits, so it needs a review before launch.

Can Replit Agent see my secrets?

Your app reads Secrets as environment variables, and Agent works inside the same project, so treat anything in the workspace as visible to it. Never paste real keys into the chat. Add them through the Secrets pane and use keys with the minimum permissions and spending limits your app needs.

Do I need to re-check security after every Agent change?

Yes, for anything that touches authentication, data access, payments or file uploads. Agent can rewrite a route and silently remove a check. A quick re-test of the authorization and admin checks after each major change catches most regressions.

What is the most common security bug in AI-built apps?

Missing authorization, often called IDOR. The app checks that you are logged in but not that the record you ask for belongs to you, so changing an ID in the URL or API call exposes other users' data.

Book the $199 review