Replit app security checklist: Secrets, Security Center and publishing
Replit gives you a full server, a database and one-click publishing, so secrets can stay server-side and the main risks are hard-coded keys, public remixes and missing authorization. Replit's docs also say plainly that no scan guarantees your app is secure. Here's what to check before you publish.
Scan your live app free Passive, no signup, never touches your database.
1. Keep every key in the Secrets tool, not in code
Replit's Secrets tool encrypts values (AES-256 at rest, per its docs) and exposes them to your code as environment variables. Use Secrets for API keys, tokens and database URLs, and Configurations only for non-sensitive settings such as log levels or public URLs. Replit's docs warn that hard-coded secrets leak through public projects, copy-paste, public repos and screen sharing.
2. Check production app secrets
Your published app has its own secrets: Publishing → Adjust settings → Production app secrets. Make sure production uses production keys and that test keys aren't shipped by mistake. Per Replit's docs, Secrets aren't available to Static Deployments, so a static site can't keep a secret at all; any key it needs is public.
3. Never send secrets to the browser
Code running on Replit's server can read Secrets safely. Code that runs in the visitor's browser (your React or HTML front end) can't. If the front end needs an AI or payment call, route it through a server endpoint that holds the key and checks who is calling.
4. Know who can see secret values
Per Replit's visibility table, Multiplayer collaborators and organization Owners can see secret values; people who remix your project see secret names but not values. Remove collaborators who no longer need access, and rotate keys after someone leaves.
5. Run Security Center scans, and know their limits
In Tools → Security Center: Level 1 (free) checks dependencies only; Level 2 adds an Agent review of your source code (paid plan); Level 3 adds a black-box test of your live Preview. Replit always runs a security scan before publishing, and you can turn on Block publishing of critical vulnerabilities. Replit's docs note that a passing publish check doesn't mean your code has no vulnerabilities.
6. Choose who can access the app
When publishing, Replit lets you choose Public, Password protected, Workspace only or Invite only. Internal tools and prototypes with real data shouldn't be Public.
7. Authorize every API route
Every route that reads or writes user data must check the signed-in user and that the record belongs to them. Test with two accounts: log in as user B and request user A's record IDs. If you use Supabase or Firebase from the browser, follow our RLS and Security Rules checklists too.
8. Scan the published URL
Run Unspill against your .replit.app or custom domain to catch keys in your JavaScript, exposed .env or .git files, public source maps and missing security headers.
Fix guides for these issues
- AI API key exposed: An OpenAI, Anthropic, Groq, OpenRouter or xAI key in your front-end bundle lets anyone run up your bill. Revoke it and proxy AI calls through a server function with rate limits.
- Stripe secret key exposed: A Stripe sk_live_ or sk_test_ key in your JavaScript lets anyone create charges, issue refunds and read your customers. Roll the key in the Stripe Dashboard and move payments server-side.
- Exposed .env file: If https://yourapp.com/.env downloads your environment file, every secret in it is public. Remove it from the deployed output, block dotfiles, and rotate every key.
- Exposed .git directory: A public /.git/config means attackers can often download your full source and commit history, including old secrets. Block /.git and rotate anything ever committed.
- Content-Security-Policy: A Content-Security-Policy limits which scripts can run on your site, reducing the damage of XSS. Copy-paste CSP examples for Vercel, Netlify and Next.js apps using Supabase.
- Verify Supabase Row Level Security: Your Supabase anon key is public by design, so Row Level Security is the only thing protecting your tables. Run these SQL checks to find tables with RLS off or policies that let anyone read everything.
- Verify Firebase Security Rules: Your Firebase web config is public by design, so Firestore, Realtime Database and Storage rules are the only protection for user data. Here's how to check them.
FAQ
Are Replit Secrets visible to people who remix my project?
According to Replit's docs, people remixing a project they don't own or collaborate on can see secret names but not values. Multiplayer collaborators and organization Owners can see values.
Does Replit's security scan make my app secure?
It helps, but Replit's own docs say no scan guarantees an app is secure. Level 1 checks dependencies only; source-code review and live-app testing are higher levels. Combine scans with access-control testing.
Can a Replit Static Deployment use secrets?
No. Replit's docs say Secrets are available for all deployment types except Static Deployments, so anything a static site uses is public.
Sources
- Replit docs: Secrets
- Replit docs: Security scan levels
- Replit docs: Publishing
- Replit docs: Project Security Center
Last checked against these sources on 2026-10-19. Platforms change; when in doubt, the official docs win.