How to secure a Replit app (Secrets, public repls and databases)

Replit makes it easy to build and deploy in one place. Five habits keep that convenience from turning into a leak.

1. Use Secrets, not code

Put keys in the Secrets panel, not in your source files. Secrets are read on the server with process.env.NAME (Node) or os.environ["NAME"] (Python).

If a key is written in a file, anyone who can see the repl can read it, and public repls are visible to everyone. Rotate any key that was ever in code.

Search the project for hard-coded API keys, tokens and passwords. Replace each with a read from an environment variable and tell me which names I need to add in the Secrets panel. Do not print the values.

2. Keep secrets away from the browser

If your app has a frontend, it should call your own backend for anything that needs a key. Never build a key into a frontend bundle, including through VITE_ variables.

3. Serve only what you mean to serve

A web server that serves the whole project folder will also serve .env, .git and database files. Check your-app.replit.app/.env and /.git/config: both must show “not found”.

Make sure the web server only serves the public/static folder. Confirm that requests for /.env, /.git/config and any .db or .sqlite file return 404.

4. Protect your routes

Every route that returns or changes data needs a server-side check that the caller is signed in and allowed to see that data.

For each API route, add an authentication check that returns 401 when there is no valid session, and make sure users can only access their own records.

5. Databases

If you use Supabase or Firebase from Replit, turn on Row Level Security (Supabase) or write real rules (Firebase). The default “open for testing” rules must not go live.

Scan your deployment

Run Greenlight Scan on your deployed address (not the editor page). It checks the points above from the outside and gives a prompt for Replit Agent for each fix.