Pre-Launch Security Checklist for Vibe Coders (With a Free AI Evals Template)

A pre-launch security checklist for an AI-built app has 16 checks in five batches. Paste one audit prompt into your coding agent, read its pass or fail report, fix the fails one batch at a time, and re-run the audit until everything passes. Then use the free AI evals template at the end to make sure your AI features keep behaving well.

Last updated 11 November 2026 by Vinita Mathreja, who has shipped 30+ AI-built projects and writes about vibe coding at WhatTheWeb.

Pre-launch security checklist: key takeaways

• 16 checks, five batches. Data layer, browser and login, abuse and traffic, hygiene, and safety net.
• One prompt does the audit. Your coding agent reports pass, fail, or not applicable in plain English, so you never read code.
• Report first, fix second. Tell the agent not to change anything until you have read the report.
• Every check maps to a real standard. Fourteen of the 16 line up with the OWASP Top 10:2025.
• A pre-launch security checklist is not an eval. Security locks the app down. Evals check that the AI inside it still behaves.

What is a pre-launch security checklist?

A pre-launch security checklist is a short list of protections you confirm before real users touch your app. It matters most when AI wrote the code, because a coding agent builds what you asked for and does not always lock the doors you forgot to mention.

This one covers 16 of those doors. They sit in five batches, so you can fix them in small, calm steps. You do not need to read code to use it, because your coding agent does the checking and reports back in plain English. If you are still at the planning stage, start with the eight simple docs you need before you vibe code an app, then come back here before you launch.

Who should use this pre-launch security checklist?

Use it if you built an app with Claude Code, Cursor, Lovable, Replit, Bolt, or any other coding agent, and you are about to let strangers sign in. It assumes three things, and nothing more.

• Your app has a database, a login, or both.
• You can paste a prompt into the agent that built it.
• You can read a plain-English report and decide what to fix.

That is the whole bar. However, if your app takes payments or handles medical or financial records, treat this as a floor rather than a finish line, and budget for a professional review as well.

How do you run a security audit with your coding agent?

You run the pre-launch security checklist in five steps. Paste one prompt, read the report, fix in batches, then repeat until the list is clean.

1. Copy the audit prompt below into your coding agent.
2. Read the pass or fail report before letting the agent change anything.
3. Fix the fails one batch at a time, using the five batches in this guide.
4. Run the audit again after fixing, until everything passes or is not applicable.
5. Finally, use the evals template at the end to check that your AI features keep behaving well.

Here is the audit prompt to copy and paste:

Act as a security reviewer for my app. Go through each item on this list and give me a pass, fail, or not applicable, with one plain-English line explaining why, and a fix for anything that fails. The list is: row level security on every table, SQL injection, exposed admin keys, XSS, secrets in code, authentication on every private route, CSRF, rate limiting, CORS, HTTPS, vulnerable dependencies, file uploads, error messages, logging and alerts, backups, and security headers. Don't change anything yet, just report.

That prompt is the whole pre-launch security checklist in one paste. The last line, “don’t change anything yet,” is the safety catch. It stops the agent from editing your app before you have read the report. That one sentence is doing a lot of work, and it is a good example of why structuring a prompt properly changes what you get back.

What are the 16 checks on the pre-launch security checklist?

The pre-launch security checklist has 16 items: row level security, SQL injection, exposed admin keys, XSS, secrets, authentication, CSRF, rate limiting, CORS, HTTPS, dependencies, file uploads, error messages, logging, backups, and security headers. The table below explains what each item on the pre-launch security checklist protects, which batch it belongs to, and the closest category in the OWASP Top 10:2025, so you can see that none of this is invented.

Checks 1 to 9: data, login and traffic

Checks 10 to 16: hygiene and safety net

The second half of the pre-launch security checklist is less dramatic, but it is just as load-bearing. These seven cover everyday hygiene and the safety net you will be grateful for later.

What changed in the OWASP Top 10:2025?

Three names in that last column are worth noticing, because the 2025 edition of the OWASP Top 10 changed. Supply chain failures moved up to A03, and a brand new category, A10 Mishandling of Exceptional Conditions, covers exactly the sloppy error messages that AI-built apps leak by default.

How do you fix the fails on your pre-launch security checklist?

Work through the pre-launch security checklist one batch at a time, in this order: data layer, browser and login, abuse and traffic, hygiene, then safety net. Small batches are easier to review, and you can re-run the audit after each one.

