Your AI App's Security Is Probably Broken: A Checklist for Founders

45% of AI-generated code has security vulnerabilities. This 25-point checklist tells you exactly what to check before real users touch your vibe-coded app.

A practical security checklist for founders who've built with AI coding tools. 25 checks across authentication, data protection, API security, infrastructure, and business logic — with explanations of why each matters.

I've audited dozens of vibe-coded apps headed for production launch. Every single one had security vulnerabilities the founder didn't know about. Not edge cases. Fundamental flaws that would have exposed user data, allowed unauthorised access, or enabled payment fraud.

The founders weren't careless. They'd built impressive products with AI tools — polished UIs, working features, demo-ready flows. But AI coding tools don't generate secure code by default. Veracode's 2025 research found that 45% of AI-generated code contains security vulnerabilities. Tenzai's assessment of five major AI coding tools found 69 vulnerabilities across just 15 applications, with several rated critical.

This checklist covers the 25 security checks I run on every AI-generated codebase before it touches real users. It's organised into five categories: authentication, data protection, API security, infrastructure, and business logic.

Print it. Work through it. Every item you check off makes your app meaningfully more secure.

Category 1: Authentication and Access Control

Authentication is where AI tools fail most visibly. They generate login flows that look professional but crumble under scrutiny.

1. All authentication happens server-side. Check that login validation, session creation, and token verification happen on your server, not in browser JavaScript. If you can find auth logic in your frontend code, it can be bypassed.

2. Passwords are properly hashed. Check your user table. If you can read the passwords, they're stored in plain text — the most serious auth failure possible. Passwords must be hashed with bcrypt, argon2, or scrypt. AI tools sometimes store passwords as base64 encoding, which looks encrypted but isn't.

3. Session tokens expire. Check that JWT tokens or session cookies have an expiration time. AI-generated auth often creates tokens that never expire — meaning a stolen token grants permanent access.

4. Password reset tokens are single-use and time-limited. Request a password reset. Use the link. Then try using it again. If it works a second time, the token isn't being invalidated. Also check that tokens expire after a reasonable time (15-60 minutes).

5. Login doesn't reveal whether accounts exist. Try logging in with a valid email and wrong password, then an invalid email. If the error messages are different ("wrong password" vs "account not found"), an attacker can enumerate which email addresses have accounts. Both should return the same generic error.

6. Rate limiting on login attempts. Try logging in with the wrong password 50 times rapidly. If every attempt succeeds without delay or lockout, there's no brute force protection. An attacker can try thousands of passwords per minute.

7. Role-based access control is server-enforced. If your app has admin and regular user roles, check where the role check happens. Navigate directly to admin URLs as a regular user. Call admin API endpoints with a regular user's token. If either works, access control is broken.

Category 2: Data Protection

Data protection failures are the ones that make headlines and trigger regulatory fines.

8. No sensitive data in client-side code. Open your browser's developer tools, go to the Network tab, and look at API responses. Check for data that shouldn't be there: other users' email addresses, internal IDs, admin flags, or data from other accounts. AI tools often return entire database records when the frontend only needs two fields.

9. Database queries are parameterised. Search your codebase for any place where user input is concatenated into a database query string. This is SQL injection — the most well-known and exploitable vulnerability in web applications. Every database query should use parameterised queries or an ORM.

10. File uploads are validated. If your app accepts file uploads, try uploading a .html file or a .php file. If the server accepts and serves them, an attacker can upload malicious code that executes on your server. Validate file types, limit file sizes, and never serve uploaded files directly.

11. Personal data isn't logged. Check your logging. AI-generated code often logs entire request bodies, which means passwords, email addresses, and payment details end up in log files. Log only what you need for debugging, and never log credentials or payment information.

12. Data isolation in multi-tenant apps. If your app serves multiple businesses or teams, log in as User A and try accessing User B's data by modifying IDs in API requests. If you can see or modify another tenant's data, you have broken access control — the single most critical failure in SaaS applications.

13. HTTPS everywhere. Check that your app forces HTTPS on every page. Try accessing it via http:// — it should redirect to https://. Without HTTPS, all data between the user and your server (including passwords and payment details) is transmitted in plain text.

Category 3: API Security

APIs are the backbone of modern web apps, and AI-generated APIs are consistently under-protected.

14. Every API endpoint requires authentication. List every API endpoint in your app. Call each one without an authentication token. Any endpoint that returns data without auth is publicly accessible — meaning anyone on the internet can access it.

15. Input validation on every endpoint. Send unexpected data to your API endpoints: empty strings, extremely long strings, negative numbers, special characters, HTML tags, SQL fragments. If any of these cause errors, unexpected behaviour, or are reflected back in responses, you have input validation gaps.

16. CORS is properly configured. Check your CORS (Cross-Origin Resource Sharing) settings. AI tools often set Access-Control-Allow-Origin: * which allows any website to make requests to your API. This should be restricted to your own domain(s).

17. Rate limiting on API endpoints. Send 1,000 requests to an API endpoint in rapid succession. If all succeed without throttling, your API has no rate limiting — meaning an attacker can overwhelm your server or scrape all your data.

18. No sensitive data in URLs. Check that API keys, tokens, and personal data aren't passed as URL parameters. URLs are logged by web servers, proxies, and browsers. Sensitive data should be in request headers or request bodies, never in URLs.

Category 4: Infrastructure and Secrets

Infrastructure security is invisible until it fails — and AI tools almost never get it right.

19. No hardcoded secrets in code. Search your entire codebase for strings that look like API keys, database passwords, or encryption secrets. Common patterns: sk_live_, sk_test_, AKIA (AWS keys), long random strings assigned to variables named secret, key, password, or token. Every one of these should be an environment variable.

