Why the Sites AI Tools Ship Are Fast to Build and Easy to Break

Five years ago, "I built an app this weekend" meant you knew how to code. Today it can mean you described what you wanted to an AI tool, watched it write the code, and clicked deploy. That shift is real and it's good — more people building things is a good outcome. But something quietly got lost in the handoff, and it's worth naming clearly: nobody decided to skip security. It just isn't part of the request unless you make it one.

What "it works" actually means to an AI coding tool

When you ask an AI tool to build a login page, a booking form, or a customer dashboard, it optimizes for the thing you described. Does the form submit? Does the dashboard show the data? Does the page load without an error? Those are testable, visible outcomes, and the tool is very good at hitting them.

What it doesn't do — not because it's broken, but because you didn't ask — is question whether a stranger can reach that dashboard by guessing a URL, whether the login page leaks which emails are already registered, or whether the database behind the booking form is reachable directly from the internet. Those aren't features. They're the absence of a hole, and absence doesn't render on screen. If nobody names the requirement, the model has no reason to invent it.

The default setting on most of these tools is "open"

This is the part that surprises people: it's not that AI-built apps are unusually insecure. It's that the tools underneath them — Supabase, Firebase, most serverless backends — ship with permissive defaults on purpose, because permissive defaults make the first hour of building painless. Row Level Security in Supabase is off until you turn it on. A new API route has no auth check unless you write one. That tradeoff has always existed for developers too. What's changed is who's making the tradeoff, and how many of them don't know it's being made at all.

An unprotected app doesn't throw an error. It works perfectly — for you, and for anyone else who finds it.

The handful of holes that show up everywhere

After enough of these builds, the same short list of problems keeps repeating, almost regardless of what the app does:

• A database that's public by default. The address is guessable or embedded in the app itself, and nothing stops a direct request to it.
• Secret keys shipped to the browser. Anything bundled into client-side code is visible to anyone who opens the developer tools, no hacking required.
• Routes with no lock on them. An admin page or an API endpoint that assumes nobody will type the URL directly.
• One number in a link exposing someone else's data. Change ?id=104 to ?id=105 and see a different customer's order.
• No rate limits. A login form, a contact form, or a password reset that will happily process ten thousand requests a minute.
• Error messages that say too much. A stack trace or a database error handed straight to the visitor's screen.

None of these are exotic. None of them require a "hacker" in the dramatic sense. Most get found by automated scanners that sweep the internet continuously, checking every new domain for exactly this list, not because anyone is targeting you specifically.

This isn't a knock on the tools

A framing contractor who frames a house in three days isn't doing anything wrong by not also being the electrician. The house needs both jobs done, and it was always on someone to make sure both got scheduled. AI coding tools compress the framing job down to hours. They were never positioned as also doing the inspection, and treating "the AI didn't stop me" as a safety net was never a safe assumption — it's just newly obvious now that so many more people are framing houses.

The practical shift is small but real: treat what an AI tool ships you as a fast, solid first draft, not a finished, launch-ready product. The speed is genuinely valuable. The review step just has to exist somewhere, and right now, for most people building this way, it doesn't exist at all.

What changes once you know this

You don't need to become a security engineer to close most of what matters. You need a short, specific list of things to check or ask your AI tool to check, in an order that puts the worst risks first. That's the entire idea behind checking your own site before anyone else finds the gap for you — and it's exactly what the next post on this blog walks through, step by step, for free.