Security checklist for AI-built apps

What this is and isn't. This is a practical list for founders. It doesn't replace a professional security assessment. If you store health records, payment card numbers or other regulated data, or you sell to companies that will ask for a security review, hire a specialist.

Authorization: who can see and change what

Check this first. A missing access check is invisible when you test as yourself, so test with two accounts.

• Every request that reads or writes data checks, on the server, that the signed-in user is allowed to. A check in the front end alone doesn't protect anything.
• Sign in as user A, copy the URL or API request for one of A's records, then sign in as user B and try it. B should get an error.
• In Supabase, Row Level Security is enabled on every table, and each policy limits rows to the right user or team. A policy of true allows everyone.
• In Firebase, security rules aren't still in test mode, which allows anyone to read and write.
• Admin features check an admin role on the server.

Secrets

• Anything in front-end code is public. That includes environment variables with a NEXT_PUBLIC_ or VITE_ prefix, which are built into the JavaScript sent to browsers.
• Supabase's anon key is meant to be public, provided your RLS policies are right. The service role key bypasses RLS and must only be used on the server.
• Secret keys for Stripe, OpenAI, Anthropic, email and SMS providers stay on the server.
• Scan the repository and its Git history with a tool such as gitleaks. If a secret was ever committed, rotate it. Deleting it in a later commit isn't enough.

Sign-in

• Use an established auth provider or library. Don't let the agent write its own password storage.
• Password reset links expire and work only once.
• Sign-in and password reset are rate limited.
• Sessions expire, and signing out ends the session on the server.

Input and output

• Database queries use parameters or an ORM, never strings assembled from user input.
• User-supplied HTML is sanitized before it's rendered. Search for dangerouslySetInnerHTML and v-html.
• Forms are validated on the server as well as in the browser.
• File uploads check type and size, and private files go in private storage buckets.
• API responses return only the fields the page needs. A user object shouldn't include password hashes, other users' emails, or internal flags.

Webhooks and APIs

• Webhook handlers verify the sender's signature before acting.
• CORS doesn't allow every origin on endpoints that use cookies or credentials.
• Server functions that call other URLs don't fetch whatever URL a user supplies.

AI features in your app

• Treat model output as untrusted input. Don't let it run database queries, shell commands or permission changes directly.
• Assume users can get the model to reveal its system prompt, so keep secrets out of it.
• Text the model reads, such as a user's document or a web page, can contain instructions. Limit what the model is allowed to do with it.
• Model calls are limited per user, and the provider has a spending cap.

Dependencies

• Run npm audit or turn on Dependabot, and fix the high severity results.
• Check that every package the agent added is the real one. AI models sometimes suggest packages that don't exist, and attackers have published packages under names like those.
• Remove packages the app no longer uses.

Logs and privacy

• Passwords, tokens and full card numbers never appear in logs.
• You know which third parties receive user data: analytics, AI providers, email services. Your privacy policy says so.

Checking with your AI tool

Ask about one section at a time, and ask for evidence: “List every API route, and for each one, show the line that checks the user is allowed to access the record.” A route with no line to show is the one to fix. Then test the fix with two accounts.

Security is one part of being ready for users. The production checklist covers the rest.