Security Risks of AI-Built Apps: Protect Your Software Tools Today | 440

Dan Hafner: All right, welcome back to the show everyone. Dan Hafner here, back with the Tech Bytes podcast. So today we're gonna be talking about a very interesting, very timely topic in the vibe coding space. And that is the topic of security.

A story came across my feed and I just could not help but dive into this more because man, this is very, very interesting because I've talked about it on the show. This is what I do every single day. A lot of us, if you're listening to the show or you have any interest in the show. You're probably into software.

into the open-claw world, the clod coding world. And it's exploding this market. It is allowing people just like you and me who have not a lot of technical know-how and capability to be able to launch their ideas and to get them out there and to make money off of them and even build entire companies and sell entire companies based on the software. But there is a new study that came out that said anywhere between 40 to 60 % of Vibe-coded apps can contain at least one security flaw, which is pretty insane to me.

Not only did this actually catch my eye because of obviously what I do day to day, but I actually decided to go back and look at a couple of the tools that we've done. And I did also find ⁓ some security flaws in some of the things that we did. it's not just, it's not like I'm on my high horse out here pretending that I have it all figured out. So this is very interesting.

So we're gonna dive into this topic here. So before I get into that further, If you are listening to this podcast, wherever you are, please like and subscribe the show. And if you are on YouTube also, please subscribe to the show. That really, really helps this get out there and be fed to more people in algorithm and on the platform.

So I really do appreciate it. Just hit that subscribe button or like or follow or whatever the case might be. Really, really helps the show get out there. And you can also go over to the Tech Bytes podcast, which is linked in the show notes here, and you can subscribe directly from our website.

just because you can... ⁓ launch these apps with tools like lovable, replete, base 44, et cetera, inside of ⁓ hours or days instead of weeks or months, ⁓ doesn't mean that it's actually a smarter way to build in terms of different enterprise level things ⁓ or ⁓ super complex types of applications. And again, the article that I was referencing in this, I'll link it in the show notes. It was, I believe it was from Forbes.

And it was basically saying that anywhere between 40 to 60 % of these Vibe coded apps that they did in this, that they studied through this, know, this survey were found to have at least one security flaw. Now I'll get into what they, you know, kind of what those fixes are and how those things kind of were found because Obviously, it's a pretty low bar. mean, what kind of tool out there doesn't have at least one security flaw, which is kind of, ⁓ you know, another conversation worth having.

Nothing is always 100 % secure. So I think that's a little bit of a misnomer, but what they're saying is that these tend to be a lot less secure and it has to do with several different factors, right? ⁓ So what's really this core problem that we're getting at, right? The big thing that people end up building when you build an app with base 44, replet, lovable, whatever, is you're really, it's hard to think about authentication properly.

You have to make sure that it's all authenticated. I, the user, am logged into my account. You, as your user, logged into your account. So there's an authentication piece there.

There are usually APIs that are included inside of that that can be ⁓ definitely, exposed or anything like that. ⁓ There are snoring dogs in the background which can tend to be very distracting during a podcast. Huh, Lily? She is such a snorer, ⁓ Anyway, authentication, secure APIs, input validation, and then database RLS, or row level security, basically being exposed.

So ⁓ basically we can build things that work really, really fast, which is obviously This that's a typical developer mindset of like build things, break things, make sure they work, make sure that they're functioning. And then you can kind of think about security later. Think about like building a fort or something like that back in you know, middle ages or whatever it might be. You were first, you were worried about security, but you had to first get a roof overhead.

You had to first get certain things happening before you worried about different things. So. ⁓ Again, it's kind of like you're building this house and you're not really worried about you can't have a lock on a door until the door is actually there, right? So security naturally comes as a secondary concern or a secondary piece to this because what's the point of locking something if there's no door to actually lock in the first place, right?

So ⁓ imagine this. Imagine you are building a new SaaS tool. You're using a vibe coding platform to launch your new to launch your new idea, to launch your business, to get it out there, right? You build it in a way such that users can log in, they can store data, they're putting business data, personal data, whatever that is inside of the app, maybe even payment information, et cetera.

