Security Essentials

Why Security Matters More Than Ever

Here is a statistic that should get your attention: studies have found that nearly half of all AI-generated code contains security vulnerabilities. Not because the AI is malicious -- because security requires intentional, defensive thinking that AI does not always prioritize. AI optimizes for "does it work?" not "is it safe?"

When you write code with Claude Code, the code works. It runs, it does what you asked, and it often looks clean and professional. But "working" and "secure" are two different things. A door with no lock works perfectly fine -- until someone walks through it who should not.

This lesson is the most important one on the trail. The concepts here are not optional best practices you can skip. They are rules. Follow them every time, and your projects will be safe. Skip them once, and you risk exposing your API keys, your data, or your users' information.

The 5 Security Rules

These five rules cover the vast majority of security issues you will encounter as a builder using AI tools. Memorize them. Follow them without exception.

Rule 1: AI-Generated Code Is Untrusted Code

All code needs review before it ships -- AI-generated code is no exception. Professional developers review each other's work, and you should review AI-generated code the same way.

What to do:

• Read the code changes before accepting them
• If you do not understand something, ask Claude Code to explain it
• Pay special attention to code that handles user input, database queries, or authentication

> Review this file for security vulnerabilities:
  src/app/api/users/route.ts

Rule 2: Secrets Are Sacred

API keys, database passwords, tokens, and credentials are secrets. They grant access to services that can cost you money, expose your data, or compromise your users. Treat every secret like your bank password.

The rules for secrets:

• NEVER put a secret directly in a code file
• NEVER commit a secret to Git
• ALWAYS use environment variables (.env files)
• ALWAYS add .env to .gitignore before your first commit
• If you accidentally expose a secret, revoke it immediately and generate a new one

Here is the correct pattern:

# BAD -- secret is directly in the code
# src/lib/supabase.ts
const supabase = createClient(
  'https://abc123.supabase.co',
  'your-supabase-publishable-key-here'
)

# GOOD -- secret comes from environment variable
# src/lib/supabase.ts
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
)

# .env.local (NOT committed to Git)
NEXT_PUBLIC_SUPABASE_URL=https://abc123.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your-supabase-publishable-key-here

# .gitignore (committed to Git)
.env
.env.local
.env*.local

Rule 3: Less Access Is More Safety

The principle of least privilege says: give every tool, user, and service the minimum access it needs to do its job. Nothing more.

In practice:

• If your app only reads from the database, use a read-only database key
• If an MCP server only needs access to one table, do not give it access to all tables
• If a feature does not need admin permissions, do not use admin credentials
• If a user should not see certain data, enforce that at the database level with Row Level Security

-- Instead of allowing everything:
CREATE POLICY "Allow all" ON projects
  FOR ALL USING (true);

-- Be specific about what is allowed:
CREATE POLICY "Users can read their own projects" ON projects
  FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "Users can insert their own projects" ON projects
  FOR INSERT WITH CHECK (auth.uid() = user_id);

Rule 4: Review Every Diff

When Claude Code changes your code, a diff shows you exactly what was added, removed, or modified. Read it. Every time.

# See what changed since your last commit
git diff

# See a summary of changed files
git diff --stat

You are looking for:

• Hardcoded secrets that should be environment variables
• New dependencies you did not ask for
• Changes to files you did not expect to change
• Code that handles user input without validation
• Database queries built with string concatenation (a sign of SQL injection risk)

> Show me a summary of all changes since the last commit
  and flag anything that might be a security concern.

Rule 5: Commit Often, Revert Freely

Git is your safety net. Commit every time something works. If the next change breaks something, you can revert to the working state instantly.

# The safe workflow:
git add .
git commit -m "Working state: projects page loads from database"

# Now make a risky change...
# If it breaks:
git checkout .
# You are back to the working state. No damage done.

The opposite of this -- making many changes without committing -- is dangerous. If you go an hour without committing and something breaks, you have to manually figure out what went wrong across dozens of changes. Commit often, and each revert is surgical.

Where API Keys Should (and Should Not) Live

| Where | Safe? | Details | |---|---|---| | .env.local | Yes | Local development, not committed to Git | | Vercel dashboard | Yes | Production environment, encrypted storage | | Source code files | NO | Will be committed to Git and exposed | | Git history | NO | Even deleted keys persist in history | | Chat messages | NO | Do not paste keys into Claude conversations |

What to Do If You Expose a Key

Even experienced developers accidentally commit a secret. The response must be immediate:

1. Revoke the key immediately in the service's dashboard
2. Generate a new key and update .env.local and your deployment platform
3. Remove it from Git history using git filter-branch or BFG Repo Cleaner
4. Check for unauthorized usage in the service's logs

# Search for common secret patterns in your code
grep -r "sk-" src/ --include="*.ts" --include="*.tsx"
grep -r "eyJ" src/ --include="*.ts" --include="*.tsx"
grep -r "password" src/ --include="*.ts" --include="*.tsx"

cat .gitignore

.env
.env.local
.env*.local
node_modules/

npm audit

# Automatically fix what it can
npm audit fix

# For remaining issues, review them manually
npm audit

# Search recent commits for potential secrets
git log --all --oneline -20
git diff HEAD~5..HEAD

# Make sure .env.local exists and has your secrets
ls -la .env.local

# Make sure .env.local is NOT tracked by Git
git status

The npm audit Command

When you install packages with npm, you are trusting code written by thousands of developers. npm audit checks every package against a database of known vulnerabilities.

Severity levels: Low (fix when convenient), Moderate (fix before deploying), High (fix before deploying -- serious), Critical (fix immediately).

npm audit              # Check for vulnerabilities
npm audit fix          # Auto-fix what it can
npm audit fix --force  # Force major version updates (test afterward!)

The Security Deployment Checklist

Before you deploy anything to the internet, walk through this checklist. Every item should be checked.

Building Security Habits

Security is not a one-time task. It is a set of habits that become automatic with practice. Here are the habits to build:

Before every commit:

git diff          # Review what changed
git status        # Check no secret files are staged

Before every deployment:

npm audit         # Check for vulnerable packages

When installing new packages:

> Before installing this package, are there any known security
  concerns with it? Is it actively maintained?

When Claude Code modifies sensitive files:

> Show me exactly what changed in the API route and confirm
  no secrets are hardcoded.

The Security Mindset

The most important takeaway is not any specific command -- it is the habit of asking: "What happens if someone sees this code on GitHub? What if this key gets exposed? Do I understand what this code does before I ship it?" That security instinct gets stronger with practice.