Replit app security checklist

Replit puts building and publishing in one place, which is a big part of why people like it. You can go from an idea to a working .replit.app link in an afternoon. The flip side is that it's easy to publish before you've thought about who else can use what you built.

This is the checklist I'd go through before sharing a Replit app. It leans on Replit's own tools where they exist, and covers the parts they don't.

1. Every key lives in Secrets

Replit has a Secrets tool for API keys, tokens, and passwords. Replit encrypts them and gives them to your code as environment variables. That's where every key belongs.

What you want to avoid is a key typed straight into your code. It can end up in the page a visitor downloads, or in a copy of your project someone else opens.

1. Open Tools → Secrets and check your keys are there.
2. Search your code for anything that looks like a key, such as sk-, sk_live_, or service_role.
3. Make sure secret keys are only read in server code, never in code that runs in the browser.

One detail from Replit's docs: Secrets aren't available to Static Deployments, because a static site has no server to keep them on. If your app needs a secret key, it needs a deployment type with a server.

Prompt for Replit Agent:

Find every API key, token, or password written directly in the code. Move each one into Replit Secrets and read it from an environment variable on the server only. Make sure no secret is sent to the browser.

2. Production secrets and URLs match your live app

Published apps run with their own settings. Replit's troubleshooting guide lists missing production secrets, login callback URLs, and payment webhook URLs among the common reasons a published app breaks.

• Open Publishing, then Adjust settings, and check the production app secrets.
• Check that login and payment settings point to your .replit.app address or custom domain, not the replit.dev development URL.

This is a security check as much as a "does it work" check. A login redirect that points somewhere unexpected is a problem.

3. Run Replit's own security scans

Replit has a Security Center in the Tools pane. According to Replit's docs:

• It runs a security scan before publishing. A setting called Block publishing of critical vulnerabilities decides whether a critical finding stops the publish. I'd turn it on.
• Automatic dependency scans check your packages against public vulnerability records. These are free and run on their own.
• Paid plans can run deeper Agent security scans that review your app's code.

Open Security Center, run a scan, and fix every critical and high finding before you share the link. If you think one is a false alarm, ask Agent to explain it before you dismiss it.

4. Every endpoint checks who's calling

This is the one scanners have the hardest time catching, because the code looks fine. It just doesn't check who's asking.

Your app's buttons call endpoints on your server. Anyone can call those endpoints directly, without your buttons. If an endpoint returns a user's data based on an ID in the request, without checking that the signed-in person owns it, anyone can read anyone's data by changing the number.

For each endpoint, ask: what does a logged-out stranger get? What does a signed-in stranger get if they change the ID?

Prompt for Replit Agent:

Go through every API endpoint. Each one that reads or changes user data must check the signed-in user on the server and only return that user's own data. Don't trust user ids sent from the browser. Add rate limiting to endpoints that call paid APIs or send email.

5. User data goes in the database, not files

Replit's docs say a published app's file system resets every time you publish. That's mostly a reliability issue: anything saved to a file disappears. It can be a security one too: if that folder is also served as part of your site, anyone with the right link can open the files.

Your published app also gets its own production database, separate from the one you build with. Check that real user data only goes there.

6. Security headers and HTTPS

Your .replit.app address comes with HTTPS. Security headers are a different matter. They're small instructions your site sends the browser, like "don't let other sites frame me," and most apps don't send them unless asked.

Prompt for Replit Agent:

Add these response headers to every page: Content-Security-Policy (with frame-ancestors 'none'), Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy. Make sure the app still loads correctly afterward.

7. Try it as a stranger

Before you post the link:

1. Open your published app in a private window.
2. Sign up as a second person and try to see the first account's data.
3. Log out and try to open pages that should need a login.
4. Text the link to yourself and check the preview shows a real title and image.

The short version

• Every key in Secrets, read only on the server.
• Production secrets and callback URLs point at your published domain.
• Security Center scan run, critical and high findings fixed, publish blocking on.
• Every endpoint checks the signed-in user.
• Headers set, and a second account can't see the first one's data.

Replit's scans look at your code and packages. The free Throttle Bird scan is a second, outside look at the published site: what a visitor's browser receives, your headers, HTTPS, link previews, and, if your app uses Supabase or Firebase and you prove you own it, whether a stranger can read your data. Use both. There's also a Replit-specific checklist with more prompts.

Sources: Replit: Project Security Center, Replit: Secrets, Replit: Troubleshoot publishing, Replit: Development and production databases.