Then all of a sudden, someone finds an open endpoint or an API piece of thing, ⁓ they're able to... breach the database and get all of that sensitive payment information, social security number, anything like that. Now you've got a data breach on your hands. You've got legal risk that exposes you.

And then you also just have some reputation management that you're gonna have to, and brand management you're gonna have to tackle as well. ⁓ And that's a very, very real case. That's something that can easily happen in a lot of these cases where it's not like it's going, it's not like it's a a certainty, but if you have enemies, you have, ⁓ you if you start to get big and you start to have malicious people start, you know, wanting to get after you for one reason or another, that is something you do have to think about, unfortunately.

That's just part of being in a capitalist society. It's part of being in the world in general, not even just capitalist society. ⁓ But it can be, it can be very, very real and very, very terrible. You know, I didn't have anything like this happen to anything that I've built.

I have had disaster recovery happened. I remember I was three months into my business, starting out building apps and doing no code stuff for people. I had three or four clients at the time. And one day, boom, everything was completely wiped out.

had a ⁓ long story short, there was a fire at a warehouse, ⁓ like an AWS warehouse over in like Europe, like somewhere like literally on the other side of the world from me. ⁓ and it completely burned everything down and we had zero backup, zero ⁓ stored disaster recovery backups to be able to put things out there. And I learned a very, very valuable lesson from that. Luckily all my clients at the time, if you're one of those listening, God bless you for staying with me.

We were able to rebuild everything successfully. And it forced me to think in terms of that in the future, right? Like that can happen when you have. a brute force attack where you have some hackers leak information.

know Claude just had a recent story this week where they had part of their source code was actually leaked online. You can bet your sweet ass that they're freaking learning from that, right? That they are actually ⁓ going to take that into consideration in the future of, maybe we should really rethink our security protocols and how did this happen and what can we learn from it? How can we prevent this from?

being worse next time, right? So they're definitely ⁓ learning from that. And sometimes that's what it takes. That's how you learn sometimes.

You have to fall and scrape your knees a little bit. So ⁓ why is this kind of happening? I kind of sat down and thought, why, if all of these things are built this way, why is this security thing happening and becoming such an issue? ⁓ And I think part of it is that, it really seems to me like, especially in the software development world, AI is trained for three things, right?

It's trained for speed, ⁓ for functionality, and for completeness, right? Like that's really the three parameters. When I use a tool called Vibecode, which I've talked about on this show, when you put something in, the agent is working as fast as it can to make it as functional as it can and complete as it can. And it might take 30 seconds, it might take 10 minutes, it might take five minutes, ⁓ but it's usually producing pretty good, ⁓ well-designed, well-thought-out pieces of software, but that is not taking into consideration long-term security stuff, architecture integrity, ⁓ even your edge cases around, there's a lot of things that can happen when you're an ⁓ application from a desktop view to a tablet view to...

to a mobile view, different input scenarios. Can I log out and then log back in as the same user? Can I then make myself an admin through a terminal type of thing? There's all kinds of different ways that you can do it, and obviously it's very, very difficult.

There's a famous saying in security, counterterrorism type of things. As the defender, you have to get it right every single time. An attacker only has to get it right once. They only have to find one vulnerability, one flaw, one...

⁓ you know kink in the in the or what do they call it a chink in the armor right a kink in the armor whatever that word is ⁓ that can cause that stuff to then go awry so ⁓ you know it's it's kind of like we are ⁓ everybody's building stuff very very fast and then we're not we're just launching things without really taking the time to just think through is this secure is this you know viable, is this scalable, is it kind of at a way that, and I'm gonna give you guys a hot take here actually, because you know, I've on the show, I've talked a lot about all the older, ⁓ you know, no code platforms, such as your platforms like Bubble or Adalo or even Flutter Flow.

You know, I used to use one called Good Barber. ⁓ The funny thing about that is now, like even myself, I have completely migrated away. from those types, I wouldn't say completely, we do some client stuff in there. But for the most part, we've migrated into these types of lovable, replica, base 44 type of apps, vibe code, et cetera.