Batch 1: Data layer

Start with the database, because that is where your users’ real data lives. These three items top the pre-launch security checklist for a reason.

1. Row level security (RLS). Turn it on for every database table so users can only read and write their own rows. Supabase explains the pattern well in its row level security guide, and the same idea applies wherever your data sits.
2. SQL injection. Make sure user input is never stitched directly into a database query. This is the oldest trick in the book, and it still sits at A05 in the OWASP list.
3. Exposed admin keys. Check that your database admin keys, like the service role key, never appear in anything the browser can see.

Batch 2: Browser and login

Next come the three checks that stop attackers from using your own pages and login flow against you.

1. XSS (cross-site scripting). Clean any text a user types in, like comments or names, before it reaches a page, so nobody can sneak in a malicious script. The OWASP XSS prevention cheat sheet is the reference your agent should follow.
2. Secrets. Keep all API keys and passwords in environment variables on your host, never in your code or your GitHub repo.
3. Authentication. Check that every private page and every API route verifies who is calling, rather than just hiding the button on the screen.

Batch 3: Abuse and traffic

Now the pre-launch security checklist turns outward, to the bots and bad websites that want to abuse your app.

1. CSRF (cross-site request forgery). A bad site can trick a logged-in user’s browser into doing something on your app. Ask your agent to add protection tokens or strict cookie settings, following the OWASP CSRF prevention cheat sheet.
2. Rate limiting. Cap how many requests one person or IP can make per minute, so bots cannot hammer your login page or run up your AI API bill. That second one bites harder than people expect, which is why it is worth watching your token usage from day one.
3. CORS. Make sure your backend only accepts requests from your own domain, not from anywhere on the internet.

Batch 4: Hygiene

These four checks are the everyday basics, and they are the ones people skip. Most hacks slip through a gap on this part of the pre-launch security checklist rather than through anything clever.

1. HTTPS everywhere. Force secure connections and never serve anything over plain http.
2. Dependencies. Ask your agent to scan your packages for known vulnerabilities and update the risky ones, because many hacks arrive through outdated libraries. On a JavaScript project, npm audit does this in one command.
3. File uploads. Restrict file types and sizes, and never let uploaded files run as code. The OWASP file upload cheat sheet lists the traps.
4. Error messages. In production, show users a friendly error, never the raw technical details, because those leak how your system works.

Batch 5: Safety net

These three checks close out the pre-launch security checklist. They help you spot trouble early, and they help you recover when something goes wrong.

1. Logging and monitoring. Record failed logins and server errors, and set up alerts, so you find out about trouble before your users do.
2. Backups. Turn on automatic database backups, and actually test restoring one. An untested backup is just a hope.
3. Security headers. Ask your agent to add the standard ones, starting with a content security policy, which tells browsers which scripts are allowed to run on your site.

What is an AI eval, and how do you build one?

An eval is a repeatable test for your AI feature. You write down what good looks like, run the same questions every time, and score the answers. The pre-launch security checklist tells you the app is locked down. Evals tell you the AI inside it keeps behaving well. Anthropic calls this defining success criteria and building evaluations, and the idea is the same whichever model you use.

Where the pre-launch security checklist is a one-off gate, evals are a habit. Fill in the five parts below for any AI feature in your app. For a longer walkthrough with worked examples, read AI evals: 7 proven fixes for apps that keep breaking.

Part 1: What am I testing?

1. Feature name. The one AI feature this eval covers. Name it the same way you named items on your pre-launch security checklist, so the two lists stay easy to cross-reference.
2. Job in one sentence. What the feature should do for the user.
3. Who uses it. The kind of person and what they usually ask.
4. What a great result looks like. Two or three plain-English qualities, such as accurate, on-brand, short, or safe.

Part 2: Which test cases should you write?

Start with 10 to 20 cases. Include normal ones, tricky ones, and a few that try to break the feature. Think of it the way you thought about the pre-launch security checklist: you are looking for the doors you forgot. Copy this table and fill it in.

Part 3: How should you score the answers?

Scoring works like the pass or fail column on your pre-launch security checklist, so keep it just as blunt.

1. Pick 3 to 5 criteria, for example accuracy, tone, format, safety, and length.
2. Score each one as pass or fail, or 1 to 5 if you want more detail.
3. Set a passing bar up front, for example “at least 90 percent of cases must pass, and zero safety fails.”
4. Decide who scores: you by hand, the AI as a judge using your criteria, or both. For anything high-stakes, check some of the AI’s scores yourself.

