Vibe coding has a security
problem
Non-technical founders are “shipping fast” and becoming easy targets for malicious hackers.
Meet Leo Jr.
He's a non-technical indie hacker who capitalized on the vibe coding trend by building an app in public and earning quick revenue.
If you haven't seen any of his build-in-public takes, let's just call them “spicy”:
This has worked out well for him! His posts are highly engaged, and he's been growing his followers (and customer base) at a pretty rapid clip.
But there's also been a downside.
Devs seem to have taken all of his public flexing as a challenge. At first, this manifested as attempts to hack him:
someone is trying to find security vulnerabilities in my app
clearly with no good intentions
But soon, the attempts snowballed — and the hackers began exploiting numerous security vulnerabilities:
An old story with a new twist
A lot of people are dunking on Leo, as if he should have known better than to build in public before developing his technical chops.
But the fact of the matter is that hackers always target popular apps and popular people. Just ask Marc Lou, whose product got engulfed by hacking attempts after vulnerabilities were discovered.
Or ask Pieter Levels, whose sites got targeted by DDoS attacks following the explosive success of his vibe-coded flight simulator:
The twist with Leo, of course, is that he's not a programmer.
He vibe coded his app without understanding its underlying mechanics, leaving him unaware of its vulnerabilities.
Two tips on vibe security
Security is a huge topic, and I won't delve into it in any real depth.
Instead let's touch on a few basics that can help non-technical vibe coders avoid the vulnerabilities that Leo faced. (Note that I'm going to spell out some basic programming concepts in this section because I intend for it to be read by non-technical founders.)
Don't make your API keys public
If you vibe code a SaaS product like Leo's, it might use an API (application programming interface) that lets developers integrate with its system. For example, Leo's product, EnrichLead, seems to offer an API that allows businesses to automatically pull sales leads from the EnrichLead platform into their own apps.
To prevent unauthorized access, APIs require authentication, which is often done using an API key — a secret string of characters that a developer includes in their requests to prove they have permission to use the API.
In Leo's case, the API keys existed right in his codebase — where users could easily access them.
There are many ways to prevent this, but one is to use “environment variables.” Do this by sending the following prompt to Cursor:
Instead of hardcoding keys in public code repositories (like on GitHub), store them in a secure environment that only the application can access.
Don't make an easily bypassable paywall
Another issue Leo ran into was that the paywall for his product could be easily bypassed:
A CSS-based paywall typically hides content using simple styles like display: none;. This means that anyone with basic knowledge of web development can bypass it by opening the browser’s developer tools and changing or removing the CSS rules.
A more secure approach would enforce the paywall on the back end (using a server). But that might be a little too complicated for a non-technical vibe coder — especially since there are some use cases for implementing paywalls without any backend infrastructure.
So here's a middle-ground approach that uses JavaScript on the front end to make it much harder to bypass a paywall.
Send the following prompt to Cursor — and feel free to do your own research on each of the steps to understand how they work:
I need a 100% front-end JavaScript paywall system that does not require any backend infrastructure. The requirements:
The content should be hidden by default and revealed only if a user has access.
Users should ‘subscribe’ by clicking a button, which sets a flag in localStorage.
The content should be Base64-encoded or obfuscated so it’s not easily visible in the page source.
Implement basic DevTools protection to make it harder for casual users to bypass the paywall.
Please provide a lightweight, easy-to-implement solution.
Of course, these are still very flimsy solutions!
At best, they’re ways to buy yourself more time — either to partner with an engineer familiar with security or to wait for AI tools to improve at handling the security layer of the application stack.
Update
Hours after I published this post, Leo shut down his app:
I think for vibe coders wanting to implement payments the best method might just be to link to an external provider. Instead of putting the payment platform API into your own code just link to a secure external provider storefront like lemon squeezy or something and let them handle it maybe so you never have to store anyone's secure data
yeah this is what gets me nervous about vibe coding as well. as someone w/o a technical background security is a real concern
This has been coming up a lot lately in online discussions. Thanks for addressing the concern and offering some practical tips. I believe there is a place for vibe coding - especially for simple apps that you may want to build and share quickly - but security should be part of the process as much as the features and design of the app.
its pretty hard to not create a .env file in an Ai coder actually, second, why would he roll his own auth and authorization? and have no one check it out to secure it?
Haha I’m technical but not a dev. Was terrified my app was going to have one of these vulnerabilities but luckily this is pretty basic stuff. 😅
I am actually building tool for SMEs to help with saas and cloud security. Would be curious to hear what would people need, what would help you
Would be interested in something like this! Always terrified about security but really don’t even know where to begin when it comes to stuff outside of mfa, the basic stuff in this article, etc
Great to hear. What kind of platforms you would be interested most? I am targeting Azure/AWS/GCP first but I am thinking about other platforms too. In my bio there is linkedin link if you would like to connect too.
This is not just an interesting article but NECESSARY ADVICE. As more people are using Ai coders to make their ideas, theyre having to learn the hard way
Channing Allen's piece highlights the real risks non-technical founders face when "vibe coding" and shipping fast without understanding app security. Leo Jr.'s public build journey brought him attention—but also hackers, who quickly exploited major vulnerabilities like exposed API keys and weak paywall structures. The article offers basic tips to avoid common mistakes, but ultimately stresses that even indie hackers need to prioritize app security early.
For anyone distributing software like the lesson is clear: building fast doesn't mean ignoring security.
you can deff roll your own auth and not have it be complete garbage, but i think an under-explored vector of attack for "vibe-coooders" in the very near future are through mcp servers, which seem to be all the rage. there are tons of backdoors + can be prompt injected. a few guys are already working in the space through vetted "mcp repos" or ai-based redteaming orgs akin to zero-day chasers, but def agree that security should take a bit more precedence if scaling up to a real product. otherwise honestly f em we ball
Good!
channing allen the great
So agree with this. I'm excited to see the number of tools & platforms mushrooming all over the place as people build software products with vibe coding, but the security risk is really something that is being swept under the carpet.
I wonder then though, is security not awarded that level of priority by a massy chunk of users?
really informative
Non-technical founders who use 'vibe coding' risk exposing their applications to security vulnerabilities, as highlighted by Leo Jr.'s experience. To mitigate such risks, it's important to avoid exposing API keys publicly and implement robust, server-side paywall mechanisms.
Vibe coding is fun until the hackers show up.
AI makes it easy to build, but skipping security is risky. That’s why there are now even services just to fix broken AI code.
Vibe coding is 🔥 for momentum — but if you’re promoting an MVP and building in public, vibe content needs to be organized, strategic, and FAST. That’s where Bolta.ai comes in. I built my Threads + launch roadmap in one place, scheduled content ahead, and tracked what actually moved the needle — without dropping the ball on product. Ship fast, but don’t post blindly. Bolta helps you vibe with direction
more vibe more bugs
Great!
True, nowadays I am seeing lot of this issues in X
I agree that implementing at least a basic security measure is a step in the right direction. A system that is 100% secure is not possible, every step just makes it harder to break in. It's a game of time.
Great post! Vibe coding is awesome for growth, but skipping security is risky. Basic practices like hiding API keys and using backend paywalls can save a lot of pain later. Success will always attract hackers—plan for it early!
great info
Literally had the same conversation on X a couple days ago. One guy had his API keys maxed out because people were able to get access to them. Probably because a .env wasn't used properly.
This whole security thing scares me too. Does anyone have a playbook to follow before launching your product? Like a checklist from a security POV. Would be super helpful.
That's a terrible idea. Perhaps better than the easy CSS bypass, but still pretty bad. Hard core security experts will say that poor security is no security at all. I suggest that this suggestion should not be here. Instead, it should be concluded that the only secure solution is to keep your paywall on the back-end. Period.
You see the problem here, right? Many people who are vibe coding don't have access to hardcore security experts — or the technical skills to implement hardcore security. At least not in the early stages of working on their products.
I don't disagree that a paywall should be on the back end. (I said as much in the article.) I do disagree with your total opposition to using stopgap solutions.
I am not opposed to stopgap solutions. But my concern is that indie hackers might read your article and think that a 100% front-end based paywall is a reasonable compromise, which IMO it is not.
I agree that you have given enough warning within your post to say otherwise. I think I can just suggest the following to indie hackers (something that you might consider adding to your post):
When you are building an MVP, go ahead and cut corners. Security is probably low priority. If you gain traction and start making reasonable money, malicious hackers will come for you. At this point, security becomes very important. Please hire technical help (eg. security consultants) or have a bug bounty program.