Last week, I watched a founder lose £47,000 in twelve minutes.
Not exaggerating. Twelve minutes.
His AI app got hacked. Someone found his API key, ran a script, and burned through his entire OpenAI budget before he even woke up. Account suspended. App down. Users gone.
He didn't get hacked by some genius in a hoodie running custom exploits. He got hit by a bot. An automated script. The digital equivalent of someone just... trying the front door. And it opened.
The worst part? This happens every single week. And it's completely preventable.
Here's what nobody tells you about AI coding tools. They're fast. Crazy fast. But they're optimised for speed, not survival. They'll build you something that works. But "works" and "won't get you destroyed at 3am" are two very different things.
Let me break down the three mistakes I keep seeing. Same story, different founder, every time.
Mistake #1: Your API Keys Are Just... Out There
This is what killed that founder I mentioned.
Here's how it works. If your API key is anywhere in your frontend code, anyone can find it. Not "might find it." Will find it. There are bots scanning GitHub 24/7 looking for exactly this. The second they spot your key, they run up your bill to whatever your spending limit is.
No warning. No alert. Just an email from OpenAI that makes your stomach drop.
Most founders don't even realise they've done it. You're building fast, testing things, pushing code. Your AI assistant puts the key where it's convenient. Frontend file. Public repo. Done.
And just like that, you've left £50k sitting on the sidewalk with a sign saying "please take this."
The fix takes 30 seconds. Environment variables. Server-side routes. .gitignore your .env file. Basic stuff. But your AI tool won't do it unless you tell it to.
Mistake #2: No Rate Limiting (AKA The "Why Is My Bill £12,000" Problem)
Without rate limiting, someone can hit your API 10,000 times per second.
Think about that. Ten thousand requests. Per second. Your £50/month API budget becomes £5,000 overnight. I've seen it happen.
I know a founder whose AI image generator got bot-spammed. Not a targeted attack. Just random automated traffic hitting his endpoint over and over. He went to bed with a working app. Woke up to a £12,000 bill from OpenAI.
For an app making him maybe £200/month.
One night. Twelve grand. Gone.
The maths doesn't work, does it? That's because without rate limiting, you're not running a business. You're running a charity for whoever wants to abuse your API.
The fix takes 2 minutes. Set limits per IP. Set limits per user. Return proper error codes when someone hits the limit. Your AI coding tool knows how to do this. It just won't unless you ask.
Mistake #3: No Input Validation (AKA How Someone Bought £10k Worth Of Stuff For Negative £500)
This one's my favourite. And by favourite, I mean it makes me want to scream.
Someone bought £10,000 worth of products on a vibe-coded e-commerce site for negative £500. They just typed "-500" in the price field. That's it. No hacking required. Just... typing a minus sign.
Without input validation, users can send anything to your server. Negative numbers. Malicious code. SQL injection. Literally anything.
Your AI coding assistant is optimised for "does it work when a normal person uses it normally?" It's not thinking about what happens when someone types JavaScript into your search bar. Or submits a form with 50,000 characters. Or sends a request that makes your database do things databases should never do.
The fix takes 2 minutes. Check every input. Validate types. Set limits. Sanitise everything. Stop trusting that users will behave.
The Full Security PRD You Can Copy Right Now
Right. Enough talking about problems. Here's the solution.
Add this entire section to your PRD or project instructions. Whether you're using Cursor, Lovable, Bolt, Replit, whatever. Paste this in. Your AI tool will implement these protections automatically.
This is the difference between "app that works" and "app that won't ruin you."
🔐 SECURITY REQUIREMENTS (Copy This Entire Block)
markdown
## SECURITY REQUIREMENTS
### 1. API Key Protection
- Store ALL API keys in .env files only
- Never expose API keys in frontend/client-side code
- Add .env to .gitignore immediately upon project creation
- Use server-side API routes for ALL external API calls
- Implement key rotation capability for production environments
### 2. Rate Limiting
- Add rate limiting to ALL API endpoints without exception
- Authentication endpoints (login, register, password reset): 5 requests per minute per IP
- Standard API endpoints: 100 requests per minute per user
- Public endpoints: 30 requests per minute per IP
- Implement both IP-based and user-based rate limits
- Return appropriate 429 (Too Many Requests) responses with retry-after headers
- Log all rate limit violations for monitoring
### 3. Input Validation & Sanitization
- Validate and sanitize ALL user inputs on the server side
- Never trust client-side validation alone
- Check and enforce:
- Data types (strings, numbers, booleans)
- Length limits (min/max characters)
- Allowed characters (whitelist approach)
- Number ranges (no negative values where inappropriate)
- Email format validation
- URL format validation
- Implement server-side validation for ALL forms and API endpoints
- Escape all outputs to prevent XSS attacks
- Use parameterized queries to prevent SQL injection
### 4. Authentication & Authorization
- Implement proper session management
- Use secure, httpOnly cookies for session tokens
- Validate user permissions on every protected endpoint
- Implement proper logout that invalidates sessions
- Add CSRF protection to all state-changing operations
### 5. Error Handling
- Never expose stack traces or internal errors to users
- Log detailed errors server-side only
- Return generic error messages to clients
- Implement proper error boundaries
### 6. API Security Headers
- Implement Content-Security-Policy headers
- Add X-Content-Type-Options: nosniff
- Add X-Frame-Options: DENY
- Add X-XSS-Protection: 1; mode=block
- Implement proper CORS policies (restrict to known domains)
```
---
### Quick Implementation Prompts
Don't want to paste the whole thing? Fair. Here's how to add each fix one at a time:
**For API Key Protection:**
```
Review my codebase and move all API keys to environment variables.
Ensure no keys are exposed in frontend code. Create server-side
API routes for any external API calls currently made from the client.
```
**For Rate Limiting:**
```
Add rate limiting to all API endpoints in this project. Use 5 requests
per minute for auth endpoints, 100 requests per minute for standard
endpoints. Implement both IP-based and user-based limits. Return
proper 429 responses.
```
**For Input Validation:**
```
Add comprehensive server-side input validation to all forms and API
endpoints. Validate data types, length limits, allowed characters,
and number ranges. Sanitize all inputs to prevent XSS and SQL injection.Pre-Launch Security Checklist
Before you ship anything. Run through this. Every time.
All API keys are in .env files
.env is in .gitignore
No API keys in frontend code
All external API calls go through server-side routes
Rate limiting on all endpoints
Server-side validation on all inputs
No negative numbers accepted where inappropriate
Error messages don't expose internal details
HTTPS enforced
Security headers implemented
CORS restricted to known domains
Authentication required on protected routes
Spending limits set on all API provider accounts
The Bottom Line
These fixes take 5 minutes total. Maybe less.
But I've watched three founders this month alone get absolutely destroyed because they skipped them. Good apps. Real users. Actual revenue. All gone because of basic stuff that should've been there from day one.
Your AI coding tool is incredible at building fast. It's not thinking about security unless you make it think about security.
Copy that PRD section. Paste it into every project. Let your AI tool handle the implementation.
It's the cheapest insurance policy you'll ever have.
Building AI apps or automations? Reply to this email and let me know what you're working on. I read everything.
Until next time,
Mike