We Reviewed AI-Generated Apps. Here Are the 10 Security Mistakes We Keep Seeing

AI-generated apps are shipping faster than ever. They’re also shipping with serious security flaws.

Recent analyses of AI-generated applications turned up hundreds of exploitable vulnerabilities—authorization problems, denial-of-service paths, and exposed secrets among them. That matches what we see when founders paste a Cursor or ChatGPT scaffold into production: the UI looks done, the auth model isn’t.

This isn’t an argument against AI coding tools. It’s an argument against treating generated code as production-ready by default.

Why AI-Generated Apps Fail Differently

Models optimize for “works in the demo.” They rarely optimize for:

- Threat models

- Least privilege

- Abuse cases

- Secrets hygiene

- Operational limits

So you get apps that pass a happy-path click-through and fail a basic security review. Below are the 10 mistakes we keep seeing.

1. Authorization That Only Checks “Logged In”

The app verifies a session exists—then returns any user’s data if you change an ID in the URL.

Fix: Enforce object-level authorization on every read/write. `userId` from the token, not from the client body. Test with two accounts trying to access each other’s resources.

2. Secrets in the Frontend (or in the Repo)

API keys for OpenAI, Stripe, Supabase service roles, or AWS land in `NEXT_PUBLIC_*`, client bundles, or committed `.env` files.

Fix: Server-only secrets. Backend proxy for third-party APIs. Rotate anything that ever touched git history. See our notes on API keys in the frontend.

3. No Rate Limiting on Expensive Paths

Signup, password reset, AI generation, and search endpoints accept unlimited requests. Attackers don’t need a zero-day—they need a loop.

Fix: Per-IP and per-user limits at the edge and in the app. Stricter caps on AI and auth endpoints. Alert on spikes.

4. Over-Privileged Database and Service Roles

Generated backends often use a single admin connection or a Supabase service key for everything the client touches.

Fix: Separate roles for anonymous, authenticated, and admin. Enable RLS (or equivalent) and verify policies with a hostile client.

5. Missing Input Validation on AI and Form Paths

Prompts, file uploads, and JSON bodies are forwarded to models or databases with little validation—opening injection, abuse, and cost amplification.

Fix: Schema validation, size limits, content-type checks, and never concatenate untrusted input into SQL/shell/prompt templates that grant tools.

6. Debug Mode and Verbose Errors in Production

Stack traces, SQL errors, and internal hostnames leak through API responses—gold for attackers mapping your stack.

Fix: Generic client errors; structured logs server-side. Disable debug flags in prod builds and runtime config.

7. CORS, CSRF, and Cookie Misconfiguration

“Make it work” CORS becomes `Access-Control-Allow-Origin: *` with credentials. Session cookies miss `HttpOnly` / `Secure` / `SameSite`.

Fix: Explicit origins. Cookie flags locked down. CSRF protections for cookie-based sessions.

8. Dependency and Scaffold Defaults Left Untouched

Example apps ship with default passwords, open admin routes, sample webhooks without signatures, and outdated packages with known CVEs.

Fix: Treat scaffolds as untrusted. Patch dependencies in CI. Remove demo routes before DNS goes live.

9. No Abuse or Cost Guardrails on Model Calls

Every user action can trigger a paid model. Without quotas, one script becomes a five-figure bill.

Fix: Per-user budgets, hard caps, queueing, and billing alerts. Cost is a security control for AI products—see cost guardrails.

10. No Logging, Alerts, or Incident Path

When something breaks—or gets abused—there’s no trail, no on-call, and no runbook. Generated apps often skip observability entirely.

Fix: Structured logs, auth/audit events, error budgets, and a basic incident response path before launch.

What “Reviewed” Should Mean Before You Ship

Before you call an AI-generated app production-ready, run a hostile pass:

1. Two-user authorization tests

2. Secret scan of repo + client bundle

3. Rate-limit proof on login and AI routes

4. RLS / IAM review for least privilege

5. Dependency audit + remove demo surfaces

6. Cost caps and billing alerts

7. Logging + one kill switch for keys/tools

If you can’t check those boxes, you don’t have a product—you have a prototype with a public URL.

Closing

AI coding tools are leverage. Unreviewed leverage is risk. The teams that win will generate fast and verify hard—authorization, secrets, limits, and observability included.

Next step: Run your AI Production Readiness Assessment—a quick score on whether your app is ready for real users, real attackers, and real bills.