Short answer: Before launch, test who can read and write each database table using only the public key, make sure no secret key reaches the browser, check permissions on the server for every request, verify payment webhooks, add rate limits, update vulnerable packages, set security headers, prove you can restore a backup, and know what personal information you hold and where. The first three are where the 2025 evidence below points.
Why AI-built apps need a check
Two pieces of evidence from 2025 explain the concern.
A researcher scanned 1,645 apps from one AI app builder's public showcase and found 170 whose database could be read by anyone holding the public key that every visitor's browser receives. It was recorded as CVE-2025-48757: an insufficient row-level security policy that let unauthenticated attackers read or write database tables of generated sites.
Separately, Veracode's 2025 GenAI Code Security Report tested more than 100 language models on 80 coding tasks. Given a choice between a secure and an insecure way to write the code, the models chose the insecure one 45% of the time, and failed to defend against cross-site scripting in 86% of the relevant samples.
Neither finding means AI tools are unusable. They mean the code looks finished before it is safe, and someone has to check the difference.
The ten checks
1. Database access rules, tested with the public key
If your app talks to the database straight from the browser, as Supabase and Firebase apps often do, the key in the browser is public by design. Safety depends entirely on the access rules. Sign in as one user and try to read another user's records. Then try with no sign-in at all. Supabase's own documentation is explicit that tables need row-level security switched on and policies written.
2. No secret keys in the browser
Open the built JavaScript your site serves and search it for service keys, live payment keys and API tokens. Search the git history too: a key deleted from the code is still in the history. Any key that has been exposed should be rotated, not just removed.
3. Permissions checked on the server
Hiding a button is not access control. Every request that reads or changes data should check, on the server, that this user may do this to this record. Broken access control heads the OWASP Top 10, the standard list of web application risks.
4. Payments verified on the server
Prices are calculated on the server, never taken from the browser. Payment notifications and webhooks are verified against the provider's signature or by calling the provider back before an order is marked paid.
5. Input checked, output encoded
Anything a user types is validated on the way in and encoded on the way out, so it cannot run as script in someone else's browser. This is the cross-site scripting gap from the Veracode figures.
6. Rate limits on sign-in and forms
Sign-in, sign-up, password reset and contact forms need limits, or they become a tool for guessing passwords and sending spam in your name.
7. Dependencies without known vulnerabilities
Run your package manager's audit, update what it flags, and keep the lockfile in the repository so the version you tested is the version you deploy.
8. Security headers and HTTPS
HTTPS everywhere, a content security policy, and protection against your pages being framed by another site. These take an hour and close whole categories of attack.
9. Backups you have restored
A backup you have never restored is a hope. Restore one into a test environment before launch, time it, and write down how to roll back a bad release.
10. Personal information you can account for
Know what you collect, why, where it is stored and for how long. Publish a privacy notice that says so. In South Africa, POPIA section 22 requires you to notify the Information Regulator and affected people as soon as reasonably possible after a compromise, so you also need to be able to tell when one happens.
What you can do yourself, and what needs a second pair of eyes
A builder can do checks 2, 7 and 8 in an afternoon with the right instructions. Checks 1, 3 and 4 are where a second engineer earns their fee: they need someone to think like an attacker, try the requests the interface never makes, and read the rules the AI wrote rather than trust them.
Our Launch Check covers all ten in five working days for a fixed R18,500 (US$1,950 or £1,550): ranked findings with the evidence for each, a fix list your builder can follow, one re-test, and a review letter signed by the engineer who did the work and the one who reviewed it.