Replit API key exposed: secrets leaking from a public Repl

Symptoms

• A surprise bill from OpenAI or another API provider on a key you used in a Repl
• An email from the provider saying your key was leaked or found publicly exposed
• The key sits in plain text in a public Repl's source, an old fork, or version history
• The key is embedded in frontend JavaScript, delivered to every visitor's browser

Why it happens

Repls are public by default

Anyone can read a public Repl's source, and automated scrapers specifically harvest Replit for hardcoded credentials. A key in code is a key on a billboard.

Key values pasted into Agent prompts

If you paste a real key value into a prompt, the Agent generates code with that key hardcoded, and now it lives in your source.

Agent-written frontend calls third-party APIs directly

The Agent often writes browser code that calls APIs like OpenAI straight from the frontend, which ships the key to every visitor's browser where DevTools makes it trivially readable.

History and forks retain old values

Moving a key to the Secrets manager later does not scrub version history or forks. Anyone who forked or scraped the Repl earlier still has the original value.

How to fix it

1. Rotate the compromised key immediatelyTreat any key that was ever hardcoded in a Repl as stolen; automated scrapers specifically harvest Replit for credentials. Go to the issuing provider's dashboard, revoke the key, and issue a new one. Removing the key from your current code is not enough, because version history and existing forks still contain the old value and may already have been copied.
2. Move every credential into Replit's Secrets paneAdd each key by name in the Secrets pane and reference it in code as process.env.KEY_NAME in Node or os.environ['KEY_NAME'] in Python. The value stays out of your source entirely.
3. Keep real key values out of Agent promptsIf you paste a key value into a prompt, the Agent generates code with it hardcoded. Give it the environment variable name instead. A prompt like 'Use the OPENAI_API_KEY environment variable from Secrets via process.env; never hardcode any key values' gets you code that reads the secret correctly.
4. Make the Repl privateIf the Repl contains anything sensitive, change its visibility in Settings so the source is no longer readable by anyone with the URL. This does not undo past exposure, which is why rotation comes first.
5. Move third-party API calls behind your own serverCheck Agent-generated frontend code for direct calls to third-party APIs with embedded keys. Route those calls through a server endpoint you control, so the browser talks to your server and only your server holds the key.
6. Audit the codebase and set a financial backstopSearch your code and shell history for leftover hardcoded values before publishing anything. On the provider side, set spend limits and usage alerts so a future leak cannot run up an unbounded bill.

How to prevent it

• Store every credential in the Secrets pane from the first prompt; never type a real key value into chat or code.
• Keep Repls private by default when they involve credentials, customer data, or billing.
• Route all third-party API calls through your own backend; the browser should never hold a key.
• Set spend limits and alerts with every API provider you use.
• Before making a Repl public or publishing, audit code and shell history for hardcoded values.

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

Frequently asked questions

Sources

• Vibe App Scanner: Replit Exposed API Keys
• Vibe App Scanner: Replit Security
• Replit Blog: 16 Ways to Vibe Code Securely
• Replit Docs: Vibe Code Security Checklist

Related errors