Security Checklist for AI-Built Apps: What to Fix Before You Launch

AI coding tools produce working apps remarkably fast. What they rarely produce is a secure one by default. The hard part is that many vulnerabilities in AI-generated apps are invisible: they do not cause errors, crash the app, or show up in a demo. The app can appear to work while user data remains reachable through a missing access check.

This checklist covers issues that commonly appear in apps built with tools such as Cursor, Claude, Lovable, Bolt, and Replit. It applies whether your backend is Supabase, Firebase, or something custom. Work through it before launch, and again whenever you ship a feature that touches user data.

Quick reference

Data access

The most serious leaks often begin here because generated code can fetch data without consistently deciding who is allowed to see each record.

1. Verify database access rules

For Supabase, RLS should be enabled on every table in an exposed schema. Tables created with the Dashboard Table Editor have RLS enabled by default, while tables created through raw SQL or the SQL Editor require you to enable it yourself. Enabling RLS is only the start: each table still needs policies that express who may select, insert, update, or delete its rows.

For Cloud Firestore mobile and web clients, use Firebase Authentication with Security Rules that compare the requesting user to the resource owner and validate incoming data. Server client libraries bypass Firestore Security Rules and must be protected with IAM and server-side authorization instead.

Whatever the backend, verify the result with two accounts. Log in as the second user and attempt to read or change the first user's records. Perform this testing only against an application you own or are authorized to assess.

2. Separate authentication from authorization

Logging a user in is not the same as deciding what they may access. For every action that reads or writes data, confirm the server or database checks that this specific user may act on this specific record, not merely that someone is logged in.

3. Test object-level authorization

Changing an object ID in a URL or request is a common way to expose broken object-level authorization. Test whether a second user can load or modify the first user's object after changing that identifier. OWASP lists broken object-level authorization as a leading API risk because every endpoint that accepts an object ID needs an appropriate access check.

Secrets and build output

Everything delivered to a browser should be treated as public.

4. Keep private secrets out of the frontend

AI-generated integrations may place credentials directly in client code. Review the deployed client bundle and network requests for private values. Stripe secret keys, service-role tokens, and private third-party API keys belong in server-side environment variables, with the browser calling a protected backend endpoint.

Some values, including Firebase web configuration and Supabase anon or publishable keys, are designed to appear in a client application. Their safety depends on properly configured access rules and policies; they should never be treated as a replacement for authorization.

5. Control production source maps

Public production source maps can reveal original client-side source, filenames, names, and comments that make reconnaissance easier. They are not a substitute for protecting secrets, because secrets should never enter client code in the first place. Disable public source maps when you do not need them, or upload them privately to an error-monitoring service instead of serving them to every visitor.

6. Audit dependencies

Generated apps can accumulate packages quickly. Run the audit supported by your package manager, review high- and critical-severity advisories in the context of how the dependency is used, and update, replace, or mitigate affected packages. Repeat this process as dependencies change.

Endpoints and abuse

The API is often less visible than the interface in front of it, but it requires the same authorization review.

7. Require appropriate access on every API route

Call each private endpoint while logged out and as a normal user. Confirm that it rejects requests without the required identity and role. Pay special attention to routes hidden by the interface but still reachable directly.

8. Protect admin functionality on the server

A hidden button is not access control. Gate admin pages and APIs with a real server-side role or permission check, then verify the behavior while logged out and while signed in as a non-admin user.

9. Limit expensive and abuse-prone operations

An endpoint without practical limits can be used for scraping, credential attacks, denial of service, or unexpected AI and infrastructure bills. Apply controls appropriate to the risk: rate limits, request-size limits, pagination caps, timeouts, spending limits, and per-user quotas. Return clear errors when a limit is reached, and monitor repeated failures.

10. Validate input and file uploads

Validate input on the server against an explicit schema. For uploads, restrict allowed types and sizes, generate safe storage names, scan or transform files when appropriate, and store them in a location that cannot execute uploaded content. Do not rely on the filename or browser-provided MIME type alone.

Configuration

Hosting and framework defaults still need to be reviewed for the way your application works.

11. Add relevant security headers

Review protections such as Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and clickjacking protection through CSP frame-ancestors or X-Frame-Options. The correct policy depends on the application, so test changes before enforcing a restrictive CSP in production.

12. Enforce HTTPS and review CORS

Serve production traffic over HTTPS and consider HSTS after confirming that every required subdomain supports HTTPS. Review CORS separately: it controls which browser origins may read a response, but it is not authentication or authorization. A wildcard can be appropriate for a deliberately public, non-credentialed resource; credentialed or sensitive browser APIs should allow only the origins that actually need access.

The pattern

Across these checks, the underlying issue is the same: AI usually writes code for the successful request you described, not every hostile or unauthorized request an attacker might make. The fixes are often manageable. They are easy to skip because the product already appears to work without them.

Run this checklist before launch and after any feature that touches identity, permissions, payments, uploads, or customer data. For higher-risk systems, automated scanning is useful but does not replace threat modeling, code review, or a qualified security assessment.

Primary references

• Supabase Row Level Security documentation
• Firebase: Secure data in Cloud Firestore
• OWASP API Security Top 10, 2023
• MDN: Cross-Origin Resource Sharing

About the author

This checklist was contributed by the team behind vas, a security scanner built specifically for AI-generated apps. vas scans a live app for issues such as exposed keys, open database rules, unprotected routes, broken object-level authorization, and missing headers, then returns a specific fix for each finding.