Built your app with AI? The 12-point security check to run before real users arrive

Short answer: an app built with AI tools can work perfectly in a demo and still let any stranger read your customers' data. Before you invite real users, check twelve things: secrets, database access rules, authentication on every endpoint, storage, input handling, dependencies, logging, backups and a few more. If you can't confirm each one with confidence, get an independent code audit before launch, not after an incident.

AI coding tools have changed how fast a first version gets built. A founder in the UAE, Saudi Arabia or Egypt can go from idea to clickable, working product in a weekend with Lovable, Bolt, Replit, Cursor or Claude Code. That is good news. The catch is that "it runs" and "it is safe to put customer data in" are two different tests, and AI tools are very good at passing the first one.

Why do AI-built apps need a separate security pass?

Because AI tools optimise for code that runs, not code that is safe. Veracode found 45% of AI-generated coding tasks introduced a known OWASP Top 10 flaw in 2025, with little change in 2026. 'It works in the demo' and 'it is safe for customer data' are different tests.

Veracode tested code generated by large language models across 80 coding tasks in Java, JavaScript, C# and Python. In its 2025 report, 45% of tasks produced code with a known OWASP Top 10 vulnerability; its 2026 update found almost the same picture, a 56% security pass rate, even as the code got better at simply compiling and running (Veracode 2025 report, Veracode 2026).

Real products have been caught out. In 2025, a researcher scan reported by Semafor found 170 of 1,645 sites built on one popular AI app builder exposing user data, financial details or API keys (Semafor, May 2025). The same year, the Tea app leaked around 72,000 images, including ID photos, from an unsecured storage bucket (Reuters, July 2025). Tea's breach was not shown to be caused by AI-generated code, but it is exactly the class of mistake, a public bucket, that fast builds tend to ship with.

As we argued in our 2027 predictions, code is getting cheap to write and expensive to trust. AI tools optimise for the happy path. Security lives in the unhappy paths: the signed-out user, the second account, the malformed request. Nobody asked the tool to think about those.

What are the 12 checks to run before launch?

Check secrets, database access rules, two-account access tests, server-side authorisation, private file storage, server-side input validation, rate limits, dependencies, error and log hygiene, CORS and debug settings, tested backups, and a map of the personal data you hold. Each check should end in a clear 'yes, and here's how we know'.

Work through these with whoever built the app.

1. No secrets in the front end or the repository

Search the client bundle, the `.env` files and the full git history for API keys, service-role keys, payment keys and database passwords. Anything that was ever committed should be treated as leaked: rotate it, don't just delete the line.

2. Database access rules are on, for every table

If you use Supabase, Firebase or a similar backend-as-a-service, row-level security (or security rules) must be enabled on every table and every collection, with rules tied to the signed-in user's ID. A rule that says "allow if true" is the same as no rule.

3. Test with two accounts and with none

Create user A and user B. Signed in as A, try to read, edit and delete B's records by changing IDs in the URL or the request. Then sign out and try again. This single test catches many of the most common data leaks, and it's the first thing a code audit runs.

4. Every API route checks who is calling

Server functions, edge functions and admin routes must verify authentication and authorisation on the server. Hiding a button in the interface is not access control.

5. File storage is private by default

Uploaded IDs, invoices, medical documents and profile photos belong in private buckets served through short-lived signed links, not public URLs that anyone can guess or share.

6. Inputs are validated on the server

Validate type, length and format on the server for every field, and use parameterised queries. This is where the SQL injection and cross-site scripting issues in the Veracode tests live.

7. Rate limits on log-in, sign-up, OTP and public endpoints

Without them, a script can brute-force passwords, burn through your SMS budget or scrape your data overnight.

8. Dependencies are real, current and few

AI tools sometimes add packages you don't need, outdated versions with known vulnerabilities, or names that don't exist and could be squatted. Run a dependency audit and remove what you don't use.

9. Errors and logs don't leak

Production error pages should not print stack traces, SQL or keys. Logs should not store passwords, full card data or national ID numbers.

10. CORS, headers and debug settings are locked down

Restrict CORS to your own domains, set standard security headers, turn off debug mode, and make sure source maps and `.git` folders are not publicly served.

11. Backups exist and a restore has been tested

A backup you have never restored is a hope, not a backup. Know how far back you can recover and how long it takes.

12. You know what personal data you hold, and where

List the personal data you collect, why, where it is stored and who can access it. In the UAE, the Personal Data Protection Law (Federal Decree-Law 45 of 2021) applies; Egypt's Personal Data Protection Law (Law 151 of 2020) sets similar expectations. A simple data map makes later compliance work far easier. *(This is not legal advice; confirm your obligations with counsel.)*

What does a good result look like?

You don't need a perfect score to launch an MVP. You need no open critical findings, a written list of the risks you accept with an owner and date, and a habit of running the two-account test and a dependency audit before every release. That's enough to put real users on it responsibly.

• No critical findings open: no exposed secrets, no cross-account data access, no public storage of sensitive files.
• Known, written risks: anything you accept for now is listed, with an owner and a date.
• A repeatable habit: the two-account test and a dependency audit run before every release, not once.

When should you bring in an independent review?

Run the checklist yourself first. Bring in an independent review before real customer, payment, health or children's data goes in, when an investor or client asks for a technical review, when nobody can explain how access control works, or when the codebase has passed through several tools or agencies.

• You are about to put real customer, payment, health or children's data into the product.
• An investor, enterprise client or government buyer has asked for a security or technical review.
• The person who built it is no longer around, or nobody on the team can explain how access control works.
• You have changed AI tools or agencies mid-build and the codebase now has several "styles".

How we'd approach this

We'd run the two-account test first, then read the access rules, secrets and dependencies, and give you a short ranked list: fix before launch, fix soon, fine as is. Fritill's Code Audit is built for exactly this moment. It is a fixed-scope review that ends in a scored report on code quality, security and maintainability, the top fixes ranked by impact, and a 30-minute walkthrough call. It comes in three tiers, Feature (20 hours), Product (40 hours) and Platform (80 hours), from one critical flow up to a full platform.

Want a second pair of eyes on yours? See how a Code Audit works, or talk to us on a free 30-minute intro call.

We also run software of our own in production, such as Anvilium, our ERP, so these are the same checks we apply to our own releases.

Your turn: have you shipped something built mostly with AI tools? Which of the 12 checks would it fail first? Email us at hello@fritill.com.

Sources checked 10 November 2026: Veracode GenAI Code Security Reports 2025 and 2026; Semafor (29 May 2025); Reuters (26 Jul 2025); UAE government portal on data protection laws (u.ae).