But the thing is with the older tools like Adalo or Bubble, they actually had security and authentication and infrastructure baked in. Like you didn't have to worry about that. People would always ask me like, how does this work? And it was like, well, it's the platform.

They already have that baked in, you don't even have to worry about it. And ⁓ I think that's actually one thing that I kind of carried over into the new stuff that we were doing was I forgot that we had to worry about that for a little while. So actually I was just like the rest of you, just kind of building stuff and going forward and trying to make sure that things were there and working and doing the things they needed to do and giving a second thought to security or a second thought to different things like that.

⁓ because with a lot of those older tools, had, like the code really wasn't accessible. So you really couldn't do a lot of that stuff and you kind of had to take it for granted. Now you can actually build these things on Lovable, on Replet, on whatever platform and they give you the ability to export the code. That's one of the coolest things about it.

But ⁓ people are also exporting that code. They're moving into self-hosting things, stitching together APIs, just doing a whole bunch of things like that. And obviously that ⁓ comes with a cost of, now that stuff's not handled by the platform. Now it's handled by you and you have to think about it.

You have to figure it out. And you have to be that self-providing, you know, security measure, that self-providing, you know, strategic thinker around, I don't just have the platform to fall back on here. I'm actually responsible for this, you know? So that's a very, very interesting ⁓ kind of take.

on that kind of stuff I thought where I was like, wow, that's actually very, it's kind of an interesting dynamic to that because it was, you know, the reason I transitioned over into everything was because of just how much better things were. And then you start to think about, hmm, well, maybe, as far as security standpoint, maybe it wasn't always better. It can be fixed, right? So what do you actually need to care about when it comes to The fact that you're building things and you need to care about security, you need to care about being able to make sure that the tools that you either launch for your business or for other businesses are actually going to be usable, but not in like an over-technical way, right?

So the top risks that they kind of found with this was the open APIs with no authentication, right? Hard-coded keys or like exposed API keys, like, you know, when people... There's a reason when you see YouTube videos all over the place, people blur out the API key because the last thing you want to be able to do is put your API key out there and then have someone rack up a bill of $5,000 on your API key and then you're responsible for it, right? Because there's no way to really like shut that down ⁓ without going through a lot of hoops.

The other one was poor user authentication. like easy passwords to guess. ⁓ know, we really, we started implementing a two factor authentication process for all the apps that we build. which makes them more secure, prevents a lot of bots, ⁓ signups and things like that.

So that's a big one. The database exposure, as I mentioned, like the row level security stuff, SuperBase is always one that integrates. a database, no code database tool that integrates with a lot of these tools. And I just got an email this morning that we said that when we hooked something up, we were testing the open tables versus like lockdown tables and we forgot to lock one down and it said, hey, there's a security risk here.

This is actually publicly open. We're like, ⁓ whoops, definitely need to fix that, right? ⁓ And then the other one is rate limiting, right? So the open API keys with no authentication, the hard-coded keys, poor user authentication, database exposure, and then no rate limiting.

So again, you don't really need to be a cybersecurity expert to figure this out and make stuff secure, but you do need to know where those landmines are, right? So those best practices just like don't... ⁓ expose your API keys, make sure that everything's locked down. We've actually tried a couple of other tools.

There was a tool that one of my new friends actually turned me on to called CodeRabbit, which has been very interesting. It's basically an AI-based code review tool where you can just export code, upload stuff, and then it can basically just run through and identify all of those different things, as ⁓ even low-level things of like broken functionality. but then security level things, all kinds of different stuff. So that's worth trying out.

I'm pretty new with it. I can't really say I recommend it. I've just started using it recently, but it seems to be doing a pretty good job. So again.

When it comes to this, ⁓ just don't expose your keys. I would really recommend doing two factor authentication for any app that you're gonna be using. Again, you don't need it. ⁓ It can be a little bit to implement because you do need like a resend key or a Twilio key if you're gonna be text messaging and stuff.

