The 9 security holes we keep finding in AI-built apps (and how to close them before real users arrive)

Pattern. Your payment provider calls a webhook to tell your app "this order completed — upgrade this user." The generated code wires up the endpoint and reads the payload, but the signature check is left as a // TODO or skipped entirely. The webhook believes whatever it is sent.

Why it happens. Signature verification is fiddly, provider-specific, and adds nothing visible to the demo. The happy path works without it, so it gets deferred and forgotten.

What it costs. Anyone who learns the URL can POST a fake "order completed" event and grant themselves — or anyone — a paid plan without paying. The same forged call can cancel a competitor's subscription. And because these handlers usually run with elevated database rights to write across accounts, the forged request bypasses your row-level security entirely.

How to close it. Verify the provider's signature on every webhook before you act on the body, using the signing secret from your provider dashboard. Reject anything that fails. Treat the webhook payload as hostile input, because it is reachable by the whole internet.

Pattern. There is an internal endpoint that sends the newsletter, or a broadcast, to your whole list. It works. It also has no authentication — any POST from anywhere triggers it.

Why it happens. During the build, the only person calling it is the admin, from the admin screen, so it never occurred to anyone that the endpoint itself is publicly reachable. The protection lived in "you have to be on the admin page to click the button" — but the button just calls a URL, and the URL does not care where you came from.

What it costs. A stranger can send any content to your entire confirmed subscriber list, from your sending domain. That is phishing in your brand's name, your email provider's limits and bill blown, and your domain's deliverability reputation burned — which is slow and painful to rebuild.

How to close it. Every endpoint that does something privileged must check that the caller is authorised on the server, independent of the UI. "The button is only on the admin page" is not access control.

Pattern. Your access-control policy lets a logged-in user update their own profile row — sensible enough. But it lets them update any column on that row, including subscription_status or plan. So a user can open the browser console and set their own plan to "enterprise" for free.

Why it happens. The generated row-level-security policy says "a user may update their own record." That is correct for name and avatar. It is a disaster for the billing fields that happen to live on the same record.

What it costs. Straight revenue leak, and an integrity problem — you can no longer trust that "plan = paid" in your database means anyone paid. The users who find this rarely tell you.

How to close it. Billing state must only ever be written server-side, off the back of a verified payment event — never by the user, even on their own row. Either restrict which columns the user-facing policy can touch, or move subscription fields to a table the client cannot write to at all. The principle: the client may describe itself, but it may not declare what it has paid for.

Pattern. Different parts of the app decide "is this person an admin?" in different ways. One route checks profiles.is_admin. Another checks profiles.role. A third checks a separate admin_users table. Some of those columns don't even exist in the migrations — they were added by hand in the dashboard, so the real behaviour depends on database state that isn't in the code at all.

Why it happens. The app was built incrementally by an AI across many sessions, each one inventing its own admin check without reconciling against the last. The schema drifted from the code because someone patched the live database directly to make a screen work.

What it costs. Access control you cannot reason about or audit. Some admin routes may be silently wide open; others may be locked shut; and which is which depends on undocumented manual edits. For anything handling other people's data, "we're not sure how admin is actually enforced" is not a state you can launch in.

How to close it. One definition of "admin," in one place, enforced server-side, and represented in your migrations so the code is the source of truth. Then delete the other two. And reconcile the live schema against the migrations — if the database has columns the code doesn't, you don't actually know what your security depends on.

Pattern. Premium files show a lock icon to free users. But the API that lists them returns the real, downloadable file URL in the response regardless — the lock is purely visual. And the files themselves sit in public storage, so the URL is all anyone needs.

Why it happens. Gating in the UI is easy and looks done. The API was written to return the whole object, lock flag and all, and nobody checked what a free user could see by reading the raw response instead of the rendered page.

What it costs. Your paid content is free to anyone who opens the network tab, or who is handed a link. If selling that content is the business model, the business model is open.

How to close it. Enforce entitlement on the server: a user who isn't entitled gets no file URL in the response, full stop. Put the files behind access-controlled, time-limited (signed) URLs rather than permanently public ones. The rule: never send the client data it isn't allowed to have and rely on the client to hide it.

