What Is Secrets Management? Protecting API Keys and Passwords in Your Code

Why AI Coders Need to Know About Secrets

Here's something that happens every single day in the vibe coding world: someone asks Claude or ChatGPT to build an app, gets working code back, pushes it to GitHub, and within minutes their Stripe API key is compromised. Their OpenAI key starts racking up charges. Their database is wide open.

This isn't a hypothetical. GitGuardian's 2024 report found 12.8 million new secrets exposed in public GitHub repositories in a single year. Automated bots scan every public commit, looking for patterns that match API keys, passwords, and tokens. When they find one, it gets exploited — often within minutes.

The reason this hits vibe coders especially hard is that AI coding tools almost always hardcode secrets by default. When you ask Claude to connect your app to a database, it writes the password directly into the code. When you ask it to add Stripe payments, the secret key goes right in the source file. The code works perfectly — and it's also a security disaster waiting to happen.

Secrets management is the system that prevents this. It's not complicated. It's not something you need a security degree for. It's a pattern — a way of organizing your project so that sensitive credentials stay on your machine (or your server) and never, ever end up in your Git history.

Real Scenario: You Asked AI to Add Stripe Payments

You're building a SaaS app with AI. Things are going great — you've got a landing page, user auth, a dashboard. Now you need to accept payments. You give your AI this prompt:

Your AI generates clean, functional code. The checkout flow works. The webhook fires. Users can subscribe. You commit everything, push to GitHub, and deploy. Life is good.

Except buried in that working code are your Stripe secret key, your database password, and your webhook signing secret — all hardcoded as plain text strings. And now they're in your Git history forever.

What AI Generated (And What's Wrong With It)

Here's what AI typically produces when you ask for Stripe integration. This code works — but it contains a critical security flaw that most beginners won't catch:

const express = require('express');
const stripe = require('stripe')('sk_live_abc123def456ghi789jkl012mno345');
const { Pool } = require('pg');

const pool = new Pool({
  host: 'db.myapp.com',
  database: 'myapp_production',
  user: 'admin',
  password: 'MyDatabase$ecret99!',
  port: 5432
});

app.post('/create-checkout', async (req, res) => {
  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    line_items: [{ price: 'price_abc123', quantity: 1 }],
    success_url: 'https://myapp.com/success',
    cancel_url: 'https://myapp.com/cancel',
  });
  res.json({ url: session.url });
});

app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];
  const event = stripe.webhooks.constructEvent(
    req.body, sig, 'whsec_xyz789abc012def345'
  );
  // ... handle event
});

Three secrets are hardcoded directly in this file: the Stripe secret key (sk_live_...), the database password, and the webhook signing secret (whsec_...). If this file gets committed to Git — even a private repository — those credentials are exposed.

Here's what this code should look like with proper secrets management:

require('dotenv').config();  // Load .env file at startup
const express = require('express');
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);
const { Pool } = require('pg');

const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  port: parseInt(process.env.DB_PORT || '5432'),
});

app.post('/create-checkout', async (req, res) => {
  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    line_items: [{ price: process.env.STRIPE_PRICE_ID, quantity: 1 }],
    success_url: `${process.env.APP_URL}/success`,
    cancel_url: `${process.env.APP_URL}/cancel`,
  });
  res.json({ url: session.url });
});

app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];
  const event = stripe.webhooks.constructEvent(
    req.body, sig, process.env.STRIPE_WEBHOOK_SECRET
  );
  // ... handle event
});

# .env — DO NOT COMMIT THIS FILE
STRIPE_SECRET_KEY=sk_live_abc123def456ghi789jkl012mno345
STRIPE_WEBHOOK_SECRET=whsec_xyz789abc012def345
STRIPE_PRICE_ID=price_abc123
DB_HOST=db.myapp.com
DB_NAME=myapp_production
DB_USER=admin
DB_PASSWORD=MyDatabase$ecret99!
DB_PORT=5432
APP_URL=https://myapp.com

# .gitignore
.env
.env.local
.env.production
node_modules/

Install the dotenv package: npm install dotenv. That single line at the top — require('dotenv').config() — reads your .env file and loads every key-value pair into process.env. Your code never sees the actual secret values. They exist only in the .env file on your machine.

Understanding Each Part

Secrets management has a few moving pieces. None of them are complicated on their own — the power is in how they work together.

What Counts as a "Secret"?

A secret is any piece of information that, if someone else got it, could let them access your stuff or pretend to be you. The most common ones:

• API keys — Stripe, OpenAI, Mailgun, Twilio, SendGrid. These are like passwords that let your code talk to other services.
• Database credentials — The username and password your app uses to connect to PostgreSQL, MySQL, or MongoDB.
• JWT secrets — The key used to sign authentication tokens. If someone gets this, they can forge login sessions for any user.
• Webhook signing secrets — Used to verify that incoming webhooks are actually from the service that claims to send them.
• Encryption keys — Keys used to encrypt/decrypt sensitive data like credit card numbers or personal information.
• OAuth client secrets — Used in "Login with Google/GitHub" flows. Lets someone impersonate your app.

The .env File

A .env file is just a plain text file that sits in your project's root directory. Each line is a key-value pair: KEY_NAME=value. No quotes needed (unless the value contains spaces). No export statements. Just simple pairs.

