What Replit typically generates and where the trust boundary is
Replit's documentation describes building with an agent, adding a database, using built-in authentication and publishing the result. The generated stack varies with your prompt: it might be a Node or Python server with a front end, a static site or a full-stack framework. Open the project, find the entry file, list every route and identify where data is stored.
Because the same workspace holds code, running processes and configuration, the boundaries to check are different from a split front end and hosted backend. First, what the public can reach: a published address serves whatever your server exposes, including debug routes and admin pages created along the way. Second, what the code can reach: the environment where it runs may hold credentials for your database and third-party services. Third, who can see the project itself, since a public project shares its files.
Replit's security checklist for vibe coded applications groups advice into front-end, back-end and practical habits. It mentions keeping sensitive data server-side with Replit Secrets, validating and sanitizing input, using established authentication libraries, checking authorization before actions, parameterized queries, security headers, safe cookies and rate limiting. It says Replit provides many security features out of the box and that you are still responsible for measures specific to your application. Use that page alongside this one and check it for updates.
The review checklist
| Area | What to verify | How to test on your own project | Pass condition |
|---|---|---|---|
| Project visibility | Your project files are shared only as intended. | Check the project's visibility setting and who can view or fork it. | Private code is private, and any public project contains no secrets. |
| Secrets storage | Keys and passwords sit in Replit Secrets and not in source or committed files. | Search source and history for secret patterns with the commands below. | No hits, and every secret is read from the environment. |
| Published environment | The published app has the secrets it needs and nothing extra. | Compare the secrets available to the published app with those the code reads. | Only necessary secrets are present, and none are printed in logs. |
| Debug and admin routes | No debug, test or admin route is reachable on the public address. | Request likely paths on your live address and read your route list. | Admin and debug paths reject unauthorized callers or do not exist. |
| Authentication | Login uses an established library or service and sessions are safe. | Inspect session cookies for HttpOnly and Secure flags. | Cookies carry both flags and logout ends the session. |
| Authorization | Every data route checks that the caller owns the record. | Use two accounts and swap record ids in requests. | Cross-user reads and writes are rejected. |
| Database access | Queries are parameterized and the database is not open to the internet. | Read the data access code and review how the connection string is used. | No string-built queries and no credentials in code. |
| Headers and input | Security headers are set and input is validated server-side. | Run the header check and send malformed input with curl. | Expected headers present and invalid input is rejected. |
Commands and queries to run
Open the Replit shell for your own project. The searches find secret-shaped strings in files and in history, and the environment listing shows names only.
The env command cuts the value off, so you review names without printing secrets to the screen. Do not paste the values of secrets into chats or issues. Python projects can use pip-audit in place of the last command.
grep -rnE "sk_live_|sk-[A-Za-z0-9]{20,}|BEGIN PRIVATE KEY|postgres://[^ ]+:[^ ]+@" . --exclude-dir=node_modules --exclude-dir=.git
git log --all -p -S"BEGIN PRIVATE KEY" | head -50
env | cut -d= -f1 | sort
npm audit --omit=devTest the published address as an outsider
Use your own published address. Check the response headers, request paths that should not exist, and try to act as one user on another's record.
Replit's checklist points to securityheaders.com for scanning your site, which is another way to review headers. For the routes, the pass result is a rejection code and never real data. For the last request, the server should return a validation or authentication error, and should never accept a client-supplied owner id.
export APP="https://your-app.example"
curl -sI "$APP" | grep -iE "strict-transport|content-security|x-frame|x-content-type"
curl -s -o /dev/null -w "%{http_code}\n" "$APP/admin"
curl -s -o /dev/null -w "%{http_code}\n" "$APP/debug"
curl -s -o /dev/null -w "%{http_code}\n" "$APP/api/users"
curl -i -X POST "$APP/api/notes" \
-H "Content-Type: application/json" \
-d '{"text":"", "userId":"someone-else"}'Agent-built code and data in one workspace
When an agent builds and runs the app in the same workspace, it can add routes, install packages and create databases in ways you did not request. After each substantial agent session, list the routes, look at the dependency changes and check what data stores now exist. Delete demo pages and sample data before publishing.
Be deliberate about data. A prototype often starts with fake records and then real users arrive. Before that happens, confirm the database is not reachable except through your server, confirm backups and access are set up according to the current documentation, and decide what personal data you truly need. Replit's documentation on storage and databases and on publishing describes the available options and settings, so read the current versions for your plan.
Common mistakes with this workflow
- Pasting a key into the source file to make it run once, then leaving it there.
- Sharing a public project that contains a file with credentials in it.
- Publishing with debug output on, so errors reveal paths, queries or secrets.
- Trusting the agent's statement that the app is secure. Verify with requests.
- Building your own login system instead of using an established library or service.
- Leaving sample users, seed data and test admin accounts in the published app.
- Testing only as the owner, which hides missing authorization checks.
Keep it working
Re-run the searches, the dependency audit and the outsider requests after every agent session and before every publish. Rotate any secret that ever appeared in a file, a log or a chat. Pass condition: no secret is in source or history, the public address rejects unauthorized and cross-user requests, and the expected security headers are present.
Frequently asked questions
Where should I store API keys on Replit?
Replit's own checklist says to keep sensitive data server-side using Replit Secrets. Read them from the environment in server code, never from client code, and never write them into files. Check the current documentation for how secrets carry into a published app.
Does publishing make my app safe?
Replit's checklist says HTTPS is handled by default, and that Replit provides many security features out of the box. It also says you must still implement measures specific to your application, such as authorization and input validation. Test the live address yourself.
Is my code visible to others?
That depends on the project's visibility setting and plan. Check your current settings and the documentation, and assume anything in a public project is readable and copyable, including anything ever committed.
Can I let the agent handle security fixes?
You can ask, and then verify. Re-run the searches and requests in this checklist after any fix. Agent changes can resolve one finding while opening another, so evidence from tests matters more than a summary in chat.