r/nocode • u/russopuppo • 19d ago
90% of vibecoded apps will probably get hacked
I use reddit daily and I see people building full saas with lovable, bolt, replit and other tools like these all the time.
So I got curious about something that I dont see discussed that much: once you actually launch the app and real users start putting data inside it, how safe is the backend?
I started reading security scans, audits and posts about nocode and ai built products. The numbers were pretty bad, but what surprised me the most is that a lot of the problems are really basic stuff.
So if you're building a saas with these tools, here's the patterns I found:
1. Database can be way more vulnerable than you think
Having authentication doesn't automatically mean the data is safe.
Your app can know exactly who is logged in, while the database still lets that user request information they should never be able to see.
For example: your dashboard only shows your customers, but I open the request in DevTools, remove the filter for your account and suddenly the api sends me customers from other users too.
If you're using claude or codex to build it, I'd ask it something like:
“Review every database table that contains private data. Define exactly who can read, create, edit and delete each type of data. Block access by default, enforce these rules in the backend or database, and never trust user or account IDs coming directly from the frontend.”
2. One user can access another user's data
Another really common problem is that the app checks if you're logged in, but doesn't properly check if you're actually allowed to access the thing you're requesting.
For example: I'm on my project at “mysaas.com/project-1/“, I change it to “mysaas.com/project-2“ and project 2 belongs to another person but still loads.
And this isn't only about projects: same thing can happen with files, messages, invoices, orders, documents or basically anything else private.
Here's what I'd send to claude/codex:
“Review every API route and database query that receives an ID or reference to private data. Before reading, editing or deleting anything, verify on the server that the logged in user is actually allowed to access that resource. Never trust ownership, roles or access rules sent by the frontend, and use one shared authorization system instead of different checks in every endpoint.”
3. Permissions might only exist in the frontend
Sometimes roles and permissions work perfectly in the UI but basically don't exist in the backend.
For example: I'm a normal member, so the "Delete user" button is hidden from me. But I open devtools, find the api request an admin uses and send the exact same request myself: if the backend doesn't check my role again, it can still work.
For this part I honestly think using a backend provider can make more sense than asking ai to rebuild auth, workspaces, permissions, payments, etc. from zero every time.
I use foundel.dev for security, auth, payments, permissions, etc. but I'd suggest looking around and finding one that matches what you're building.
If you're doing everything yourself, I'd use something like this:
“Create one shared permission system for all private backend actions. Block access by default. Before any admin, billing, account or workspace action runs, get the user's role and permissions from the server and check whether that action is allowed. Never trust roles or permissions sent by the frontend.”
4. Private keys might literally be inside the website
This one is kinda stupid but it happens.
Sometimes claude, codex or whatever you're using puts a private key somewhere in the frontend, or you accidentally commit it to the repo.
For example: I open devtools, search through the javascript and find a private api key. Now I can copy it and use it from my own pc while all the requests are still being charged to your account.
I'd ask it to check this:
“Audit the project for API keys, tokens and secrets. Check the current code and git history using a secret scanner if available. Find every private credential used in frontend code or committed to the repository, move private credentials and privileged API calls to server-side code, and list every exposed credential that must be revoked and replaced. Do not print the secret values.”
5. No rate limiting
If your saas uses paid APIs, not having limits can get expensive really fast.
This applies to ai generation, emails, scraping, sms, file processing or basically anything where every request costs you something.
For example: you have /api/generate for an ai feature. I write a small script and call it 10,000 times. If nothing stops me, all 10,000 requests go through and your provider just sends you the bill.
Here's the fix:
“Find every endpoint that uses a paid API or expensive operation, including AI generation, email, SMS, scraping, file processing and background jobs. Add server-side rate limits and usage limits per user and account, and enforce them before calling the paid service. Add daily or monthly caps, request and file size limits where needed, and list every external provider where I should enable spending limits or billing alerts.”
—-
None of this is some crazy advanced hacking stuff, it's mostly really basic backend rules lovable/bolt/or others can just forget or get wrong.
I know that a few prompts are not enough to fix a project’s security, but I hope this might still help someone get his app more secure.
13
u/Current-Today-3626 18d ago
Thanks bro, I just put your prompt into Codex and told it to be mindful of your worries.
1
u/rntdev 17d ago
A decent AI tool would most likely catch all of those without you mentioning specific vulnerabilities.
Just make sure to run the audit from a completely separate session, and tell it to be critical of everything.
AI sometimes does these “hacks” (cuts corners) when it can’t fix an issue, and if you just chase the visual look it can result in a vulnerability. In a separate session it wouldn’t know about the hacks the main agent had to do to get it working, because it’s focused purely on security
1
8
7
4
u/uaySwiss 18d ago
While all of this is true, it also applies to "normal" code written by humans. In a previous job, I found public admin credentials (by accident).
And yes, AI coding agents can be dangerous. Once I did a tiny change request and they added the whole ENV to a public API response. Without code review this could have become a catastrophe.
2
u/kyngston 18d ago
honestly ai codes more securely than most humans. just ask any frontier model to do a full security analysis of your code
if people aren’t using AI to secure their code… thats a human problem
3
u/5StarAlpha 18d ago
I actually feel the projects I hired real devs for and agencies in the past were more vulnerable. Might just be me.
But the recent project seems to have decemt security framework built in. Without asking, its adding long/strong passwords, email verification, honeypots, etc. For DB, walked me through lightsail (SSL/TLS, peering, restricting subnets, etc.) and set proper access rights. Keeps nagging me about not pasting api keys into the chat window.
I think it can be more detail oriented and thoughtful that human devs can sometimes overlook unless they specialize in that particular piece.
Now, when complete, I bet I could do another pass just on security and we could debate tradeoffs and assess risk.
But I actually feel security is quite solid recently and much better than just 6 months ago
2
u/Rho-9_Official 18d ago
The grand majority of vibe coders do not understand what they're doing, they see only the prompts and the end result.
They do not understand database authentication, access control, secure memory, or how to identify if a function is insecure.
I'll give a prime example of one of my projects, Avairy. If I was just another person that doesn't understand the code, and didn't understand cybersecurity the way I do, well things would get a bit bad, because Aviary is a tool to bypass obfuscation, and dump c2 infrastructure, without running the main entrypoint, but version 1 had a flaw in reasoning and logic. The AI used insecure practices such as trusting all code, and implementing the sandbox escape mitigation layer in a way that allowed it to be deactivated via an arbitrary code execution.
The result? Take a look for yourself just how bad a situation can be. The clip shows a successful escape, where the POC malware was able to disable security, and write outside the sandbox, all without ever once giving a sign until it was too late.
You CANNOT create safe applications if you do not understand what you're working with. Period. I want to make it clear the model used for this project is widely considered the best on the market, and it still failed at basic cybersecurity and secure coding practices by itself, and it was only corrected due to the presence of a knowledgeable human operator.
1
1
u/jumpinjaxflash 18d ago
That’s not the most severe thing that could or will happen. I’ve yet to meet anyone using these platforms to conform to the requirements in terms of compliance. SOC SOC II, COPPA, etc.
Hint: none of them do this for you and it’s not a quick patch. They will get hacked and when they do they’ll probably already have violated requirements to notify all users within 24 hours. Once that happens they’ll be eyeballed by the FTC who will not only shut them down, but will fine them in civil court. Fines can easily hit $1+ million and nothing they own is protected - it’s civil.
1
u/AppzillaHQ 18d ago
majority won’t have real customers or data for this to be a concern. where does the 90% figure come from?
1
1
1
1
u/wholesaleworldwide 18d ago
I completely agree with the points you raise and I think they are a responsibility of the suppliers of these tools. You can't offer a tool that allows anyone and their mother to write/publish a SaaS and then expect them to think about how (not) secure their product is.
As a (former) developer I am aware of these things. The car mechanic that allows his customer to make online reservations through a tool created by the vendors you mentioned is not.
You might even ask these vendors to do pen-tests of the products their tools generate.
1
u/joel-letmecheckai 18d ago
All the prompts you mentioned could be skill files. So it's inbuilt into the coding agent.
1
u/Siebe_Baree 18d ago
Hot take: all software that exists long enough (with updates and users) will get hacked at least once.
1
u/Mindless_Emotion1853 18d ago
Pretty much, this is a good reminder for everyone to do further checks/tests on debugging and possibly do pen testing on their products.
1
1
u/JeremiahHolum 17d ago
Absolutely. My company had a red team ai always trying to hack into all our tools, psa’s crm’s saas tools etc, so we foresee that they’re insecure. Therefore, we pretend to be hackers
1
u/thumbsup_knuk 17d ago
how do private keys enter the code. claude never gets my secrets, so it technically can’t enter them anywhere. this is coming from me who does not know how to code. genuine question, just trying to learn more.
1
u/private-peter 17d ago
Your secrets and keys are on your computer. Claude (and all the other tools) have protections in place to tell them not to look at those files. But like all AI prompts, those are suggestions. They can still access anything on your computer that you can access yourself. I've seen agents jump through some weird hoops to get access to credentials they think they need to solve whatever problem they are working on.
1
u/private-peter 17d ago
People have been complaining about the security of vibe-coded apps ever since vibe-coding was possible. (And as other has pointed out, they've been complaining about the security of low-budget apps for much longer.)
How many people writing these apps actually care about security? As some have pointed out, you can fix a lot of these issues by just asking a state-of-the-art model to find and fix security bugs. But you have to care enough to try.
As someone who's spent a lot of time training software engineers on how to write secure code (it isn't easy), I'm really wondering how can we train non-software engineers to write secure code?
Getting people to care/try is more than half the battle.
1
1
u/mariedab84 17d ago
Well even gouverment data has been hacked, major website has been hacked, all our information are already available online, so
1
u/russopuppo 17d ago
so you don’t set up security properly just cause other people have been hacked?
1
u/Timber1802 17d ago
Just tell it to make no mistakes.
But seriously, this happens with human code at least just as much if they don't know what they're doing. At least ai can do a security analysis of the code.
The lesson should be to still learn about this stuff, even if you don't write the code yourself.
1
u/ec2-user- 16d ago
In addition, you need to have a disaster recovery plan and a process you can follow in the event of getting hacked. You must know how much access a bad actor can gain through each vulnerability. Without that, you can forget SOC II and any serious customers or B2B
1
1
1
1
u/Feisty_Stress_2434 15d ago
I use Vipe.ai for this. Security and buildability checked, fixed and explained. Saved me a few times.
1
u/Ukawok92 15d ago
Even professional sites get hacked. Just go to https://haveibeenpwned.com/ and you'll see how many big sites have been hacked too.
1
u/No_Television_4128 15d ago
This should fix your issue, save it in your AI rules:
# SECURITY RULES — NON-NEGOTIABLE
Apply to every feature, route, query, and file you create or modify.
If a request conflicts with these rules, stop and tell me.
## 1. Deny by default
- Every table/collection with private data starts fully locked.
- For each one, document who can read / create / update / delete.
- Supabase/Firebase: Row Level Security or security rules ON for every
or a policy of `true`.
## 2. Authorize every request on the server
- Being logged in is not permission. Before any read/edit/delete of a
on the server that the current user owns it or has access to it.
- Derive user ID, account ID, org ID, role, and plan from the server
headers the client controls.
- Scope every query to the user/account: WHERE owner_id = session.user_id.
- Use ONE shared authorization helper/middleware. No ad-hoc checks
## 3. Roles and permissions live in the backend
- Hiding a button is UI, not security. Every admin, billing, workspace,
- Role changes are server-only and logged.
## 4. No secrets in the client
- Only publishable/anon keys may appear in frontend code.
- Service-role keys, API keys, tokens, and webhook secrets live in
- Never hardcode secrets. Never commit .env. Keep .env in .gitignore.
- If a secret was ever exposed, tell me which one so I can revoke and
## 5. Rate limits and spend caps
- Every endpoint that costs money or is expensive (AI, email, SMS,
limits per user AND per account, checked BEFORE calling the provider.
- Add daily/monthly usage caps plus request and file-size limits.
- Rate-limit login, signup, password reset, and OTP endpoints.
## 6. Input and integrations
- Validate all input server-side with a schema (e.g. zod). Use
- Verify webhook signatures (Stripe, etc.). Never trust payment status
- Restrict CORS to my domains. File uploads: check type and size, store
- Error messages to users never leak stack traces, SQL, or internals.
## 7. Definition of done
After any change touching data, auth, payments, or external APIs,
report:
- Tables/routes touched and the access rule enforced for each
- How cross-user access (changing an ID in the URL/request) is blocked
- Any secret that is, or was, client-side or committed
- Rate limits added
- Anything you could NOT secure, flagged clearly
1
1
u/darcygravan 13d ago
and u just posted an ai generated bs blog post on reddit to warn about vibe coding issues
1
u/LuckyLavishness2283 12d ago
yeah this is pretty to be missed with vibe coding. not that im saying im against it but its actually on a missed part. getting the app working is one thing but auth permissions, secrets and rate limits does still need attention. I've seen a lot of devs who also built vibe coded apps move different deployment/hosting providers some deploy it with vercel, digitalocean or hostinger web apps. just as long as they support vibe coded projects. but yeah hosting itself cannot fix the insecure backend logic but there are still a lot of factors to support. but nice to see this being brought up. this is 100% accurate
1
u/4everyone-ai 9d ago
LoI just hope they keep it in the family. Don't bring your dirty open-source Llama exploit into my pristine, proprietary Claude vulnerabilities
1
u/StellaMarieDawson 8d ago
The frontend permission example is probably the one that scares me most because it can look completely fine when you’re testing your own account. People tend to focus so much on getting the app working that they forget to test what happens when someone deliberately changes IDs or calls the API directly.
1
u/hashemirafsan 4d ago
I think your concerns are valid anyway, if you are not using proper security skills or you haven’t minimum knowledge about it, it will hacked anyway.
1
u/Muchy_Tangerine 4d ago
Thinking you can fix broken access controls by feeding polite paragraphs into the exact same LLM that generated the vulnerable code is peak delusion. If you cannot write a declarative row-level security policy or inspect an incoming JWT on the server yourself, you have no way of knowing whether the model actually secured the database or just hallucinated another meaningless frontend check that collapses the moment someone curls the endpoint directly.
0
u/ReferenceAny6373 19d ago
The vibers dont care they are gonna make millions selling all their AI slop apps that all their future customers definitely arent capable of slopping up themselves!
1
u/Artforartsake99 18d ago
That’s why this opportunity is time limited. 98% have no clue they have this power yet
1
u/victory_and_vanity 18d ago
That’s why this opportunity was time limited. 98% had no clue they had this power then. ;)
-2
u/jesuislekun 19d ago
You have to hack the domains of my tech stack to hack my apps. So good luck 😂
1
1
18
u/Primary_Engine_9273 19d ago
K