What Is a Secret and Why Does It Matter? (.env Files Explained)
What Is a Secret and Why Does It Matter? (.env Files Explained)
Security First, Day 1 — by Tom Hundley
Let me tell you about a three-person dev team in Mexico.
In February 2026, one developer made a small, easy mistake: he left a Google Gemini API key visible where it shouldn't have been. Automated bots — the kind that scan the internet 24/7 hunting for exactly this — found the key within hours. By the time the team noticed, attackers had used that single key to rack up $82,314 in AI charges in under 48 hours. Their normal monthly spend? About $180.
That story is real. It happened. And it started with a secret sitting in the wrong place.
Here's what you need to know — and it won't take long.
The Lesson
What Is a "Secret"?
In software, a secret is any piece of private information that gives access to something. Think of it like a key to a door. If someone else gets that key, they can walk in as you.
Common secrets you'll run into as a vibe coder:
- API keys — Strings that services like OpenAI, Stripe, or Twilio give you so your app can talk to them. They look like:
sk-proj-abc123xyz789... - Database passwords — The password your app uses to connect to your database
- Private tokens — Access credentials for services like GitHub, Supabase, or SendGrid
Every single one, if exposed, can be used by someone else to impersonate your app — reading user data, sending emails from your account, or billing your credit card.
Why Do Secrets End Up in Code?
AI coding tools are great at writing functional code fast. But "functional" and "secure" aren't the same thing. When you ask Cursor, Bolt, or Replit to build an app that connects to Stripe, the AI will often write the key directly into the code to make it work:
stripe.api_key = "sk_live_AbCdEfGhIjKlMnOp"
That runs fine. But the moment you push that file to GitHub or share it anywhere, that key is compromised.
The Moltbook incident from February 2026 shows how fast this scales up. Moltbook was a social network for AI agents, built entirely through vibe coding — the founder said he "didn't write a single line of code." Security firm Wiz discovered the platform had left 1.5 million API authentication tokens and 35,000 user email addresses completely exposed. Not from sophisticated hacking — from credentials baked into infrastructure that nobody reviewed before launch.
What Is a .env File?
A .env file is a plain text file that lives in your project folder and stores your secrets separately from your code. It looks like this:
OPENAI_API_KEY=sk-proj-abc123xyz789...
STRIPE_SECRET_KEY=sk_live_AbCdEfGhIjKlMnOp
DATABASE_URL=postgresql://user:password@host/dbname
Your code reads these values instead of having them written in directly. Instead of the key being in your code, the code says "go find the value called OPENAI_API_KEY" — and the .env file is where it looks.
The critical rule: the .env file never gets pushed to GitHub. You add it to .gitignore, which tells Git to skip it when saving your project. Your code goes up. Your secrets stay local.
This one habit is the most important security practice you can build right now.
Example Prompts
Copy and paste these directly into your AI coding tool.
Prompt 1 — Setting up a .env file from scratch:
"Create a
.envfile for this project with placeholder values for my OpenAI and Stripe keys. Update the code to read from environment variables instead of hardcoded values. Add.envto.gitignore. Also create a.env.examplefile with fake values that I can safely share."
Prompt 2 — Auditing existing code:
"Scan this entire codebase for any hardcoded API keys, passwords, tokens, or secrets. List every file and line number. Then refactor each one to use environment variables and confirm
.envis in.gitignore."
Prompt 3 — Deploying with secrets (Vercel, Railway, Render):
"I'm about to deploy this app to [your platform]. Walk me through adding my environment variables so the deployed app can access them without the .env file being included. Step-by-step for a non-developer."
What NOT To Do
Don't hardcode keys in your code. Even in a private repo, this is dangerous. Private repos get made public by accident. You share a screenshot in Discord. You paste a code snippet asking for help. There are dozens of ways a hardcoded key escapes.
Don't commit your .env file to GitHub.
Forget to add .env to .gitignore, run git push, and your secrets are live. Even if you delete the file immediately, Git history remembers — and those automated bots scan GitHub continuously. Truffle Security found nearly 3,000 live, exploitable Google API keys embedded in public code in early 2026, many of them years old.
Don't share real keys in Discord, Slack, or screenshots. Help channels are public. DMs get forwarded. Screenshots travel. Never paste a real API key anywhere social.
Don't ignore old or "unused" keys. That Google Maps key you enabled eight months ago may now have access to Gemini endpoints — because the platform quietly expanded what those keys can do. Keys don't become harmless when you stop using them. Audit and delete anything you're not actively using.
Quick Checklist
Do these today, before you write another line of code.
- Audit for hardcoded secrets. Ask your AI: "Do I have any API keys or passwords written directly in my code files?" Fix what it finds.
- Create a .env file. Move every secret into it. One key per line, in
KEY=valueformat. - Add .env to .gitignore right now. Open
.gitignore, add a line that just says.env, save. Takes 10 seconds. - Create a .env.example. Same file structure, but with fake placeholder values. Safe to share, tells teammates what variables the project needs.
- Check existing GitHub repos. Search your public repos for strings like
sk-,api_key=, orpassword=. If you find real keys, rotate them immediately at the source.
Ask The Guild
Post this in the AI Coding Guild community this week:
"I just audited my project and [found hardcoded secrets / I'm not sure how to check]. Can someone walk me through setting up a proper .env workflow for [your tool: Cursor / Bolt / Replit / v0 / Lovable]? Using [your stack: JavaScript / Python] and deploying to [your platform]."
The more specific you are, the better help you'll get. No question is too basic here — this is exactly what the Guild is for.
Tom Hundley is a software architect with 25 years of experience. The Security First series exists because good security habits should be accessible to everyone building with AI tools, not just people who went to school for this.