Web application security audit for AI-built apps

A web application security audit is a review of how your app is built, to find the ways someone could read data they should not, spend your money or take over accounts, ranked by risk and then fixed. I’m Mo Tawfik Khalifa, chief product officer and forward deployed engineer at Instruxi. I review and harden apps built with AI, the way I check my own builds before launch, then fix what I find and check it again.

AI writes code that works and rarely checks who else can use it. In July 2025, Veracode tested more than 100 AI models on 80 coding tasks, and when a task could be written safely or unsafely, the models chose the unsafe way 45% of the time (Veracode, 30 July 2025). In a 2025 scan of 1,645 apps from one AI app builder’s public showcase, 170 had database tables anyone could read or write, because Row Level Security was missing or wrong (Matt Palmer’s statement; the builder disputes the CVE).

Worried someone else can see your users’ data?

These are the worries founders with AI-built apps write down, in their own words, and what I do about each one.

[
  { "id": 1043, "name": "Tom Reid", "address": "9 Mill Lane, Bristol" },
  { "id": 1042, "name": "Sarah Hughes", "address": "14 Elm Road, London" }
]

What is a web application security audit?

It is a structured review of a web app’s code, configuration and data rules against a known standard, by someone with access to all three. You get a list of findings ranked by risk, and a way to close each one. For an AI-built app it looks hardest at the places a demo never tests: who else can read the data, where the keys ended up, and what the AI agents are allowed to do.

I work from two free references published by OWASP, a vendor-neutral non-profit:

• OWASP Top 10:2025, the ten risk categories that cause most web app breaches. Broken access control is number one, software supply chain failures number three, and security logging and alerting failures number nine.
• OWASP ASVS, the Application Security Verification Standard. Version 5.0.0 (released May 2025) sets out testable requirements in 17 chapters and three levels. ASVS describes Level 2 as the level “most applications should be striving to achieve.”

Every finding I write up maps to an ASVS chapter, so your team, a future tester or an enterprise customer’s security questionnaire can follow it.

What gets checked?

Eight areas, in the order the risk usually sits in an app built with Lovable, Bolt, Replit, v0, Cursor, Claude Code, Codex or Gemini CLI on top of Supabase, Firebase, Vercel and Stripe:

1. Data rules and RLS. Row Level Security on every table, no using (true) on private data, views that respect it, roles read from data users cannot edit. Checked by signing out and calling the API with only the public key. The SQL is in my Supabase security checklist.
2. Exposed keys. Secret keys in the browser bundle, the git history or a public repo. Anything found gets rotated first, then cleaned up.
3. Sign-in and sessions. Where the staff or admin check runs, password reset, one-time codes, email confirmation and session expiry.
4. Storage buckets. Private by default, a folder per user, a policy per folder, file types checked on the server.
5. Webhooks and payments. The signature checked on the raw body, each event handled once, and orders marked paid by the webhook, never by the thank-you page.
6. Rate limits. Login, sign-up, reset, anything that sends email or texts or calls a paid AI API, plus spend caps in each provider.
7. AI agent and MCP permissions. What each agent and MCP server can reach, scoped tokens, pinned versions, and a person approving deletes, sends and payments. That includes the coding agent that built the app, which has a shell and your keys. See my MCP security checklist and how to stop an agent deleting your database.
8. Logging. Sign-ins, failed sign-ins, permission errors and admin actions recorded, no passwords or tokens in the logs, and an alert when errors spike.

Dependencies, error messages, CORS and backups come along too. The full list is my vibe coding security checklist, 13 checks a founder can run alone.

Answer eight questions about your app on the sheet below and the register ranks what an audit would look at first. With the defaults, an AI-built app that talks to Supabase from the browser, with staff roles and payments, the data rules and the keys come first.

What do you receive?

1. Findings ranked by risk. Each one says where it is, how I confirmed it, what it would let someone do, its likelihood and impact, and the ASVS requirement it maps to. Plain English first, the technical detail under it.
2. Fixes applied, or a fix plan. I can fix in your repository with a test for each finding, or hand your team the plan in order of risk, with the code or SQL for each step.
3. A retest. Every finding checked again the same way it was found, and marked closed or still open, in writing.

You also get a short note on keeping it closed: the checks to run before each release, automatic dependency updates, and limits on the coding agent so the next prompt does not reopen the hole.

