Back to blogYouTube Video

Published April 20, 2026

Common security vulnerabilities that vibe coders face

Can't play the video or having issues? Here's the direct link.

AI Summary

The video identifies 6-7 common security vulnerabilities frequently made by 'vibe coders' and junior developers, aiming to educate them on critical mistakes to avoid in their code.

Key Takeaways

  • Junior and 'vibe' developers are highly susceptible to common security pitfalls.
  • The content focuses on identifying and rectifying the most frequent security errors seen in early-stage development.

Description

In this video, we're gonna go over 6 or 7 major security vulnerabilities that I see most vibe coded developers making. If you're a junior dev or a vibe coder, I'm 90% sure you're making one (or more) of the mistakes we talk about in this video. Watch the full thing and I'm sure you'll learn a lot. :) P.S I know I haven't uploaded in a long time. Sorry about that :D, I'm gonna try and be more consistent now that I've actually got some free time again haha

Transcript

Auto-generated transcript
All right, it's no secret that AI is writing 90% of our code nowadays. I know that makes a lot of you excited, but we can't forget about basic security when building apps, right? Wipe-coded AI apps are full of security issues, and in this video, I'm going to go over five or six, I don't know, major security vulnerabilities that I find most wipe-coded apps to have. Before we begin, let me address those of you who are pissed off that AI is writing all of our code now. Look, it's easy to blame AI for all these security issues, but the reality is the genie is out of the bottle. AI coding agents are here to stay, and we need to learn how to use them to write secure apps instead of throwing them away altogether. We need to learn how to adapt to AI-assisted coding. And in this video, I'm going to share how I think we as developers can do that. So the very first thing I want to talk about is not securing your environment variables properly. This is not only an extremely common security issue, but probably the easiest to fix by far, as long as you know what you're doing. So every application has sensitive information like API keys, secrets, passwords, etc. And you want to make sure you put all of that inside an ENV file when at least when you're developing the project locally. Make sure that file is also in your gitignore file and never committed to source control. Now when you're deploying on a production platform, let's say something like Vercel or something, make sure you put the environment variables where they need to be in your project settings. All right. I know sometimes when I'm being lazy developing a new feature, I'll just hard code these secrets while I'm testing locally. And then I'll just forget to remove them when I push the repository to GitHub. We can all make mistakes like that. But obviously, we should try to avoid them. And if we do make such a mistake, we need to revoke and regenerate those keys or tokens so they can't be abused by some malicious third party, right? But all that to say, as long as you don't have your environment variables hard-coded in your application, you're going to be fine. Secondly, you want to make sure you're not exposing API keys and sensitive secrets to end users. Now, this is closely related to the previous point. You need to make sure that you never ever hard code your api keys and other sensitive secrets in your code you always need to use environment variables right but there's also certain scenarios where you can expose your sensitive information even when you use environment variables for example front-end applications expose all their details to the user if you've got a front-end app that calls a third-party api people can literally open up chrome dev tools and open the network tab and see your entire request data as well as the API keys and the authorization keys or whatever you put in the request right It literally all available over there for anyone to see. Even if you put the key inside an environment variable, when you actually send a request, it's going to be visible in the network tab for anyone to see. So in this very specific example, the way to secure front-end apps is to have a back-end server that serves as a proxy between your front-end app and the third-party APIs and databases and other servers that you want to communicate with. So your front-end app will literally call that back-end server, which will then send a request to the third parties directly. So that's just one example where just using environment variables isn't gonna, you know, hide your API keys and secrets completely, right? So you need to think about these things. Now, next we need to talk about securing file uploads, all right? And I see way too many developers making the same mistakes when it comes to file uploads. So I've already made a dedicated video going over everything I know about securing file uploads. I'm not going to go too deep into this over here because I've already made a very detailed video on this topic. So just go watch that, right? And as long as you're doing all the things I discussed in that video, your file uploads are going to be pretty secure. So with that out of the way, let's now talk about rate limits and not implementing them correctly. This one is extremely important. You need to make sure you implement rate limits in all your endpoints, especially ones that are concerned with writing or modifying data on your servers. And if you don't know what I'm talking about over here, rate limiting just means not allowing unlimited requests to your servers, basically. Now, let me give you a couple examples of how people can fuck this up, right? so let's say you've got a signup page with no rate limits what happens when someone decides to spam a thousand requests at a point and create thousands of spam accounts on your servers your database is going to be filled with useless junk your server's performance is going to be destroyed and it's just going to be a terrible experience to deal with right and if you're using some third-party api during the signup process for like for example to validate an email address then you're quickly going to run out of rate limits on their platform as well because no one is going to let you use their service if you're sending thousands of requests all the time and so you shouldn't either now signups are usually a very cheap endpoint right at least like computationally speaking there's not really that many operations or stuff you need to do right but what if you have something more expensive than that what if you um let me think about this What if you got an endpoint where you return a lot of data let say a very large video file of 5GB or something What going to happen when someone sends lots of spam requests to that endpoint, especially if that video file is just hosted on some static URL and you can literally just send a request over there to download it, right? If you've got a static URL and you've got a very large file hosted over there, Anyone could send a request there and just spam it so much that you're going to end up paying AWS or whatever cloud provider you use a fuck ton of money for all the bandwidth you're spending on these spam requests. Because that's going to be like some user trying to download a 5GB file like hundreds or thousands of times, right? And all that bandwidth is going to come out of your pocket. Now, I know that 99% of users aren't going to be sending hundreds of requests to one of your endpoints. But there's always that 1% of idiots or malicious actors, right, who do these kinds of things. And we need to make sure our app can handle those people because I promise you they exist. And as soon as you put your app in any production setting, they're going to fucking find a way to, like, fuck it up, right? So make sure you've got proper rate limits on your API. Now, moving on with that, the next mistake I see wipe coders make is not validating and sanitizing the user input. This is again a very common mistake, not just in wipe coders, but also in junior developers. They blindly trust everything that the frontend sends to their backend API. They don't bother to validate the inputs or they validate inputs only on the frontend or only on the backend instead of validating them in both places. Like contrary to what you might think, you actually need to validate form data on both the frontend and the backend. And let me explain why. The reason you need to validate inputs on the front end is because this will allow you to drop invalid requests before sending them to the backend API. Let's say you've got a login page and the user inputs an invalid email address. You can just reject that on the front end directly, right? Like you can just use a simple rejects check and validate that on the front end without sending a request to your backend server for no reason, right? And this also means faster responses for your users because you can show them the error message instantly without having to send a request to the backend. And also this means less requests on the backend server, less, you know, resources used over there, which translates to better performance overall. Now the reason you need to validate user inputs again on the backend is because the frontend can be modified by any user And if you don have a front if you only have an API that users directly send HTTP requests to then this is even more important But even if you have like a front-end app that talks to your backend API servers, users can still send pretty much whatever they want in the request, right? So your backend API needs to validate and sanitize the user input again and make sure that everything is valid before doing any processing on that input. Now, what does it mean to actually sanitize and validate user input? Basically, you just need to make sure that whatever data your user is sending is the data you actually expect to be there. Like, make sure that it's got the proper format and everything, right? So, for example, if you've got an email address field and the user is sending some obscure SQL code over there or something, then that's obviously not going to be valid, right? or if you've got a profile picture edit where a user is sending a pdf or an executable instead of an image file that's obviously wrong right so just make sure that users are sending valid inputs and not something completely unexpected or malicious right now to conclude all of that these are like the 80 20 of security practices that all applications should be practicing and especially vibe coded applications because i can promise you most of the vibe coded applications are out there they're not practicing any of these like security ideas right so if you just follow all these things you're going to build much more secure apps than pretty much any vibe coder or no code creator nowadays right and obviously you can use ai to help you implement all of these practices in your application like i'm already using ai to write all the code for me but just make sure you actually learn what these are and how they work, how they're protecting you from vulnerabilities and what vulnerabilities they're actually protecting you from, right? Because if you don't have all that base knowledge, if you don't have all that context, one, you're not going to be able to use AI to secure your application because you're not going to be able to prompt it well enough. And two, even if you ask AI to implement all of these things, you're not going to know if it did it correctly or not unless you actually learn these things, right? So just make sure you learn these things as well, right? That's all for this video. Thank you for watching. Like, comment, subscribe, do all those wonderful things. I know I haven't posted in a while, but I'm trying to be consistent again. So if you want to see more videos like this, make sure you subscribe so I know that you guys are actually interested in this topic. I'm going to try and post more videos nowadays and be more consistent and yeah see ya

Share this article

All great things started with a conversation

If you've got a cool project or opportunity and you want me to be a part of it, set up a free meeting with me here, and let's talk. 😊