932: Vibe Coding’s Huge Problem  ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 932: Vibe Coding’s Huge Problem - Category: #podcasts - URL: https://share.snipd.com/episode/9c962b43-8a79-4e58-a496-7715ba6d0022 ## Document Notes ## Highlights - **AI-Generated Auth Mistake** - Wes accidentally let an auth check run only on the client when scaffolding quickly. - The generated UI even told users the cookie value to gain access, exposing the flaw. Transcript: Wes Bos Right, let's talk real quick. So this was an app that it's century hack week right now. And we're building some apps and I'm building this like LED grid that you can control over the web. And I needed some very basic auth, basically where I was just going to throw a cookie in my own browser and I'm checking for that cookie and a specific value on request, right? At the very most basic auth that you can get. I added that in and whatnot. And then I just like typed into cursor, like go ahead and protect these routes with it. And it started adding the auth client side. Like, it was checking for the auth authentication client side. And then it was also adding an error message that says, you don't have access to this. Add a cookie with this following value in order to have access to it that's literally literally telling the person how to get access to it hey wes have you ever considered this is the future Scott Tolinski Of apps and ai never makes any mistakes and is perfect and the fact that it's suggesting this to you means that you need to upgrade your brain matter. Yeah. Have you considered that? Wes Bos No, I have not considered that. But honestly, the fact that I caught it, so what it was doing is it created an auth.ts file and it was putting the client code and the server code in the same file. And sometimes in apps, you can do that and it gets tree shaken. But like literally it was adding that into the same file and it was only doing the check client side. So before you click a button, it would check if you had the cookie there client, entirely client side. It wasn't protecting the red at all. And the fact that I caught that and I said, are you checking the auth client side? It says, you're absolutely right, which drives me nuts. ([Time 0:02:33](https://share.snipd.com/snip/9dfa2ae5-aa49-4566-aabc-94c58c819d60)) - **Mass Exposure Of Sensitive Files** - The T-app stored uploaded driver's licenses in a Firebase bucket with a wide-open endpoint. - Attackers could scrape and download sensitive documents because access controls were missing. Transcript: Wes Bos Was that the idea? Scott Tolinski It was a dating app, but it yeah, that man, a part of the application that I think is kind of shocking in all of this is that they had women upload their driver's licenses. Like the the fact that this would have been taken in a way that was so insecure or uh you you can explain how it was insecure but when you're dealing with such secure data and information Being so careless you ever heard of it is just shocking and mind-blowing to me and this person should i i i don't know what the legal consequences but this person the people responsible Wes Bos For this this is like negligence they should face legal consequences in my mind exactly so what was happening was that they're they're having women upload the driver's license or something Else in in order to to be validated right and then they were storing those photos in a firebase bucket right just as like an asset however they also had an end point that could pull all of Those assets and then it basically was just a wide open endpoint. I'm showing it right now on the screen. It's still in Firebase. These attachments are no longer accessible. So I've heard. And people could just scrape this API endpoint and then download every single asset that was available. And these were private assets not be accessed by the general public, right? So that's a major security issue, having people's sensitive documentation. Even storing something that sensitive requires security officers and all of the stuff. And I do believe that this T-app was primarily Vibe-coded. ([Time 0:04:47](https://share.snipd.com/snip/ed8606c7-0e89-4709-9c15-1da7fcca11cc)) - **Don't Vibe Code Access Control** - Avoid vibe coding access control; implement explicit permission checks instead. - Break permissions into simple yes/no or CRUD checks and enforce them on the server. Transcript: Wes Bos First, don't vibe code access control. It's really not that hard. It's not. Access control can get complex in like you having to manage who has access to what, but being able to say yes or no, does somebody have access to this thing? And generally, you can break it down to do you have access to it? Yes or no? Or you can bring it break it down even into to crud? Can they can they create these things, but not read them? Can they read them but not create them? Can they delete them? Can they can they read their own? These are common things that are built into a lot of of access control apps out there if you're using some sort of CMS backend. ([Time 0:07:47](https://share.snipd.com/snip/570c5b30-81a1-4a0e-9622-9133c2c61dd8)) - **Block By Default, Allow Explicitly** - Default to denying access and explicitly allow only authorized users. - Do not ship wide-open endpoints and then try to lock them down later. Transcript: Wes Bos Our next step here is let in, don't lock down, meaning that you should not be allowing people to access data or send post requests to endpoints. And then you have to go in and lock it down. You should be the opposite is everything should be locked down by default. And you should only be letting through the people that are allowed. And Firebase had kind of an oopsie over a long time ago, and they're still paying for it. When Firebase first rolled out, everything was wide open. And it was great because you could just throw it in there and you could just start saving stuff and building an app really quickly. Yeah, and you didn't get bogged down by this annoying access control. Scott Tolinski The problem is people never actually went back and and locked it down yeah i will say the creator of meteor said that that was one of his biggest regrets in creating it was not having it Be locked down by default and uh zero sync had the same issue it was open by default and then they have since because it's an alpha have since changed it to be the opposite it's it's denied By default and you have to open it up, which is great. That's the way it should be. Wes Bos Even like I have one Firebase database from like a tutorial I did a long time ago and they sent me an email every single day like, hey, your access controls are insecure because of X, Y and Z. And it's because people can if you have it wide open by default, you can just say list all of the endpoints and then you can loop through each of the endpoints and see what is available there. So this is not a new thing, right? This is how a lot of firewalls work, right? Block everything by default, but let people in. Don't reactively go and lock things down. ([Time 0:09:38](https://share.snipd.com/snip/c41b315e-2f77-4b82-9898-7cae3ba6bb57)) - **Enforce Auth On The Server** - Ensure access control runs on the server, not just in client code. - Protect database queries and endpoints at the server layer where clients cannot bypass them. Transcript: Scott Tolinski Next thing we have here is be very clear about code that runs in the server or the client. And in regards to locking things down, you cannot lock things down from the client in that way. You cannot, if the access control is happening only on the client side, that's not access control. That's a sign that people can get around. You need the access control to happen at the server level when you're querying from the database itself. Wes Bos Yeah, and this can get a little bit muddy with a lot of these React server components. All of these meta frameworks allow you to mix your server logic and your client logic the same folders and in some cases even in the same files. That's great because the developer experience is awesome, especially if you've got utils where like a format money function is something I have all the time, right? I want to be able to use that same function on the client and on the server. But there are some things like databases where you simply do not want that to be able to accessible on the client side. And if you simply import the wrong thing into a file, there are lots of checks to make sure you're not doing something bad, but you can let things slip through. So be very clear about how you do that. ([Time 0:11:23](https://share.snipd.com/snip/b1deddf8-b9b5-4cc1-8cd8-3fbcf625bd03)) - **Server/Client Ambiguity Raises Risk** - Mixing server and client files in modern frameworks creates ambiguity about where code runs. - That ambiguity makes it easy to accidentally expose server-only logic to the client. Transcript: Wes Bos Yeah, and this can get a little bit muddy with a lot of these React server components. All of these meta frameworks allow you to mix your server logic and your client logic the same folders and in some cases even in the same files. That's great because the developer experience is awesome, especially if you've got utils where like a format money function is something I have all the time, right? I want to be able to use that same function on the client and on the server. But there are some things like databases where you simply do not want that to be able to accessible on the client side. And if you simply import the wrong thing into a file, there are lots of checks to make sure you're not doing something bad, but you can let things slip through. So be very clear about how you do that. I know Svelte has a dot server dot js file they now have a remote files oh they now oh yeah dot dot remote file not oh they did have server though right well the server thing is for yeah code Scott Tolinski That runs specifically on the server could be endpoints or whatever but now their new rpc thing which is very more similar to react server components is these remote files, which only Run on the server because one of their core principles in designing these things was we want zero ambiguity as to what is running on the client and what is running on the server, like zero Ambiguity. We don't want them to mix, although we want it to be easy. Wes Bos Yeah. In React Land, you can pop a used server on there. So you have to be a little bit explicit where if you do want to do this, it's kind of hard to accidentally do it. ([Time 0:11:54](https://share.snipd.com/snip/f1e11dad-e41f-4109-ada1-7aa90f3bd3f0)) - **Use AI To Assist Security Audits** - Use AI to scan your codebase for possible security issues as a second check. - Ask models to generate automated tests and security checks for access roles and endpoints. Transcript: Wes Bos And like you can vibe code something and then you can take maybe even just another model and ask it to like, hey, can you go through this and check for any security issues? Because AI is very good at detecting possible issues that can pop up. So I don't think it's the single thing that can happen. But I do think that you can ask the AI to kind of rip through your code base, especially when you get into some of these bigger, like cloud code or max mode on cursor, things like that, where You can just like let it rip for hours on end, it will go through it and not just kind of do a half ass job at it. Scott Tolinski Yeah. You know what? Even with that visualizing your thing, there's definitely like a conversation that we're not having in this episode. But when we say access controls, that could mean, you know, assigning individual access controls themselves can edit, can whatever as a means of controlling access or a role-based Access system where this role has access to the following access parameters and only these ones so this role can do this like i'm an admin therefore i can do this i'm a super admin therefore I can do everything Or you can control it on a more micro level and say, this particular person is capable of doing these following things. Wes Bos Last thing is, is automate, automate tests. It's very easy to even you can go ahead and ask AI to, to spin up a whole bunch of automation tests for all the different access roles. And then anytime you have a change, you can run those tests. And if one of those fails, oops, something changed for these types of things. So I don't know that the AI is going to entirely help you here. ([Time 0:14:04](https://share.snipd.com/snip/d880adf7-5977-497a-8d05-6bb09950ce5a)) - **Automate Role-Based Tests** - Automate access-control tests and run them on every change to catch regressions. - Generate role-specific test suites and fail builds when permissions break. Transcript: Wes Bos Last thing is, is automate, automate tests. It's very easy to even you can go ahead and ask AI to, to spin up a whole bunch of automation tests for all the different access roles. And then anytime you have a change, you can run those tests. And if one of those fails, oops, something changed for these types of things. ([Time 0:15:30](https://share.snipd.com/snip/1343684b-accf-4ad9-80ea-78123e3e2100))