Your AI-built app works great in testing, then someone finds everyone's data through a URL change. I spent the last year understanding security holes in codebases (often AI-generated) for 50+ founders, and the pattern is consistent: initial speed, then preventable disasters that kill momentum right when things start working.
The good news is that most security issues come from the same few patterns. Fix these, and you stop 95% of the attacks that actually happen to early-stage startups. Here's what works in practice.
Make the Database Enforce Its Own Rules #
Row-Level Security means your database automatically prevents users from seeing each other's data. When you query the database, it only returns rows that user is allowed to see. The enforcement happens at the database level, not in your application code.
This matters because AI-generated code often handles permissions inconsistently. One endpoint checks user permissions, another forgets. During a security review last month, I changed a single URL parameter in a founder's dashboard and immediately saw 400 other users' data. The founder had no idea this was possible (two weeks before their investor demo.)
Copy this prompt into Claude or Cursor:
I need to implement Row-Level Security in my Supabase database.
I have these tables: [list your tables]. Each row should only be
accessible to the user who created it. Generate the SQL policies
to enable RLS on all tables and create policies that restrict
access based on auth.uid(). Include policies for SELECT, INSERT,
UPDATE, and DELETE operations.
After Claude generates the policies, test them yourself: log in as one user, try to access another user's ID in the URL. If you can see their data, RLS isn't working. Go back to Claude with the specific failure and ask it to fix the policy. This takes 20 minutes to set up properly and prevents the data leak that ends your company.
Rate Limiting #
Rate limiting caps how many requests a single user can make per hour. Without it, one attacker can generate thousands of fake accounts, fill your database with garbage, burn through your email quota, and rack up API costs while you sleep.
I watched this happen to a founder last quarter. They woke up to a $600 AWS bill from a single night of bot traffic. The app worked fine, but their entire monthly runway disappeared because they didn't have rate limiting configured.
Give this prompt to your coding AI:
Add rate limiting to all my API routes. Limit each IP address to
100 requests per hour. Apply it globally to all api routes.
Return a clear error message when the limit is exceeded. Show me
where to add this and how it will work.
Start strict at 100 requests per hour. Real users never hit this limit. Bots do. You can always increase it later if legitimate users complain, but in 50+ implementations, I've never seen that happen. This also protects you when things go right: your app goes viral, traffic spikes 1000x overnight, and the rate limits keep your costs predictable instead of bankrupting you.
Keep API Keys Out of Your Code #
API keys in your codebase will get stolen. GitHub bots scan for exposed credentials 24/7. When they find your Stripe key or AWS credentials, someone uses them within hours, not days. During security reviews, I find exposed keys in about 40% of AI-generated repositories, usually because Claude or Cursor wrote them directly into the code.
Use this prompt to fix it:
I need to move all my API keys to environment variables. Find
every place in my code where I'm using API keys directly (Stripe,
AWS, database URLs, any third-party services). Show me: 1) how to
create a .env.local file with these keys, 2) how to update my
code to use process.env instead, 3) what to add to .gitignore,
and 4) how to set these as environment variables in Vercel/my
hosting platform.
The actual keys never appear in your repository after this. Set a calendar reminder to rotate all keys every 90 days. Ask Claude: "How to generate new API keys for [service] and show me how to update them in my environment variables without breaking my app."
Three layers catching problems before they reach production. I've seen this reduce critical security issues by 60% across 30 founder projects over the last eight months.
Security breaches kill momentum. These four controls prevent the disasters that actually happen to early-stage startups. They take an afternoon to implement properly and work consistently after that.