A working demo does not establish that an app protects its users and data. Review the actual code, configuration and intended access rules before putting customer information or money through it.
These are practical review points, not a measured failure rate for AI-built apps or a claim about every builder. Only test systems you own or have explicit authority to assess, preferably in a suitable test environment.
Authentication and access
- Verify the sign-in and session behaviour for the intended users.
- Check server-side authorisation on protected actions.
- Check that one account cannot access another account's records.
- Review roles and administrative permissions using least privilege.
- Test password recovery and session expiry for the actual implementation.
OWASP distinguishes authentication from authorisation and recommends validating permissions on each request. A hidden button or a signed-in browser is not an access-control boundary. OWASP authorisation guidance and authentication guidance.
Data exposure
- Review the data each API response returns.
- Check database grants and row-level policies against intended access.
- Review storage permissions for public and private files.
- Keep privileged keys and credentials out of frontend code and version history.
- Review logs and error responses for sensitive data.
For Supabase, verify the actual grants and RLS policies. Do not assume every project starts with the same defaults or that enabling RLS alone proves the right access. Supabase's current RLS guidance explains how grants and policies interact.
Backend and business rules
- Validate important inputs on the server.
- Use trusted server-side prices and entitlements.
- Verify provider webhook signatures and handling for duplicate events.
- Review rate limits and abuse handling for exposed actions.
- Test uploads, outbound requests and third-party dependencies within scope.
Infrastructure and release
- Check environment configuration and dependency updates.
- Agree backups, recovery and incident ownership.
- Require review and relevant checks before release.
Use severity, not a failed-item count
A single serious access or data issue can require immediate attention. Several low-impact findings may have a different response. Triage against the actual exposure, affected users and consequences rather than a rule that a certain number of failures always requires a rebuild.
Passing a checklist does not guarantee an app is secure or prevent every future generation from introducing a fault. Agree the scope, evidence, remediation and retest for a proper assessment. This guide makes no changes to your authentication, database or payment setup.
See Sonder's app review and rescue service for a concrete review conversation. Findings and estimates should describe the inspected application and the limits of the assessment.
Sources and review
Guidance checked on 7 October 2026. Features and commercial terms can change; confirm availability for your own account and scope. These planning checks are recommendations and do not replace an assessment of the actual implementation.