Common security gaps in apps built with AI tools
AI coding tools can accelerate a good engineering process, but they can also accelerate an unsafe assumption. The recurring problems are usually ordinary application-security gaps, introduced when generated code is accepted without checking the trust boundary around it.
1. The browser is trusted to enforce permissions
Hiding an admin button is not authorisation. Every API route and server action must verify the signed-in identity and the specific resource that identity may access. A useful test is to change a record identifier in a request and confirm that the server rejects access to another user's data.
2. Database rules are broader than the interface suggests
Supabase row-level security and Firebase rules are part of the application's security boundary. A polished interface can still sit in front of public tables or rules that permit any authenticated user to read every record. Review policies against each role and test them directly, not only through the normal interface.
3. Secrets are placed in public code
Anything shipped to a browser is public. Service-role keys, private API tokens and webhook secrets belong on the server or in a managed secret store. Removing a leaked value from Git is not enough: rotate it, review its usage history and determine what it could access.
4. Authentication exists, but session handling is incomplete
Sign-in is only one part of authentication. Check session expiry, logout, password-reset or magic-link reuse, cookie flags, rate limits and whether sensitive account changes require recent authentication. Error messages should not disclose whether a particular email address has an account.
5. Webhooks and background actions trust unverified input
Payment success pages and browser redirects are not proof of payment. Stripe and similar providers sign webhook requests so the server can verify the raw payload before changing an order. Processing must also be idempotent: delivery of the same event twice must not create two engagements or send the same benefit twice.
6. Production defaults were never reviewed
Development CORS rules, verbose errors, source maps, test accounts and permissive storage policies often survive the launch. Create a short release checklist that covers secrets, logging, access rules, backups, dependency risk and monitoring. Re-run it whenever the deployment architecture changes.
The build tool is not the risk classification. Review the resulting application, its data rules and its deployment. See the £149 launch-review scope.