Part 4: How do you run the eval?

1. Run every test case the same way each time, with the same settings.
2. Record each answer next to its case.
3. Score each answer using the criteria from Part 3.
4. Write a short summary: total passes, total fails, and the three worst misses.

Hand this to your coding agent the same way you handed over the pre-launch security checklist, with a prompt like this one:

Act as an evaluator for my AI feature. Here is what the feature should do, here are my test cases, and here are my scoring criteria. Run every test case through the feature, score each answer pass or fail against the criteria with one plain-English reason, and give me a summary with the pass rate and the three worst failures. Don't change the feature yet, just report.

Part 5: How do you review and improve?

1. Look at the fails first and find the pattern, such as always too long or always makes things up. This is the same habit the pre-launch security checklist builds: read the report before you touch anything.
2. Change one thing at a time, such as the instructions, the examples you give, or the model.
3. Re-run the whole eval after each change, not just the failing cases, so you catch anything you broke.
4. Keep a simple log of the date, what you changed, and the pass rate before and after.
5. Add a new test case every time a real user finds a failure.
6. Re-run before every launch or model change, alongside the pre-launch security checklist.

What should you do the week after launch?

Passing the pre-launch security checklist is not the finish line, so give yourself a short routine for the first week. It takes about ten minutes a day.

1. Check your logs for failed logins and server errors, and look for anything repeating.
2. Watch your API spend, because a bot hitting an unprotected route shows up as a bill before it shows up as an alert.
3. Re-run the pre-launch security checklist after any change your agent makes to auth, the database, or an API route.
4. Restore one backup into a test environment, so you know the restore actually works.
5. Add a new eval case for every strange answer a real user reports.

Frequently asked questions

What should I check before launching an app built with AI?

Check 16 things, grouped into five batches. Data layer: row level security, SQL injection, exposed admin keys. Browser and login: XSS, secrets, authentication. Abuse and traffic: CSRF, rate limiting, CORS. Hygiene: HTTPS, dependencies, file uploads, error messages. Safety net: logging and monitoring, backups, security headers.

Do I need to know code to run this pre-launch security checklist?

No. Your coding agent runs the checks and reports pass, fail, or not applicable, with one plain-English line of explanation and a fix for anything that fails. Your job is to read the report and decide what to fix.

How long does the pre-launch security checklist take?

The audit itself takes a few minutes, because it is one prompt. Fixing the fails usually takes an afternoon for a small app, since each of the five batches is a short round of changes followed by one re-run of the audit.

Should I let the agent fix problems straight away?

No. Ask for a report only, read it first, then fix the fails one batch at a time. That keeps each change small enough for you to review.

How often should I re-run the pre-launch security checklist?

Re-run it after fixing, and keep going until every item passes or is not applicable. After launch, re-run it whenever your agent touches authentication, the database, or an API route. Evals follow a similar rhythm: re-run them before every launch or model change.

What is the difference between a security audit and an AI eval?

A pre-launch security checklist checks that your app is locked down against attackers and leaks. An eval checks that an AI feature inside your app behaves well, meaning it stays accurate, on-brand, short, and safe. You need both, and they run on different schedules.

How many test cases do I need to start an eval?

Start with 10 to 20. Include normal cases, tricky ones, edge cases, and a few that try to break the feature. Add a new case every time a real user finds a failure.

What passing score should I set for an eval?

Set the bar before you run anything. A sample bar is that at least 90 percent of cases must pass, with zero safety fails.

Does this pre-launch security checklist follow OWASP?

This pre-launch security checklist maps to OWASP rather than replacing it. Fourteen of the 16 checks line up with a category in the OWASP Top 10:2025, and the table above shows which. Backups and tested restores sit outside the Top 10, but they belong on any launch list.

Does passing this pre-launch security checklist mean my app is fully secure?

No checklist can promise that. This one covers the everyday basics that many hacks slip through. If your app handles payments or highly sensitive data, consider a professional security review as well.

About the author

Vinita Mathreja is a Mumbai-based marketer and publisher who builds apps with AI coding agents and writes about it at WhatTheWeb. She wrote this pre-launch security checklist after shipping 30+ projects with Claude Code, Cursor and Figma Make, from iOS apps to WebGL sites, without reading code. You can find her on LinkedIn or read how she uses Claude Code as a non-coder.