How not to leak API keys in Vibe Coding

Why this happens more often in Vibe Coding

During rapid prototyping, it's easy to ask the AI to "just connect the API" and immediately paste the key into the code. The problem is that everything that goes into the frontend can be seen in downloaded files or network requests. And a secret, once saved in Git, can remain in the history even after being deleted from the latest version of the file.

Secure Project Structure

Keep real values in a file .env, which is not committed to the repository. For the team, leave only a template .env.example with variable names and no secrets.

# .env — локально, не комітимо
OPENAI_API_KEY=справжній_ключ

# .env.example — можна комітити
OPENAI_API_KEY=

# .gitignore
.env
.env.*
!.env.example

On hosting, the key should be added via the Secrets or Environment Variables section. Do not paste it into HTML, client-side JavaScript, public configuration files, or variables with a prefix that the platform embeds into the browser code.

If the application uses Supabase, the client publishable/anon key is not a substitute for authorization: access to rows is restricted by database policies. There is a separate step-by-step guide for this — how to set up Supabase RLS and test it with two users.

How to formulate a task for AI

Instead of passing the real key, give the assistant the variable name and describe the boundary between the client and the server:

Enable GitHub Protection

GitHub Secret Scanning looks for keys, tokens, and passwords throughout the entire repository history. Push protection works even earlier: it can stop a commit from being sent if a secret is found. For personal accounts, user protection from leaks to public repositories is enabled by default, but warnings should not be bypassed without checking.

Before your first public push, search your project for API_KEY, SECRET, TOKEN, PASSWORD and fragments of your services' key formats.

If a key has already been exposed

1. Immediately revoke the key in the service dashboard. Deleting the line from the file is not enough.
2. Create a new key with minimal necessary permissions and, if possible, an expiration date.
3. Replace the values in the environment variables on the server and verify that the application works.
4. Review usage, billing, and request logs for unusual activity.
5. Only after revocation should you decide whether you need to clean the Git history. Still, consider the old key compromised.

What not to paste into an AI chat

• API keys, passwords, access tokens, and private keys;
• full backups of production databases containing user data;
• production configurations if they contain addresses, secrets, or service credentials;
• other people's personal, medical, payment, or internal corporate data without permission and proper protection.

Pre-publication Checklist

• There are no real keys, passwords, or tokens in the code or Git history.
• .env and local configurations are added to .gitignore.
• .env.example contains only variable names and safe examples.
• Secret API requests are performed on the server, not in the browser.
• Keys have only the necessary permissions, limits, and expiration dates where available.
• GitHub secret scanning or push protection warnings have not been ignored.
• Error logs have been checked: they do not print secrets or private data.
• Separate test keys and dummy data were used for testing.
• Spending limits or unusual usage alerts are configured.
• You know where to quickly revoke each key in case of an incident.