The most common security flaws in AI-built applications are broken object-level authorisation, missing server-side validation, secrets exposed in client code, absent rate limiting, over-permissive database policies, unsafe file uploads, and prompt injection in any LLM feature. None are exotic. All appear because AI builders generate what was asked for, and nobody asked for a threat model.
Here is what each one looks like in a real build, and the specific check that tells you whether you have it.
1. Broken object-level authorisation
The single most common flaw. Your app authenticates users correctly, then fetches records by ID without checking whether the record belongs to the requester. Change the ID in the URL or the network request and you read someone else's data.
Check: log in as user A, capture a request that fetches one of A's records, replay it with B's session and A's record ID. If it returns data, you have the flaw. Fix with row-level security policies enforced at the database, not filters applied in the client.
2. Client-side-only validation
The form stops you entering a negative quantity. The API does not. Anyone can call the endpoint directly with any payload, because the only rule lives in the browser.
Check: send a request straight to your API with values your UI would reject. Fix by validating on the server for every mutation — types, ranges, ownership, and state transitions.
3. Secrets in client code
Service keys, admin tokens and third-party API keys pasted into frontend code during a build session. They are visible to anyone who opens the network tab, and search engines index them from public repositories.
Check: search your bundle for anything resembling a key. Fix by moving every privileged call behind a server function and rotating anything that was ever exposed — rotation matters, because assume-compromised is the only safe stance.
4. No rate limiting or abuse controls
Public endpoints — signup, password reset, contact forms, and especially anything that calls a paid AI model — with no throttle. The consequences range from spam to a five-figure model bill generated overnight by a script.
Check: hit an endpoint a hundred times in ten seconds and see what happens. Fix with per-IP and per-account limits, plus a hard spend cap on any AI provider.
5. Over-permissive database policies
Row-level security is enabled, but the policy reads `true` — added during a build session to unblock an error and never tightened. Enabled RLS with a permissive policy is functionally the same as no RLS, and it looks safe on a dashboard.
Check: read every policy on every table and ask who it lets in. Fix by scoping each to the authenticated user and granting only the privileges the app actually uses.
6. Unsafe file uploads and public storage
Buckets set to public so that images would display, with no file type restriction, no size cap and predictable file paths. Customer documents end up publicly readable by anyone who guesses a URL.
Check: take an upload URL, log out, and open it. Fix with private buckets, signed URLs, MIME validation and size limits.
7. Prompt injection and data leakage in AI features
The risk unique to AI products. If your app passes user content into a model that has access to tools, other users' data, or your system prompt, then user content is untrusted input that can redirect the model's behaviour.
Concretely: never grant a model direct database credentials; scope every tool it can call; never place secrets in a system prompt; treat retrieved documents as untrusted; and filter model output before rendering it as HTML. Also decide, and publish, whether customer data is sent to third-party providers and whether it is retained for training — enterprise buyers will ask, and the answer belongs in your privacy policy.
The one-hour audit
You can run a meaningful pass in an hour: replay one user's request with another user's session; call one API endpoint with invalid data; search the bundle for keys; read every database policy; try one upload URL while logged out; hammer one endpoint; and check whether you have a spend cap on your AI provider.
Seven checks. In most AI-built apps, at least three will fail. That result is normal — the failure is leaving them unfixed while onboarding paying customers.
Where to go next
Security is one gate in a larger sequence — see the AI MVP production readiness checklist for the rest, and why your Lovable app is not ready for customers for the commercial context.
Frequently asked questions
- Are AI-generated apps secure?
- They are as secure as the requirements they were built against. Because founders prompt for features rather than controls, AI-generated apps typically ship without authorisation checks, server-side validation, rate limits or spend caps, all of which must be added deliberately.
- What is the most common security flaw in AI-built applications?
- Broken object-level authorisation — fetching a record by ID without verifying it belongs to the requesting user. It lets one customer read another customer's data by changing an identifier.
- What is prompt injection and does it affect my product?
- Prompt injection is untrusted user or document content that changes a model's behaviour. It affects any product that feeds user content into a model with tools, data access or a confidential system prompt.
- How do I stop an AI feature generating a huge bill?
- Apply per-user and per-IP rate limits, cap tokens per request, and set a hard monthly spend cap with the provider. Without a cap, a single script can turn an unthrottled endpoint into a five-figure invoice overnight.
- Do I need a penetration test before launch?
- Not usually at pre-seed. A structured self-audit covering authorisation, validation, secrets, policies, uploads and rate limits catches most real risk. A formal test becomes worthwhile when enterprise buyers or regulated data are involved.