Does Replit Secrets keep keys out of the website?

Secrets are environment variables for the app. They stay private when server code reads them and never writes them into HTML or JavaScript. A public Repl can still show a key that was typed into a file.

The app is on a .replit.app domain. Can I scan that?

Yes, if the URL is public. Paste the published address. The check does not need a Replit account, and it does not look inside the editor.

Will this check use my database password if it finds one?

No. If a database URL with a password is in the page or a script, the report says so and does not save the password. It does not connect to the database with that secret.

What should I paste into Agent?

Paste the fix prompt on this page, republish, and run the check again. Rotate any key or database password that was already public. Agent cannot revoke those at the vendor.

Does a passing check mean the Replit app is safe?

It means this public look did not see the issues it knows how to find. Server bugs, a private admin route, and a public Repl full of old keys can still be a problem.

Guides

Is my Replit app secure?

Replit Agent will scaffold a server, a database, and a publish button. The published app is a normal website, and the usual leaks are normal website leaks: a secret written into the HTML, or a file that should have stayed in the editor.

Free check

Check the live app

Paste the public Replit URL. The check reads what a visitor's browser can already see, then gives you a private report with a fix prompt for each issue.

What Replit actually ships

Replit does not document one framework for Agent apps. A project might be Node, Python, or something else, published to a .replit.app address or a custom domain. Secrets belong in Replit's Secrets tool, which exposes them as environment variables to the running app. Replit's database connection is commonly a DATABASE_URL with a password in it. Treat the published URL as the thing strangers see, and treat a public Repl as source code strangers can read.

Mistakes worth checking

These are the ones that show up in apps built with Replit. Each step is something you can do in the browser or in the product dashboard.

Critical
A secret printed into the HTML or the client bundle
Replit Secrets stay on the server only while your code keeps them there. Agent code sometimes logs the whole environment, or returns a key from an API route, while debugging a connection. Once that string is in a response the browser receives, it is public.
Check it yourself
Open the published app. View source and search for sk-, sk_live, and the names of your secrets. In the network panel, open the main document and any script from your domain and search again.
Critical
DATABASE_URL in the browser
Replit's database secret is a connection string. It includes a username and a password. The browser must never receive it. With that string, someone talks to the database directly and skips the app.
Check it yourself
Search the published page and scripts for DATABASE_URL, postgres://, and mysql://. A match that includes a password is a leaked credential. Rotate the database password after you remove it.
High
A public Repl shares the files
If the Repl is public, people can read the files, including a key that was pasted into source and later deleted from the latest version while it remains in history. The free check looks at the published URL. It does not crawl the editor.
Check it yourself
If the project is public, assume the files are public. Move every secret into the Secrets tool, take the keys out of the files, and rotate anything that was committed.
Critical
A static publish that includes .env or .git
Some Replit apps are static sites. Copying the project folder to the web root can publish .env, .env.local, or the .git directory next to index.html.
Check it yourself
On the published domain, open /.env, /.env.local, /.git/HEAD, and /.git/config. Each one should be a not-found page. A readable Git config means the history may be downloadable, so rotate secrets that ever lived in the repo.
High
Supabase or Firebase added in chat, with default locks
If the agent connected Supabase, the anon key in the page is normal and row-level security still has to be on. If it connected Firebase, test-mode rules are open on purpose and are a problem once real people use the app. The service role key does not belong in client code in either case.
Check it yourself
Search the published page for supabase.co and for a Firebase config. Then open that product's dashboard and confirm a signed-out visitor cannot read private tables or collections.

A prompt you can paste

Paste this into Replit, publish again, and run the check a second time. If a key was already on the live site, rotate it in the vendor dashboard. The prompt cannot do that part.

Review this Replit app before it is shared. Fix the leaks a visitor can already see.

1. Remove every secret from client code, HTML, and public responses. That includes API keys (sk-, sk_live, rk_), a Supabase service_role key, a PEM private key, and any database URL that contains a password. Read those values only from Replit Secrets on the server.
2. Never return process.env, DATABASE_URL, or a secret from an API route or a template. Log only the fact that a variable was missing, not its value.
3. If the app uses Supabase, enable row-level security on every public table and keep the service role key on the server. If it uses Firebase, replace test-mode rules so reads and writes require auth.
4. Make sure the published site does not serve /.env, /.git/HEAD, or /.git/config. If it does, remove those files from the deploy and rotate the secrets.
5. Tell me which values were exposed so I can rotate them. Do not print the secret values in your reply.

Do not disable a security check to make the app start.

What the check looks at

The public page and the JavaScript it loads, for common leaked secret keys: a Supabase service role key, OpenAI, Anthropic, Stripe secret keys, AWS, GitHub, Slack, private keys, and database URLs that include a password. A Supabase anon key is called out as expected in the browser.
A short list of public paths: /.env, /.env.local, /.env.production, /.git/config, /.git/HEAD, and /.npmrc.
A source map, only when a script on the page already points at one, and only when that map includes original source.
Supabase tables, only when the page already includes a supabase.co address and the public anon key. It asks for one row per table, then drops that row.
Firebase Realtime Database and Firestore, only when the public config is already in the page. It uses that public config and does not sign in.
A few browser safety headers on the main response. Missing headers are noted when two or more of the watched ones are absent. They are less urgent than a leaked key.

What stays outside it

It reads. It does not log in, submit forms, or change data.
It does not guess passwords, fuzz inputs, or hunt through hidden paths.
It does not use any secret it finds, including a service role key.
It does not open your builder's dashboard. A rule that lives only there can stay invisible.
A clear result describes this public look. It is not a certificate that the whole app is safe.
The check uses the published URL. It does not open the Replit editor, a private Repl, or the Secrets pane.

Questions

Free check

Run it on the published URL

Use the address a customer would type. The report stays private, and the shareable scorecard hides the details.

Other builders

Vibe-coded app security checklist · All guides