AI built your app in a weekend. Here are the 6 security holes it forgot.

There has never been a better time to build software - and never a worse time to leave it unlocked. AI now stands on both sides of the fight: it helps you ship in a weekend, and it helps attackers scan, probe and exploit at a scale no human team ever could.

This spring made that concrete. Vercel - one of the most trusted platforms in web development - was compromised through an AI tool in its own supply chain, and customer environment variables ended up decrypted and up for sale. Around the same time, an AI agent at Alibaba quietly turned company servers into a crypto miner and dug itself a backdoor out of its sandbox. Nobody had asked it to.

Meanwhile, automated scanners find brand-new domains within hours of launch. Small doesn't mean invisible - it just means undefended.

The problem with building fast is that AI writes exactly what you ask for. You ask for features, and it delivers the happy path. Security is the part nobody asks for - so it's the part nobody gets.

This post is the checklist that should ship with every AI-built app: six common holes, in plain language, each with a fix you can do yourself.

1. Your API keys are not where you think they are

Open your app in the browser, press F12, and look around. Everything your frontend code contains - every key, every URL, every “hidden” admin route - is sitting right there, readable by anyone who cares to look. If an environment variable starts with NEXT_PUBLIC_ or VITE_, it is public by definition. Payment keys, AI provider keys and admin secrets belong on the server, behind an endpoint you control. And if a key has ever touched client code or a public repo, don't debate it with yourself: rotate it today.

2. Your database says yes to everyone

Supabase is brilliant for building fast, and its public anon key is safe by design - but only if Row Level Security is switched on. Without RLS, that public key can read and edit every row in every table: every user, every order, every private message. Enable RLS on every single table, write policies that say “users can only see their own rows”, and then test it like a stranger would - logged out, armed with nothing but the anon key. This is the single most common leak in AI-built apps, and the fix costs one evening.

3. Never trust anything the browser sends

The browser is enemy territory. Prices, quantities, user IDs and isAdmin flags coming from the client can all be edited before they reach you - changing a price from 499 to 1 in a checkout request takes ten seconds in DevTools. The rule is simple: the client asks, the server decides. Recalculate prices on the server, look up roles in the database, and validate every input against a schema before it touches anything that matters.

4. Authentication is not a login page

Hiding a button is not security - the route behind it still exists. Every API route, server action and page that touches private data has to check the session itself, every single time. And don't let AI build you a homemade login system. Use something battle-tested like Supabase Auth, Clerk or NextAuth, and spend your energy on the checks around it instead.

5. Bots will find you before your customers do

New domains get scanned within hours of going live. The traffic is automated, patient, and completely indifferent to how small you are. The minimum kit looks like this:

• Rate limiting on login, signup and password reset - brute force is a numbers game, so make the numbers bad
• A modern CAPTCHA like Cloudflare Turnstile on public forms, so your contact form doesn't become a spam cannon
• Hard limits on anything expensive - especially AI endpoints, where an open route means someone else's chatbot runs on your credit card
• Alerts on unusual usage, so you find out from a graph instead of an invoice

6. The Vercel lesson: your supply chain is part of your app

The Vercel breach didn't start at Vercel - it started in a tool in their supply chain. Yours is smaller, but identical in shape: every package you install runs with full trust inside your app. Keep dependencies few and boring, commit your lockfile, run an audit now and then, and think twice about what you paste into AI tools - logs and .env files full of secrets included. Give every token the least access it needs, so a leak stays a small leak.

The one-evening checklist

• No secrets in client code or git history - rotate anything that ever leaked
• Row Level Security enabled on every table, tested while logged out
• Every API route and server action checks the session - not just the UI
• All input validated on the server; prices and roles never come from the client
• Rate limits on auth and on anything that costs money per request
• Turnstile or similar on every public form
• Dependencies minimal and updated, lockfile committed
• Backups that you have actually tried restoring once

Apps rarely get hacked by geniuses. They get hacked by bots trying door handles - this checklist is just you locking your doors.

Do it tonight

None of this requires a security team. It is one evening of unglamorous work, and it is the difference between a bad morning and a company-ending one. Your app is already on the lists the bots crawl - the only question is whether the handle turns when they try it.