The dotenv package (version 16.4, tested March 2026) reads this file when your app starts and loads every pair into Node.js's process.env object. Your code then accesses values with process.env.KEY_NAME instead of hardcoding strings.

The beauty of this pattern: your code is safe to share, commit, and push to GitHub. The secrets stay in the .env file, which stays on your machine.

The .gitignore File

The .gitignore file tells Git which files to completely ignore — pretend they don't exist. When .env is listed in .gitignore, Git won't track it, won't show it in diffs, and won't include it in commits. It's invisible to version control.

This is the critical link in the chain. Without .gitignore, your .env file gets committed like any other file — and your secrets end up in Git history.

Environment Variables in Production

On your local machine, dotenv loads secrets from your .env file. But when you deploy to production (Vercel, Railway, Render, Heroku, AWS), you set environment variables directly in your hosting platform's dashboard. The variables are injected into your app at runtime — no .env file needed on the server.

This is why process.env.STRIPE_SECRET_KEY works everywhere: locally it comes from your .env file via dotenv, and in production it comes from the platform's environment variable settings.

The .env.example File

One more piece: create a .env.example file that shows the structure of your environment variables without the actual values:

# .env.example — commit this to Git (no real values!)
STRIPE_SECRET_KEY=sk_live_your_key_here
STRIPE_WEBHOOK_SECRET=whsec_your_secret_here
DB_HOST=localhost
DB_NAME=myapp_dev
DB_USER=your_db_user
DB_PASSWORD=your_db_password
DB_PORT=5432
APP_URL=http://localhost:3000

This file does get committed. It tells anyone (or any AI) working on the project exactly which environment variables are needed, without exposing real credentials.

What AI Gets Wrong About Secrets

AI doesn't just make one mistake with secrets — it makes a pattern of related mistakes. Here are the three most common, and each one can compromise your entire project.

# .gitignore
.env
.env.*
!.env.example
node_modules/

// script.js — this runs in the user's browser!
const response = await fetch('https://api.openai.com/v1/chat/completions', {
  headers: {
    'Authorization': 'Bearer sk-abc123def456...',  // ← visible to EVERYONE
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ model: 'gpt-4', messages: [...] })
});

// Frontend: script.js — no secrets here
const response = await fetch('/api/chat', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ message: userMessage })
});

// Backend: server.js — secrets stay server-side
require('dotenv').config();
app.post('/api/chat', async (req, res) => {
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    headers: {
      'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: 'gpt-4',
      messages: [{ role: 'user', content: req.body.message }]
    })
  });
  const data = await response.json();
  res.json(data);
});

I Already Committed a Secret — What Do I Do?

Step 1: Revoke the Secret Immediately

Go to the service's dashboard (Stripe, OpenAI, AWS, whatever) and revoke or rotate the exposed key. Generate a new one. This is the single most important step — it makes the leaked key useless even if someone already copied it.

• Stripe: Dashboard → Developers → API Keys → Roll Key
• OpenAI: Platform → API Keys → Delete the key, create new one
• AWS: IAM → Users → Security Credentials → Deactivate Access Key
• Database: Change the password immediately via your database admin tool

Step 2: Add .env to .gitignore

If your .gitignore is missing or doesn't include .env, add it now:

# Add to .gitignore
.env
.env.*
!.env.example

Step 3: Remove the File from Git Tracking

Even after adding to .gitignore, Git still tracks files it already knows about. Remove it from tracking without deleting the local file:

git rm --cached .env
git commit -m "Remove .env from tracking"
git push

Step 4: Clean Git History (Optional but Recommended)

The secret is still in your Git history. For public repos, use BFG Repo-Cleaner to scrub it:

# Install BFG (requires Java)
brew install bfg

# Remove the .env file from all history
bfg --delete-files .env

# Clean up and force-push
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force

Important: Force-pushing rewrites history. If others have cloned your repo, they'll need to re-clone. For personal projects this is fine. For team projects, coordinate first.

Step 5: Check for Damage

If the secret was exposed publicly:

• Check your Stripe dashboard for unauthorized charges
• Check your OpenAI usage for unexpected API calls
• Check your AWS billing for new resources you didn't create
• Review your database for unauthorized access or data changes
• Enable GitHub Secret Scanning to catch future leaks automatically

Beyond .env: Secret Rotation and Vault Services

The .env + .gitignore pattern handles 90% of what you need as a vibe coder. But as your projects grow — especially if you're deploying to production with real users — there are more robust tools:

Secret Rotation

Secret rotation means regularly changing your API keys and passwords on a schedule. If a key leaks but gets rotated every 90 days, the window of exposure is limited. Most major services (AWS, Google Cloud, Stripe) support automatic key rotation.

Managed Secret Services

• Doppler — Syncs secrets across environments. Great developer experience. Free tier available.
• Vercel Environment Variables — If you deploy on Vercel, their built-in env var system is all you need.
• AWS Secrets Manager — Enterprise-grade. Automatic rotation, audit logging, encryption at rest.
• HashiCorp Vault — The industry standard for secrets management at scale. Overkill for most vibe coders, but worth knowing it exists.

For most AI-enabled coders, start with .env + .gitignore. Move to a managed service when you have multiple environments (dev, staging, production) or a team that needs shared access to secrets.

Secrets Management Checklist

Run through this before every git push:

What to Learn Next

Now that you understand secrets management, these topics build directly on what you've learned:

Frequently Asked Questions