How to Security Audit Your AI-Generated Code (Before Hackers Do)

The Vibe Coding Security Problem

AI coding tools prioritize functional code over secure code. They'll generate working features without thinking about:

• Who should be allowed to call this endpoint?
• What happens if someone calls it 10,000 times per second?
• Is this API key safe in the browser?
• Can a user access another user's data by changing an ID?

This isn't a flaw — it's how these tools are designed. They optimize for getting you to a working prototype fast. Security is your job.

What a Security Audit Should Cover

A proper audit isn't just "check for SQL injection." You need to systematically examine every layer of your application:

1. Frontend Security

• API keys in client bundle — Check if any secrets are exposed via VITE_ or NEXT_PUBLIC_ environment variables
• XSS vulnerabilities — Look for dangerouslySetInnerHTML or user input rendered without sanitization
• Insecure storage — Find sensitive data in localStorage or URL parameters

2. Backend API Security

• Authentication — Does every write endpoint require auth?
• Authorization — Can users access other users' data?
• Input validation — Are inputs sanitized and validated?
• Rate limiting — What happens with 1000 requests/second?

3. Database Security

• Service role exposure — Is your Supabase service_role key ever in client code?
• RLS policies — Are Row Level Security policies properly configured?
• SQL injection — Any string concatenation in queries?

4. API Abuse Protection

• Rate limiting — Are auth endpoints protected from brute force?
• Account lockout — What happens after 10 failed logins?
• Resource limits — Can users create unlimited records?

How to Run a Security Audit

You can use AI to audit your own AI-generated code — but you need the right approach.

Step 1: Scan for Hardcoded Secrets

Start by searching your codebase for common secret patterns:

grep -rn "sk-\|AIza\|SG\.\|eyJ\|password\|secret" \
  --include="*.ts" --include="*.tsx" --include="*.js" \
  --exclude-dir=node_modules .

Also check your git history — even deleted secrets are compromised:

git log --all -p -S "AIza" | head -100

Step 2: Check Client-Side Exposure

# Find env vars that go to client
grep -rn "VITE_\|NEXT_PUBLIC_" --include="*.ts" . | grep -i "key\|secret"

# Check for service role in client code
grep -rn "service_role\|SERVICE_ROLE" --include="*.ts" ./src

Step 3: Audit Every API Endpoint

For each endpoint in your /api directory, ask:

1. Does it require authentication?
2. Does it verify the user owns the resource?
3. Does it validate all inputs?
4. Does it have rate limiting?

Step 4: Test Rate Limiting

Try hitting your auth endpoints rapidly. If you can make 100 login attempts in 10 seconds without being blocked, you have a brute force vulnerability.

Step 5: Verify Security Headers

curl -I https://yoursite.com | grep -i "x-frame\|strict-transport\|content-security"

Or visit securityheaders.com and aim for an A grade.

Pre-Launch Security Checklist

Before you ship, verify each item:

• ☐ No API keys in client bundle
• ☐ No service_role key in frontend
• ☐ All write endpoints require auth
• ☐ Rate limiting on auth endpoints
• ☐ CORS whitelist configured
• ☐ Security headers present
• ☐ Input validation on all forms
• ☐ No secrets in git history
• ☐ npm audit clean