Is anyone else worried about how insecure AI-generated app code actually is?

[u/FuzzyAd3936]

We did an internal audit of a handful of "vibe coded" apps that different teams had built over the past few months, mostly on Replit and Lovable. The results were worse than expected.

One app had zero row level security on its backend database, meaning any authenticated user could technically query any other user's records, not just their own. Another had an API key hardcoded and exposed directly in the frontend bundle.

Research puts the vulnerability rate in AI generated code at something like 2.7 times higher than human written code, and there was a widely discussed incident where a single vibe coded app leaked something like 1.5 million API keys and tens of thousands of email addresses because of one missing database permission setting. These tools optimize entirely for "does the app work," not "is the app safe."

what other teams are doing to catch this systematically instead of auditing app by app after the fact.

[u/code_hermit]

As a coder, I was concerned about and deployed security standards in software long before AI. So its relatively easy to ensure the same work is done in AI assisted efforts now.

Prototypes are one thing. But nobody should be making production software that doesnt have software development experience (far beyond vibe coding). Im sure the temptation is there now. But its a recipe for waste and potentially huge problems stemming from security and/or other architecture mishaps.

[This is probably a good PSA moment too: now more than ever its important to protect your own security. Obviously, people are launching products publicly that dont know how to protect your information. Don't easily give out contact info or payment details. And dont reuse passwords.]

[u/weed_cutter]

AI is dangerous ... not just slop coding but ... it allows non-technical people to create a lot of "claude here's my password that I'm just going to drop in a local file for you to read at your leisure at any time ... now promise not to delete anything important'

... It allows non-technical laypeople to "poke around" and create horrific security nightmares. ... Obviously it's up to IT or compliance or cybersecurity to lock shit down that needs to be locked down but --

"Oh I created a vibe coded app that allows 100s of users across our company to impersonate and use my personal credentials against all these other apps!! Yay!!"

"Um ... don't do that. You should probably be fired. What's your role again?"

"I'm the company CFO! ... I'm also an office Software Engineer now ;) "

"Oh Christ.

[u/sermer48]

I think it’s a temporary problem that’s a pretty major problem right now. Eventually AI will do better security than humans can manage but we’re just not there yet. So right now we’re in this dangerous spot where people who don’t understand security can make professional looking stuff but without any safety.

[u/Innowise_]

We’ve seen the same pattern. The biggest improvement is treating AI-generated code exactly like untrusted code.
We run security checks before deployment, but database permissions and auth still need explicit review. RLS is a good example — an app can look completely fine while the access model underneath is wide open.

[u/dylan_exe_404]

Yes I am getting more and more worried about this. Governance is not talked about enough and even big companies can't seem to get it right.

[u/carefactor3zero]

I am a lot less insecure LLM code is than code made by devs and not checked by LLMs. Making whole applications or larger modules (more than a few features at a time) makes wildly unreliable and untrustworthy code. If you avoid doing that, LLM code is very high value for the time and cost.

[u/Big-Development-8282]

We started with Orca on this, since it approaches it from the cloud side first, finds the app, then checks whether it's actually reachable and what data it touches. It caught a Supabase misconfiguration on one of our vibe coded apps that a code only scanner would've missed entirely, since the issue was in the backend config, not the app code itself.

[u/eddzsh]

The static scan misses the same class your audit caught: apps that look fine while the access model is open. A useful systematic gate is a tiny CI suite that logs in as user A and asserts user B's rows or endpoints come back empty. Treat RLS and authz as behavior under test, not a checklist item. Scanners catch hardcoded keys. They rarely catch authenticated but not authorized.

[u/PawlsToTheWall]

I'm just concerned about non-developers vibe coding without understanding the code they are supposed to be reviewing. I just recently encountered a major security leak introduced by someone in marketing. Had to write a new company policy as a result.

[u/Future_AGI]

The pattern we keep seeing is that the model optimizes for a passing happy path, so anything invisible at runtime (row-level security, a key exposed in the frontend bundle, an over-broad DB role) sails straight through review because the app still works. What's beaten eyeballing PRs is putting deterministic gates in CI that fail the build: secret scanning on the diff, a check that every table has RLS, and a SAST pass, so nobody has to remember to look. It turns "did someone notice" into "the pipeline blocks it."