Pattern. The product is sold as a B2B tool where a company's data is isolated from other companies. Under the hood, every row is tied to an individual user account, and "company" is just a free-text field on the profile. There is no concept of an organisation, no membership, no shared-but-isolated company data.

Why it happens. Generating per-user data isolation is straightforward and the tools do it by default. Real multi-tenancy — organisations, members, roles, data scoped to the org and shared across its users while walled off from other orgs — is architecture, and it doesn't emerge from prompting feature by feature.

What it costs. The core promise — "your company's data is isolated from other companies, and your colleagues share it" — isn't met. You either can't onboard a company with multiple users properly, or you bolt on something fragile under pressure later. This is the most expensive item on the list to retrofit, because it touches the data model everything else sits on.

How to close it. Decide early whether one customer means one user or one organisation with many users. If it's the latter, build the tenant model deliberately — organisations, memberships, and access rules scoped to the org — before real customers arrive. Retrofitting tenancy after you have live data is a migration, not a patch.

Pattern. A contact or enquiry form saves to the database. The save fails — often because the code is writing columns the table doesn't have (see the schema drift in #4) — but the handler catches the error, logs it to the console, and returns "success" to the user anyway. The visitor sees a thank-you message. The enquiry is gone.

Why it happens. Defensive "always return success so the UI doesn't break" error handling, combined with a schema that has drifted from the code so writes quietly fail.

What it costs. Incoming business vanishing with no trace and no error — the worst kind of bug, because nothing alerts you and the customer thinks they reached you. For a company whose pipeline comes through that form, you are losing revenue you will never know you had.

How to close it. Never report success on a failed write. Surface real failures, alert on them, and fix the underlying schema drift so writes succeed in the first place. Reconcile what the code writes against what the database actually has.

Pattern. Row-level security is enabled on the table, which looks reassuring in the dashboard — the toggle is green. But the policy on it is effectively USING (true) or WITH CHECK (true): it permits every row to everyone. So a table that appears protected is, in practice, world-readable or world-writable through the public API key. A common version is an enquiry or leads table with an insert policy of WITH CHECK (true), which lets anyone write arbitrary rows straight through the anonymous key.

Why it happens. Turning RLS on and writing a correct policy are two separate steps, and the tools (or a human under time pressure) often do the first and stub the second with a permissive placeholder to make the feature work, meaning to tighten it later. "RLS: enabled" then reads as "secured" when it isn't. It's worse than no RLS, because it gives false confidence.

What it costs. Whatever the table holds is exposed to anyone with your public key, which ships in the browser — so, effectively, to the internet. Customer records readable, leads tables writable and spammable, data you believed was walled off sitting open. And because the toggle says "on," nobody goes looking.

How to close it. Don't trust the enabled flag — read the actual policies. Every policy needs a real condition that scopes rows to who should see or change them (the owning user, the owning organisation), never a blanket true. Audit each table for what an anonymous caller and a logged-in non-owner can actually do through the public key, and write the negative tests that prove they can't.

Pattern. The app calls an external AI model for its core feature — drafting replies, summarising, classifying. When the provider account hits a spending cap, an expired card, or a rate limit, the API call fails. The code doesn't handle that failure, so the request either throws an unhandled error and 500s, or fails silently and returns nothing — and the user is left with a broken feature and no explanation.

Why it happens. During the build the account has credit and the call always succeeds, so the failure branch never gets exercised or written. Out-of-credit, rate-limited, and provider-outage responses are all error states that don't show up in a happy-path demo, so they're never coded for.

What it costs. Your headline feature dies the moment billing lapses or usage spikes — silently, in front of real users, with no error surfaced and nothing telling you it's happening. A spike in genuine usage can trip the cap and take the feature down exactly when it's most in demand. You find out from a confused customer, not a monitor.

How to close it. Treat every external AI call as something that can fail, and handle it explicitly: catch the error, show the user a clear "this didn't go through, try again shortly" message rather than a crash or silence, and log and alert so you know the moment it starts. Watch the provider balance and rate limits, and where it matters, degrade gracefully — queue the work, or fall back — rather than leaving a dead button.