20. Secrets are not in version control. Check your Git history: git log --all -p | grep -i "api_key\\|secret\\|password\\|token". Even if you've removed secrets from the current code, they may still be in your commit history — and that history is accessible to anyone with repository access.

21. Error messages don't expose internals. Trigger an error in production (submit an invalid form, request a non-existent resource). Check what the user sees. If it includes stack traces, database query text, file paths, or technology versions, you're leaking information that helps attackers understand your system.

22. Database backups exist and are tested. Check that your database is backed up automatically. Then verify you can actually restore from a backup — untested backups are as useful as no backups. If your hosting provider doesn't include automated backups, set them up manually.

23. Dependencies are up to date. Run npm audit (Node.js) or pip-audit (Python) on your project. AI tools often install specific package versions that have known vulnerabilities. Update dependencies with known security issues before launching.

Category 5: Business Logic

Business logic vulnerabilities are the hardest to detect because they're specific to your application. These are the flaws that Tenzai's research found AI tools are most prone to creating.

24. Payment logic is server-side and webhook-driven. Check how your app grants access after payment. If it happens in the browser after the user clicks "Pay" (before Stripe confirms the payment), users can get free access by intercepting the request. Access should only be granted after a Stripe webhook confirms payment succeeded. Check that webhook signatures are verified.

25. Business rules can't be bypassed from the browser. Open your browser console and check what's stored in localStorage, sessionStorage, and JavaScript variables. Look for values like isPaid: true, role: "admin", plan: "pro". If changing these values changes the app's behaviour, your business logic is client-side and can be bypassed by any user.

How to Use This Checklist

Work through it in order. The first category (authentication) contains the highest-risk items — if authentication is broken, nothing else matters.

For each item, the outcome is binary: it passes or it doesn't. There's no "partially secure." If a security check happens client-side, it's broken. If secrets are in code, they're exposed. If an endpoint lacks authentication, it's public.

Keep a tally. In my experience auditing vibe-coded apps, the average score on first review is 10-12 out of 25. Apps built with Cursor tend to score slightly higher than Replit or Bolt apps, but none consistently pass all 25 checks without human intervention.

If you score 20-25: Your app has solid security foundations. Review the failures, fix them, and you're likely ready for real users.

If you score 12-19: You have meaningful security gaps that need addressing before launch. Most can be fixed in 1-2 weeks of focused work.

If you score below 12: Your app needs significant security work before it's safe for real users. A professional review is strongly recommended — the risk of launching with this many gaps outweighs the cost of fixing them.

The Items AI Tools Get Wrong Most Often

Across every audit I've done, five items fail most consistently.

Client-side security logic (items 1, 7, 24, 25). This is the universal failure. AI tools put logic where it's easiest to generate — in the frontend — rather than where it's secure — on the server. Every app I've audited has had at least one security check that lives in the browser.

Hardcoded secrets (items 19, 20). AI tools inline API keys and database credentials because that's the simplest working code. Most founders don't realise these are visible to users or persisted in version control history.

Missing rate limiting (items 6, 17). AI tools almost never add rate limiting because it's not required for the code to function. It's only required for the code to survive real-world usage.

Overly permissive CORS (item 16). The wildcard * CORS setting is AI's default because it eliminates cross-origin errors during development. In production, it means any website can make authenticated requests to your API.

Missing input validation (item 15). AI generates code that handles expected input. Production receives unexpected input — constantly. Missing validation is the gateway to injection attacks, data corruption, and application crashes.

What Happens If You Skip This

In May 2025, the AI coding platform Lovable was found to have personal data exposed in 170 out of 1,645 applications — roughly 1 in 10 apps was leaking user information to anyone who knew where to look.

A startup called Enrichlead put all security logic client-side. Users bypassed the paywall within 72 hours by changing a browser variable. The project shut down.

An AI coding agent on Replit deleted an entire production database despite explicit instructions not to modify production systems.

These aren't hypotheticals. They're documented incidents from 2025-2026. The vibe coding security landscape is getting worse, not better, as adoption accelerates and more non-technical builders launch AI-generated code to production.

Frequently Asked Questions

Can I automate this checklist?

Partially. Static analysis tools (Semgrep, ESLint security plugins, npm audit) can catch items 9, 19, 20, and 23 automatically. But business logic vulnerabilities (items 24-25), client-side security (items 1, 7), and data isolation (item 12) require manual testing. Automated scanning catches roughly 40% of the issues; human review catches the other 60%.

My app doesn't handle payments. Do I still need all 25 checks?

Skip items 24 and the payment-specific parts of 25. Everything else applies to any app that handles user data. Even a simple app with user accounts needs proper authentication, data protection, and API security.

How often should I run this checklist?

Before every major deployment, and whenever you add a new feature with AI coding tools. AI tools can introduce new vulnerabilities with every generation. A feature that was secure in version 1 might become insecure after the AI modifies it in version 2.

What if I can't fix an item myself?

Prioritise by risk. Items in Category 1 (authentication) and the client-side security items are the highest risk — fix these first or get help. Items in Category 4 (infrastructure) are the easiest to fix without deep development experience. For anything you can't resolve, a Discovery Sprint provides a professional assessment and action plan.

Is there a tool that makes AI code secure automatically?

Not yet. Products like Aikido and Snyk can scan for known vulnerability patterns, but they can't validate business logic, check access control, or verify that payment flows are correct. Security is ultimately about context — understanding what your specific app needs to protect and verifying that the protection is actually in place. That requires human judgment.

---

Related reading