What security checks should I do before launching an app built with AI?

Before you launch an app built with AI, check six things: no secrets in the browser or the repo, permissions checked on the server for every table and action, payment webhooks verified before anyone gets access, rate limits on anything that can be abused, an agent that cannot touch production, and dependencies that really exist. AI coding tools often miss these, so run a focused review against a written checklist before real users and money arrive.

Recommended resource: for the full step-by-step method, Build Software With AI by Manthan Bhendkar (founder of Asendify) covers this in depth. PDF, £500.00, instant download.

This is general guidance for non-engineers shipping their first product, not a professional security audit.

1. Get every secret out of the browser and the repo

A secret is any string that grants access: database passwords, API keys, webhook signing secrets, your Supabase service-role key. Two rules cover most of it.

• Nothing secret reaches the browser. Anything sent to the browser is public. In Next.js, environment variables are server-only by default, but any variable prefixed `NEXT_PUBLIC_` is built into the JavaScript visitors download. A secret with that prefix has been published. Other frameworks have their own prefixes, so check yours.
• Nothing secret goes into the repo. `.env` files belong in `.gitignore`. Production and preview keys live in your host's settings.

Then do three quick checks:

1. Search the whole repo for your providers' key prefixes (for Stripe live keys, `git grep -n "sk_live"`). It should find nothing.
2. Use test keys on local and preview, and live keys only in production.
3. If a key ever turned up in a chat log, screenshot, commit or shared doc, rotate it: create a new one, update the environment, then revoke the old one.

Add a line to your rules file: "Never write a secret value into any file other than .env.local."

2. Check permissions on the server, every time

Authentication proves who someone is; authorisation decides what they may do. AI tools usually get the first right and the second wrong, because it must be repeated on every action.

The principle: treat everything the browser sends as a request, never as the truth. In practice:

• The price comes from your database or payment provider, never from a hidden field or a URL.
• The user's identity and role come from the session your server has verified, never from a `role=admin` value in a cookie or request body.
• Every ID in a request is checked against that session. If changing `/projects/7` to `/projects/8` shows someone else's project, you have a serious hole. Hiding a button is not a permission.

If you use Supabase, Row Level Security does much of this at the database level. The Supabase RLS documentation says to enable RLS on every table in an exposed schema. Once it is on, nothing can be read with the public key until you write policies. Watch for policies that are `using (true)` for anonymous users: they give every visitor access, which is only right for genuinely public data. The service-role key bypasses RLS, so it must only ever run on the server.

The test that matters: create two ordinary user accounts. Log in as user A and try to read, edit and delete user B's data by changing IDs. Every attempt should fail.

3. Grant paid access only from a verified webhook

The success page after checkout grants nothing. It is just a "thanks, confirming your payment" screen. Access should be granted only when your server receives the payment provider's webhook and has checked it.

• Verify the signature first. Stripe signs each event in a `Stripe-Signature` header. Its webhook documentation warns that without verification, an attacker could send fake events to your endpoint to trigger actions like fulfilling orders or granting account access.
• Check the amount and currency against the order you created on the server.
• Expect duplicates. Store processed event IDs with a unique constraint, so a replayed event cannot grant two licences or send two receipts.
• Return a 2xx quickly, then do slow work such as sending emails.

The same pattern applies with PayPal, Razorpay or a merchant of record.

4. Close the classic web holes and add rate limits

Ask your AI tool for these defences, then check they are actually in the code:

• Injection: parameterised queries only, and never SQL built by joining strings together.
• Cross-site scripting: let the framework escape output (React does this by default), and forbid raw-HTML escape hatches unless the content goes through a maintained sanitiser.
• Validation: check every input on the server with a schema covering type, length and allowed values. Validation in the browser is a convenience, not a defence.
• File uploads: allow file types by inspecting the content rather than the extension, cap the size, and store files under generated names.
• Rate limits: on login, sign-up, password reset, anything that sends email and any endpoint that calls a paid API.

5. Treat your AI agent as an attack surface

Prompt injection sits at number one in the OWASP Top 10 for LLM Applications 2025. It happens when text the model reads, such as a web page, an issue, a README or a customer message, contains instructions the model then follows. This applies to the coding agent building your app and to any AI feature inside it.

• Never give an agent production write access you cannot undo. It should work against a development database, and production credentials should not exist anywhere the agent runs.
• Use the strictest permission mode you can work with, and read each command before you approve it.
• In your product's AI features, treat model output as untrusted. Don't let it trigger payments, deletions or emails without a server-side check.

6. Back up, then check your dependencies

Backups: turn on automatic backups and restore one at least once before launch. A backup you have never restored is only a hope.

Dependencies: run your package manager's audit (`npm audit` for Node) and fix high-severity findings. AI models also sometimes recommend packages that don't exist, and attackers can register those names with malicious code inside. Before installing any new package, check it is on the official registry with a real history, and that the spelling matches exactly. Add a rule: "Do not add dependencies without listing them first and waiting for my approval."

Finally, run a security review prompt in a fresh AI session, not the one that wrote the code, and record each finding as fixed or accepted with a reason. If you handle card data directly, health data, children's data or identity documents, pay a qualified human to review before launch.

Key takeaways

• Search for key prefixes before every release, keep secrets server-side, and rotate anything that has been exposed.
• Enforce authorisation on the server and prove it with a two-user test.
• Only a signature-verified webhook unlocks paid access, never the success page.
• Rate-limit logins, sign-ups and anything that costs you money per call.
• Keep agents away from production, test a backup restore, and verify every new package.

FAQ

Is Supabase secure by default?

Only once RLS is enabled with correct policies on each table. A table without RLS in an exposed schema, or a `using (true)` policy, can leave data open to anyone with your public key.

Can I ask the AI to do the security review itself?

Yes, as one pass. Use a fresh session, give it your checklist and spec, and then check its claims yourself with real tests, such as the two-user test and a fake webhook. Don't treat "looks secure" as proof.

When do I need a professional security audit?

Get one if you store card details yourself rather than using a hosted checkout, if you handle health, children's or identity data, if you work in a regulated industry, or if a breach would be catastrophic for a client. If you're unsure what the build and review will cost, the free AI Build Cost Calculator gives you a starting figure.

I'm Manthan, and I'm not an engineer. I built this shop, Outbound, Notes and Asendify AI with Claude, and this is the checklist I would want any non-engineer to run. Build Software With AI gives the full version in Part 13: the security review prompt, the rules-file lines, and when to bring in a human, alongside the build loop it fits into.

Looking for a different topic? Browse all 23 Asendify books by topic.