⁓ But two factor authentication definitely is a good way to go. That's why I really love Vibecode. They have a ⁓ very awesome 2FA piece that's just built into a lot of apps that you build, where you just put in your email, they send you a code and you input it. Works really, really well.

Level two intermediate stuff would be API authentication, making sure that you're using either SuperBase or Firebase properly and setting up that RLS, that row level security. And then input validation is definitely one that even I missed a couple of times when we were first starting and said, ⁓ that's definitely something that we can. ⁓ implement across the board. And that really protects you from those brute force attacks and password hacking types of things.

Excuse me. And then you can always go with a level three type of thing where you can actually have a team come in and do a security audit. You can do penetration testing. You can do architecture review.

A lot of these things weren't really available with lot of no code tools, but now that you have access to the code, to the database, even doing something like a code rabbit review or different things like that, can be really, really ⁓ kind of more of an advanced ⁓ service or a way of going through that, whether it's your own tool or a tool you're building for other people, just to have that peace of mind and to have, ⁓ you know, if you can't pay a senior engineer to review it all by hand, you can still leverage AI to go through and try to do those things.

And I know that I'm very interested to see there's a new model that Claude is coming out with, I believe, very soon, or if it's not already available for research. Methos, believe or mythos, however you say it which is supposed to be very interesting from a cyber security perspective meaning that it's going to be very ⁓ It could probably be used to generate a lot of cyber attacks But at the same time it should also I would think have the reverse ability to be able to have a lot more ⁓ Of a stronger, you know defensive mechanism to that inside of a cyber capability.

So, interested to see what happens with that one there. ⁓ big picture of this episode, right? ⁓ Everyone is building apps now. You're building, I'm building, we're all building.

It's all great. We're all doing really cool stuff, really fun stuff. But very few are building things well. And that's really the difference, right?

So, just because everyone's building things doesn't mean that everyone's building quality. ⁓ but even fewer of those building things well are building them securely, right? And I will admit, there was a time we weren't building things very securely either. We went back and caught those types of things.

⁓ This was definitely something that caught my eye, made me think twice about it. ⁓ But the winners in this space aren't just gonna be the fastest builders, the first to market, that tends to be the big mantra you see online of be first to market, just push something out there, build and break things, right? But the winners won't just be the fastest builders. They're going to be the people that build things fast that are actually proven trustworthy, that are proven quality.

I think the market decides on those things and naturally those tools and those platforms rise to the top through that process of, we built this first, we built this quality, this is an interesting product and it's secure and it's well put together and it's tested. That just puts together such a nice clean offer to put ⁓ to a customer and to a market and that will stand the test of time. That's really my belief as far as who the winners are. Regardless of what niche you're in or what industry you're building in, I really think that's gonna be who's gonna win on that.

So yeah, if you've built an app with AI, I'm very ⁓ interested if you have thought about this or gone back and implemented this or if there's other tools that you are possibly using. besides AI generated ⁓ code reviews or any things like that, security pen testing tools. Be very interested to hear any of that. If you guys go to the Tech Bytes website here down in the show notes, I'd love to hear from you if you have any recommendations or any thoughts or any questions you might wanna ask for a follow-up episode around this topic.

I'd be very interested to hear all of that. ⁓ And then as always, if you are someone who is like, don't really have time to think about all this kind of stuff. This is not really my cup of tea. Definitely hit me up at danatdappernocode.

com and I'd be happy to take a look at whatever you're building. We can either come in and help you consult with ⁓ what you actually have going on and what you're doing. We've helped people kind of at the edge of like, I need to publish this app. I have it built, but I don't know how to publish it.

We can help with those types of things. Or if you're just in the idea stage and you need something completely built from scratch ⁓ using one of these tools, we can definitely help with that too. You can go to dappernocode.com and check us out.

All right, guys, that's it for this episode. Be very interested to hear your thoughts and your opinions. You can go over to the Tech Bytes podcast or Tech Bytes podcast website. Subscribe, subscribe on YouTube, subscribe on your podcast episode or channel wherever you are.

And that is very, very much appreciated. Until next time, guys, take care.