The most common security mistakes in AI-built apps

The most common security mistakes in AI-built apps are secrets shipped in the browser bundle, databases left publicly readable, missing or broken authentication, exposed file storage, and insecure framework defaults left untouched. These show up because AI coding tools optimise for "it works on the screen," not "it holds up when a stranger opens the network tab." If you have built an app with an AI assistant and pushed it live, those five categories are where you should look first.

None of this is the AI being malicious. It is the AI doing exactly what you asked, make the feature work, without anyone in the loop asking the boring question: who else can reach this. A practitioner reviewing AI-built code in India sees the same handful of security mistakes in AI-built apps over and over. Let's go through them with the specifics that actually matter.

1. Secrets shipped in the client bundle

This is the most frequent one, and the most expensive. You ask the assistant to "connect to the payments API" or "call OpenAI from the app," and it writes the call directly in your React or Next.js component with the API key sitting right there as a string or an environment variable prefixed with something public.

The catch with front-end frameworks: any environment variable prefixed for the client (VITE_, NEXT_PUBLIC_, REACT_APP_) is compiled straight into the JavaScript that every visitor downloads. It is not hidden. Anyone can open browser dev tools, search the bundle, and read it. A Razorpay secret, a Cashfree client secret, an OpenAI key, a Resend key, all of them have been found this way.

The fix is structural, not cosmetic. Secret keys belong on the server: a Worker, an edge function, or a backend route that holds the key while the browser only ever talks to your endpoint. The client should never see anything beyond a publishable key that is designed to be public. If you find a secret in your bundle, rotate it immediately, assume it is already compromised, then move the call server-side.

2. Databases left publicly readable

AI tools love managed backend platforms because they get you to a working app in an afternoon. The trap is that both ship with permissive defaults during development, and the assistant rarely tightens them before you go live.

The killer is a database table with row-level security disabled, or RLS enabled but with a policy that effectively says "allow all." Combine that with the anon key (which is public by design and sits in your client) and anyone can query your entire table from the browser console. Customer names, phone numbers, addresses, order history, all readable. Firebase has the equivalent in rules that read allow read, write: if true.

What to check: confirm RLS is on for every table holding real data, and that each policy actually scopes rows to the authenticated user, typically auth.uid() = user_id, not a blanket allow. Test it the way an attacker would: open your live site, grab the anon key from the network tab, and try to select a table you should not be able to see. If rows come back, you have a problem.

3. Missing or broken authentication

There are two failure modes here. The first is no auth at all on something that needed it: an admin dashboard reachable by URL, a delete endpoint with no check on who is calling it, an internal report page that loads for anyone.

The second is more subtle and far more common in AI-built apps: authentication that exists on the front end only. The login screen looks correct, the UI hides the admin button from normal users, and everyone assumes it is secure. But the API behind it never checks the token. An attacker does not use your UI. They call your endpoint directly with a tool like curl or Postman, and since nothing on the server verifies who they are or what they are allowed to do, the request goes through.

The rule: every protected endpoint must verify the token and the permission on the server, on every request. Hiding a button is a UX choice, not a security control. If your app uses Bearer JWTs, the server should validate the signature and check the user's role before doing anything sensitive, not trust a flag the client sent.

4. Exposed file storage

The moment your app handles uploads, whether KYC documents, profile photos, invoices, or signed contracts, storage becomes a target. AI assistants commonly wire up a public storage bucket because it is the path of least resistance: the upload works, the image renders, everyone moves on.

The problem is that "public bucket" often means publicly listable or guessable. If files are stored at predictable paths and the bucket allows listing, someone can enumerate every document you hold. For an Indian business handling PAN cards, Aadhaar copies, or GST documents, that is not just embarrassing; it is a data-protection liability under the DPDP framework.

Fix it by making buckets private and serving files through signed, time-limited URLs that your server generates only for users who are allowed to see that specific file. Never rely on an unguessable filename as your only defence; obscurity is not access control.

5. Framework defaults left untouched

The quiet category. AI scaffolds an app and leaves a trail of defaults that are fine for a demo and wrong for production:

• CORS set to *, so any website can call your API from a victim's browser session.
• Verbose error responses that leak stack traces, file paths, and database structure to anyone who triggers an error.
• Debug mode on in production.
• Default or sample credentials left in config because the boilerplate had them.
• No rate limiting, so a login endpoint can be brute-forced or your paid API metered into a large bill.
• Dependencies pulled in months ago with known vulnerabilities and never updated.

Each one is small. Together they are the difference between a hobby project and something you can put a customer's data into.

How to actually check your app

You do not need to be a security engineer to catch most of this. A practical first pass:

1. Open your live site, open browser dev tools, and search the loaded JavaScript for words like key, secret, token, and password. Anything that looks like a real credential should not be there.
2. Grab the public/anon key and try to read a sensitive table or list a storage bucket directly. If it works, your access rules are open.
3. Hit your protected API endpoints with no token, using curl or Postman. If they respond with real data, your auth is front-end only.
4. Trigger an error and read the response. If it shows a stack trace or database details, tighten your error handling.

If doing that by hand feels like a lot, an automated scanner can do the first sweep for you. vybckr checks public web apps for exactly these issues: secrets exposed in the bundle, openly readable databases, broken auth, and exposed storage. It is a fast way to find out whether your AI-built app has the obvious holes before someone else does.

AI coding tools are genuinely good at getting you to a working product. They are just not the ones who get the call when customer data leaks. Treat security as a deliberate review step after the build, not a thing you hope the assistant handled. Run the checks above, point a scanner at your live URL, and fix what comes back before you tell customers it is safe.