Guides / Prompting and shipping

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

A practical security checklist for AI-built apps: login and permissions, secrets, input validation, per-user data, rate limits, dependencies and backups.

Mythex Team · 2026-09-29 · 8 min read

Before real people use an app you built with AI, check seven things: every page and API checks who the user is and what they may do; secret keys live on the server, never in the browser or chat; all input is validated on the server; each user can only reach their own records; login and costly endpoints are rate-limited; dependencies are up to date; and you can restore your data if something goes wrong. The checklist below turns each of those into specific tests you can run without reading code.

AI app builders are good at making features work. They are not automatically careful, because "careful" is rarely in the prompt. Most of the problems below come from things nobody asked for, so the fix is usually to ask.

How to use this checklist

Work through it in order, and for each item do two things: ask the AI to make sure it's handled, and test it yourself. The AI can write a permission check; only a test tells you it works. Items are marked:

• Must — do this before anyone else uses the app.
• Should — do this before you have real users or real data.
• Later — worth doing as the app grows.

If you only have an hour, do every Must.

1. Authentication: who is this?

Authentication means confirming who someone is — usually login. See what authentication is for the basics and how to add login to your app for the options.

• Must: Every page that shows private data requires login. Test: log out, then paste the URL of a private page directly into the browser.
• Must: Every API endpoint behind those pages also requires login — not just the page. Test: log out, open the browser's network tab, and retry a request the app made while you were logged in.
• Must: Passwords are stored hashed with a slow password-hashing algorithm, never in plain text. OWASP's password storage guidance recommends Argon2id first, with scrypt, bcrypt or PBKDF2 as alternatives. Ask: "How are passwords stored?"
• Should: Password reset links expire and work only once.
• Should: Session cookies are marked Secure, HttpOnly and SameSite, and logging out ends the session on the server.
• Later: Offer two-factor authentication, or sign-in through a provider that has it.

Check every API route and page that returns user data. Each one must reject requests from users who aren't logged in, on the server, not only in the page's code. List the routes you checked.

2. Authorization: what are they allowed to do?

Authorization is the step after login: deciding what this particular user may see and change. This is where AI-built apps most often have serious holes, because the app looks right — each user's dashboard only shows their own data — while the server will happily hand over anyone's data if asked directly.

• Must: Every read, update and delete checks that the record belongs to the current user (or their team), on the server.
• Must: Test it: create two accounts, A and B. As A, open one of A's records and note the ID in the URL or network request. Log in as B and request that same ID. B must get an error, not A's data.
• Must: Admin pages and admin API endpoints check the user's role on the server. Hiding the admin link is not protection.
• Must: Users can't change their own role, price, balance or owner fields by editing the request. Test: in the network tab, look at what a profile update sends. If it includes fields like role or isAdmin, ask the AI to ignore them from the client.
• Should: IDs in URLs are hard to guess (random IDs rather than 1, 2, 3). This is not a replacement for permission checks, but it limits damage when one is missing.

For every endpoint that reads or changes a record, check on the server that the logged-in user owns it or is allowed to access it. Return 404 if not. Then show me how you'd test this with two accounts.

3. Row-level access in the database

"Row-level access" means each row of a table (one booking, one invoice) is only visible to the users it belongs to. There are two common ways to enforce it:

Either can be done well. What matters:

• Must: If the browser talks to the database directly (some hosted database products allow this), row-level rules are switched on for every table. Without them, anyone with the public key can read the whole table.
• Must: Queries filter by the current user or team, not by an ID the browser sends.
• Should: Shared data (a team's projects) has a clear rule for who's in the team, enforced in one place.

4. Secrets and API keys

An API key is a password for a service. Stripe, email and AI providers all use them. For background, see what environment variables and secrets are.

• Must: Keys are stored in the project's environment variables or secrets, never written into the code.
• Must: Keys that can spend money or read private data are only used on the server. Test: open your live site, view the page source and the JavaScript files in devtools, and search for the start of your key (for example sk_). It must not appear.
• Must: Keys were never pasted into chat, a public repository, or a screenshot. If one was, rotate it at the provider (create a new one, delete the old one).
• Should: Use restricted or scoped keys where the provider offers them. Stripe, for example, recommends restricted keys that only have the permissions your integration needs.
• Should: Test and live keys are separate, and the live app uses live keys only when you're ready.

Some keys are designed to be public — Stripe's publishable key (pk_…) or a maps key restricted to your domain. The rule is about keys that grant power, not every string that looks like a key.

5. Input validation

Anything a user sends — form fields, file uploads, URL parameters — can be anything, not just what your form allows.

• Must: Validation happens on the server, not only in the browser. Browser checks are for convenience; anyone can skip them.
• Must: Database queries use parameters, not text glued together from user input (this prevents SQL injection). Ask the AI to confirm.
• Must: Text that users enter is displayed as text, not run as HTML. Test: enter <b>hello</b> as your name. You should see the tags, not bold text.
• Should: File uploads check type and size, and uploaded files aren't served from your app's main domain as runnable pages.
• Should: Errors shown to users are plain ("Something went wrong"); detailed errors go to the server logs only.
• Should: Webhooks from services like Stripe verify the provider's signature before acting. See what a webhook is.

Add server-side validation to every form and API endpoint: required fields, lengths, formats and allowed values. Reject anything else with a clear message. Don't show internal error details to users.

6. Rate limits and abuse

A rate limit caps how many requests someone can make in a period. Without them, anyone can guess passwords all day, flood your signup form, or run up your bill on a paid API.

• Must: Login, signup and password reset are rate-limited per IP address and per account.
• Must: Anything that costs you money per call — AI model requests, SMS, email — has a per-user limit and requires login.
• Should: Public forms (contact, waitlist) have spam protection: a rate limit, a hidden honeypot field, or a CAPTCHA.
• Should: Set spending caps or alerts at your paid providers, so a bug or an attacker can't produce an unlimited bill.

7. Dependencies

Apps are built from open-source packages, and packages sometimes have known vulnerabilities.

• Should: Ask the AI to check for known vulnerabilities (for JavaScript projects, npm audit or the equivalent for your package manager) and update what's affected.
• Should: Remove packages the app no longer uses.
• Should: Be wary of packages with very few users or names that look like typos of popular ones.
• Later: Re-check every month or two, or turn on automated alerts if your code is on GitHub.

8. Backups and recovery

Security includes being able to recover from mistakes — yours, the AI's, or an attacker's.

• Must: Know where your data lives and whether it's backed up. Don't assume; check your host's documentation.
• Should: Keep your own periodic export of important data (for example, a CSV export feature or a database dump), stored somewhere separate.
• Should: Keep your code in version control, so any version can be restored.
• Should: Destructive actions (delete account, delete project) ask for confirmation, and consider a "soft delete" that can be undone for a while.
• Later: Actually test a restore once. A backup you've never restored is a hope, not a plan.

9. Before launch

• Must: The live site uses HTTPS everywhere.
• Must: Sample data, test accounts and debug pages from development are removed.
• Should: A privacy policy says what data you collect and why — required in many places if you collect personal data. Don't claim certifications (SOC 2, HIPAA) you don't have.
• Should: You have a way to be contacted about security issues, and you know how to rotate every key quickly.

For a broader pre-launch pass beyond security, see how to take an AI prototype to production.

When to get a professional review

A checklist catches common mistakes; it doesn't replace an expert. Consider paying for a review if you process card numbers yourself instead of through a hosted checkout, store health, financial or children's data, sell to companies that ask for security questionnaires, or would be seriously harmed by a leak. Having your code exportable makes that review much easier.

Security when building on Mythex

Mythex doesn't include a security-scan panel, so the checklist above is the process to follow. Some things that help:

• Project secrets. Store keys under project settings → Secrets, or through the secrets card the agent shows in chat, so they stay out of your code and messages. After changing a secret for a live app, publish again.
• Plan and Ask modes. Ask the agent to review permissions without editing: "In Ask mode, list every API route and what permission check it does."
• /test has the agent click through your preview as a user — useful for the two-account test in section 2.
• Checkpoints let you roll back a change that broke something.

See Security for apps you build and Environment variables and secrets in the docs. If you're adding user accounts next, read how to add login to your app.