A security check before you launch an AI-built app

The short answer

An app built with an AI coding tool can look finished and still let one user read another user’s data. You will not see it in a demo, because a demo is one person using the app the way it was meant to be used.

So before real users sign up, pay for a scoped security review: a developer who fixes AI-built apps checks six specific areas and hands you a written list of what was checked, what was found and what was not checked. Then decide on fixes. The review is the small order; the fixes are the second one. Both fit the AI-built app brief, which already has a “Sensitive parts” field for exactly this.

Why AI-built apps need a check of their own

AI coding tools are good at the part you can see: screens, flows, buttons that do things. Security is mostly the part you cannot see. It lives in rules like “this record belongs to this user”, “this key never reaches the browser” and “this payment is only confirmed when the payment provider says so”.

Those rules are easy to get almost right. The tool writes a page that shows your orders, and it works when you test it. Whether the server also refuses to show someone else’s orders when the address bar is changed is a separate question, and nobody asked it.

There is a second reason. When you keep asking the tool to change things, earlier fixes can be quietly undone. Why an AI-built app breaks after every change covers that pattern; for security it means a check done in month one does not cover what was changed in month two.

The six places an AI-built app usually leaks

These are the areas a reviewer should name in their reply. If a quote does not mention most of them, it is a quote for something else.

1. Logins and password reset. Can someone sign in without the right password, reuse a reset link, or stay signed in after logging out?

2. Access between users. The most common gap. Log in as user A, open one of your records, change the number in the address, and see if user B’s record appears. It should not, and the server, not only the screen, should refuse it.

3. Keys and secrets. API keys for the AI provider, payments and email should live in the hosting settings, not in the code and never in anything the browser downloads. The API keys explainer covers why whoever holds the key holds the bill.

4. Payments. A payment should count as paid only when the payment provider confirms it to your server, not when the checkout page says “thank you”. Ask what happens if the same confirmation arrives twice.

5. File uploads. What can be uploaded, how large, and who can open an uploaded file by guessing its address.

6. Admin pages and error messages. Hidden admin screens that are only hidden, not protected. Error messages that print internal details to the visitor.

Six places to check before launch

A demo shows one user using the app as intended. A review checks what happens around that path.

Who gets in, and what they can see

Logins and password reset→Access between users→Admin pages

What the app trusts, and what it reveals

Keys and secrets→Payment confirmation→File uploads→Error messages

What you get back

Checked→Found, with steps→Not checked, in writing ✓

Who to hire, and what to order first

Look for a developer who fixes vibe-coded or AI-built apps specifically and names security in the gig. On the AI-built app job page, two examples: Corpsoft names security and maintenance explicitly and focuses on making an AI-built MVP production-ready once real users arrive, and Amish Sohail offers a lower-cost first review of a vibe-coded site, with security mentioned in the gig, so you can decide on bigger fixes afterwards.

Order in two steps:

1. A paid review with a written findings list. Small, fixed scope, quick.
2. Fixes, quoted against that list. Now both of you are pricing the same thing.

Skipping step 1 is how a “fix everything” order grows without an end. What buyers say in reviews of AI coding freelancers shows the range of order sizes; a review sits at the small end.

What to write in the order

Paste this into your first message, adapted to your app:

Security review before launch. The app is [one line: what it does], built with [tool]. Code: [repository link on my account], live branch [name]. Sensitive parts: [logins / payments / personal data / uploads — list which exist]. Please check: logins and password reset, access between two test users, where keys and secrets are stored, payment confirmation, uploads, admin pages, error messages. Deliverable: a written list of what you checked, what you found (with steps to reproduce), how serious each finding is, and what you did not check. No code changes in this order.

The last line matters. A review that changes code while it looks is harder to judge. Keep looking and fixing as two orders.

What I do on my own automations

I run a set of unattended jobs in my content pipeline that publish and write drafts. They are not customer-facing apps, but the same habits apply, and they are cheap to copy. I have never had an outside security review of them; everything below is a check I set up and run myself.

• Least permission by default. The AI job that writes drafts overnight is allowed to edit files and search the web, and it has no shell. The second job that checks those drafts can only read. Neither can publish anything by itself.
• Nothing ships if a check fails. My publishing job runs a build and an audit first. If either fails, it reverts the change and pushes nothing.
• Logins are checked before they are needed. The publishing job checks its code-hosting login on every run, even when nothing is due, so an expired token shows up days before a publish, not on the day. I added that after a token stopped working and two days of posts went out empty while everything reported success.
• HTTPS everywhere. When I set up this site I turned on HTTPS-only and a header that tells browsers to keep using HTTPS.

None of this is advanced. It is the kind of thing a reviewer should ask your app about, and the kind of answer you should get back in plain words.

Where it goes wrong anyway

• The review happens, then the app keeps changing. A check covers the code on the day it was done. Tie the next review to your next big change (new payment flow, new user roles), not to the calendar.
• Keys were in the code before the fix. Moving a key out of the code does not un-publish it. If a key was ever in the repository or the browser, ask for it to be replaced with a new one, not just moved.
• Everything is on the developer’s accounts. Then the review is of an app you do not control. Hosting, database and keys belong on yours; the handover checklist for a fixed AI-built app covers the rest of that hand-back.

Wrap-up

Before real users arrive, order a scoped review, not a vague “make it secure”. Name the six areas, ask for a written findings list with a “not checked” section, and keep fixes as a second order. Then keep two test users, repeat the one check you can do yourself after every change, and book the next review when the app changes shape.