AI-Built App Security Review Checklist

This article is part of our AI-Built Site Rescue hub. Want help applying it? Talk to eSEOspace.

Before real users arrive, an AI-built app needs a review of its database rules, keys, access checks, payments, dependencies and logs. This checklist walks through each one in the order we'd do them.

It is written for owners of apps made with builders and coding assistants. Teams using Claude Code on websites should also read our Claude Code security checklist. This page is part of our AI-Built Site Rescue hub, and was checked against vendor and OWASP documentation on 9 November 2026.

The issue is unreviewed software in production, not AI. Disclosure: eSEOspace builds with AI tools, including Claude Code, and sells services around them.

Key Takeaways

Start with the data, because a table without row-level security can be open to any role with a grant on it.
Anything prefixed for the browser, such as VITE_ or NEXT_PUBLIC_, is public.
OWASP says access control only works in trusted server-side code or serverless APIs.
Builder security scans help, but vendors say they cannot guarantee complete security.
One published benchmark of AI coding agents found security gaps, though it tests tasks and not live businesses.
Only test apps you own or have written permission to test. eSEOspace does not do penetration testing.

Before you start

Write down what the app holds and who should reach it. List each kind of user, such as visitor, customer, staff and admin.

Get permission if the app isn't yours. Only review systems you own or are authorized in writing to test. Don't point any scanner or test at another company's site.

1. Database and data access

This comes first because it's where customer data lives. Supabase is used here as the example. Other databases need the same questions answered.

[ ] Row-level security is on for every table in an exposed schema.
[ ] Each table has policies that match your written list of who can reach what.
[ ] No policy is written so that it always returns true.
[ ] Old default grants are revoked where needed.
[ ] Views don't expose rows that policies would block.
[ ] Storage buckets holding private files are not public.

Supabase's RLS guide says "A table in an exposed schema without RLS is readable and writable by any role with a grant on it."

It also says "On projects that still grant anon and authenticated by default, revoke those grants. Adding policies doesn't remove them." That is the detail short checklists skip.

Run Supabase's Security Advisor in your dashboard and read each warning. It looks for known patterns and doesn't know your business rules. Our row-level security guide explains the terms.

2. Keys and secrets

[ ] No secret key appears in frontend code.
[ ] No secret sits in a VITE_ or NEXT_PUBLIC_ variable.
[ ] No secret is committed to source control, including old commits.
[ ] Any key that was ever exposed has been rotated.

Vite's environment guide is direct. "VITE_* variables should not contain sensitive information such as API keys." Next.js's environment docs say NEXT_PUBLIC_ values are inlined into JavaScript sent to the browser.

Supabase's API keys guide covers secret keys. "Never put one in a browser, a shipped application, or source control." The same page says Supabase is deprecating the anon and service_role keys by the end of 2026. See our legacy key guide.

If a key has leaked, follow what to do in the first hour.

3. Access checks

[ ] A second test user can't open the first user's records.
[ ] A signed-out visitor is refused everywhere that needs a login.
[ ] A non-admin can't open admin pages or call admin actions.
[ ] Create, update and delete actions are checked, not just reading.
[ ] Roles come from data users can't edit.

OWASP's A01 page sets the rule. "Access control is only effective when implemented in trusted server-side code or serverless APIs, where the attacker cannot modify the access control check or metadata." Our broken access control guide has a simple two-account test for your own app.

4. Logins and sessions

[ ] Sessions end on the server after logout, or tokens are short-lived.
[ ] Password reset and email change flows have been tried by a person.
[ ] Login attempts and sensitive actions are rate limited.

OWASP says stateful session identifiers should be invalidated on the server after logout. It says stateless tokens should be short-lived. It also recommends rate limits to reduce harm from automated attacks.

5. Payments

[ ] Only publishable Stripe keys appear in the browser.
[ ] Webhooks verify the signature before acting.
[ ] Fulfillment runs from verified webhooks and handles duplicates.
[ ] Prices are set on the server.

Stripe's webhook guide explains the risk. "Without verification, an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders, granting account access, or modifying records." The full list is in our Stripe checklist for AI-built apps.

6. Dependencies and framework versions

[ ] You know which framework versions you run.
[ ] Known security fixes are applied.
[ ] Someone owns checking for updates each month.

OWASP's 2025 list includes Software Supply Chain Failures as A03.

A real example shows why versions matter. CVE-2025-29927 let authorization checks be bypassed in Next.js when the check happened in middleware. It was fixed in 12.3.5, 13.5.9, 14.2.25 and 15.2.3.

7. Environments and data separation

[ ] Development and production use separate databases.
[ ] Test data is not real customer data.
[ ] AI tools can't write to production without a human step.

Tools differ here, so check yours. Replit's development and production docs say "Agent is not able to modify the production database." That is a statement about Replit only.

8. Mistakes, logs and alerts

[ ] Error pages don't reveal stack traces or internal details.
[ ] Failed logins and refused access attempts are logged.
[ ] Logs don't store passwords, tokens or card details.
[ ] Someone gets an alert when something repeats.

OWASP's list includes Security Logging and Alerting Failures as A09. Its access control page says to log failures and alert admins when appropriate, such as after repeated failures.

9. Use the builder's tools, then go further

AI builders ship their own checks. They're worth running, but read their limits.

Lovable's security docs are candid. "These tools help identify common security issues, but they cannot guarantee complete security." They also say "You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions."

A scan is a good floor. It doesn't know your business rules.

10. Have a person review the result

A published benchmark explains why. The SusVibes preprint, revised 21 September 2026, tested AI coding agents on 186 tasks. The authors report: "Although 57% of the solutions from SWE-Agent with Claude 4 Sonnet are functionally correct, only 11.8% are secure."

That is one agent and model on benchmark tasks, not a measure of live business apps. It does show that working code and safe code are different things.

So include security requirements in your prompts, then have someone read the result.

What this checklist can't do

It can't prove your app is safe, and neither can any tool. It reduces risk.

eSEOspace does not do penetration testing. A penetration test actively tries to exploit weaknesses. If your app holds health, financial or other sensitive data, hire a qualified firm.

Next step

Fix anything open in sections 1 to 3 first, then work down. If you're preparing to launch, also read our pre-deploy checklist.

For outside help, our website security consulting covers assessments of your setup and vendors. It reduces risk, but it cannot certify an app as safe.

Frequently asked questions

What should I check first?

Check your database rules. Supabase says a table in an exposed schema without row-level security is open to any role with a grant on it.

Is my builder's security scan enough?

Treat it as a starting point. Lovable's own docs say its tools cannot guarantee complete security. They suggest an additional professional review for apps handling sensitive data.

Are AI-built apps less safe than hand-written apps?

We found no source that establishes this for real sites. Benchmarks test generated code on tasks, not live businesses. Review matters either way.

Can I run these checks on another company's app?

No. Only test apps you own or have written permission to test. Testing someone else's site can create legal exposure.

Do you offer penetration testing?

No. eSEOspace does not do penetration testing. If you need one, hire a qualified firm.

AI-Built App Security Review Checklist