Do you need a penetration test or a security audit first?

They answer different questions, and most teams with an AI-built app need the audit first.

• Security audit. A review from the inside, with access to the code, the configuration and the database rules, against a standard, then fixed and retested. Best before launch, after a fast AI build, and before you pay for a pentest.
• Penetration test. An authorised attack on the running app by a tester working like an outsider, within agreed rules, who reports what they got through. ASVS notes that traditional penetration testing reports issues “by exception,” listing only failures. Best before a big launch, for an enterprise customer’s security review, and for compliance.
• Code review. Reading changes for bugs and quality, usually pull request by pull request. Security is one part of it, and it rarely covers the database rules or the hosting settings.

The order that saves money: fix the build first, then commission the pentest, so the tester spends their days on the hard problems and not on an open table.

How long does a security audit take?

1. Access and scope. Read-only access to the repository, the hosting and the database project, and a list of the flows that matter.
2. First pass on the high-risk areas, in the order the register above gives.
3. Findings written up and ranked, and talked through with you.
4. Fixes, by me or by your team.
5. Retest, then the note on keeping it closed.

The self-check in my vibe coding security checklist takes an afternoon for a small app. A full review with fixes and a retest takes longer, and the number of user roles, payment paths and AI agents sets how much. I give you a date after the first call.

What have I published on app security?

Most of my work at Instruxi is under NDA, so I can’t name the clients, and their findings stay private too: I never discuss one client’s vulnerabilities with anyone else. What I can show is the method, published in full.

I also lead product for GVNR at Instruxi, a free and source-available guard that decides allow, deny or ask a person before an AI agent acts, and keeps a hash-chained record of every decision. It works with Claude Code, Cursor, Codex, Gemini CLI and any MCP client. And I built Laqtaa alone with AI: about 100 guests used it on the day and nothing broke.

If the review shows the app needs rebuilding rather than patching, that is MVP development. If the bigger question is where AI belongs in your business, see AI consultant who ships.

How much does a web application security audit cost?

Security reviews and penetration tests are priced by the day or as a fixed scope. The size of the app, the number of user roles, the payment paths and whether fixes are included set the price.

I price each review after a first call, from the size of the app and whether I fix or hand over a plan.

Questions people ask

What is a web application security audit?

A review of how a web app is built, from the inside, against a known standard such as the OWASP Top 10 and OWASP ASVS. It finds the ways someone could read data they should not, spend your money or take over accounts, ranks each finding by risk, and ends with fixes and a retest.

Is a security audit the same as a penetration test?

No. An audit reviews the code, configuration and data rules with full access, and fixes what it finds. A penetration test is an authorised attack on the running app by an accredited tester, who reports what they got through. Many teams need both, the audit first.

How much does a web application security audit cost?

A UK security testing firm’s 2026 guide puts web application penetration tests in the UK at £2,500 for limited scope, rising past £50,000 for enterprise platforms. UK contract ads for penetration testers had a median day rate of £675 in the six months to 17 October 2026, per IT Jobs Watch. That is market data, not my rate. I price each review after a first call.

How long does a security audit take?

The self-check in my vibe coding security checklist takes an afternoon for a small app. A full review with fixes and a retest takes longer, and the number of user roles, payment paths and AI agents sets how much. I give you a date after the first call.

Do you fix what you find?

Yes, if you want me to. I fix in your repository with a test for each finding, or hand your team a fix plan in order of risk. Either way, every finding is retested the same way it was found.

Can you audit a Supabase or Firebase app?

Yes. I have moved apps onto Supabase and fixed database security on live ones. Row Level Security, policies, views, storage and keys are the first things I check, and I have published the checklist with the SQL.

Can I ask the AI to check its own code?

Yes, as a first pass. Then check the results the way an attacker would: sign out and call your API, search the built JavaScript for keys, upload a file you should not be allowed to. The model that wrote the hole is not the best judge of whether it is closed.

1. 30-minute call. Your app, your users, what worries you.
2. A written plan in 48 hours. What to check first, how long it takes, the risks.
3. Start, or not. Use the plan with your team or with me. I reply to every email within one working day.

If you need an app checked and fixed before launch, write to m@tawfik.tv with what it does and what it is built on.