Secure Builds in 48 Hours

[00:00:00]Hello. Oh, excuse me. Hello everybody and welcome back. Um, can you believe we are already on one, two, three, our fourth micro webinar of today? That is like a lot to me because it's noon here.

[00:00:14]Maybe that maybe it's the end of your day and you're like, yeah, so what? Um, but I'm just like, wow, we are just cruising through them. Um, this one is one of those topics that I was like, yes, let's have multiple on this because we can't talk enough about security.

[00:00:31]So, with us is SA from season 2 and SA has a background in product security as an engineer. So, she is an remarkable person to talk about security as was Lena. Um, because Lena of course is also an engineer. But I really like it makes me very happy that we have the engineers within she builds who took on this topic. Um just kind of shows the you know what how secure it actually is. Um and so I'm going to get to shutting up so that we can let the real star uh take over which is Sana. And thank you so much for being with us today and sharing your time.

[00:01:12]>> No, thank you so much for having me. I loved lovable and this that's how I learned how to wipe code and like learn more about AI built applications. So I'm really excited to be here. Um my name is Senna Talwar. Um I'm a product security engineer currently at Service Now and I also teach sometimes depending on this this semester this season. Um I'll teach like a class or two on like inter cyber security at community colleges near me.

[00:01:36]Um and today like I'd really love to talk about like something that I like lived through. So bu you know I was a part of season 2. I built an app, a full stack app in 48 hours through Lovable.

[00:01:47]Um, and what I really learned on the like after I had built it and submitted my application on like on the security side of things. So, this is for all you builders, you don't need to have a security background, I would say. Um, but if you have already shipped something with Lovable or you're about to with season 3, um, please, you know, I hope you take something away from here.

[00:02:11]So one of the things I would say like the honest take about like building fast and like a lot of things with AI assisted any task that you do specifically uh coding is that speed will like always obviously win the demos right like I created this entire HTML presentation through cloud um and lovable is really good at getting from like your idea to your working application within maybe a couple of hours if you exactly know what you're you know looking to do and the momentum is so real and it's so quick and easy to build something that you're thinking in your head to have it like a prototype in fruition. Um, but the shortcuts sometimes can compound. So there's in from a security like standpoint lots of things like hard-coded keys, missing RLS, authorizations that only live in the UI. Um, every one of those can like have like can be like your decisions at our zero become a problem when your app is in front of like real users. So when your app is actually in production, it's published. Um those issues really matter in terms of like trust and reliability um on your brand and your business.

[00:03:18]Um and you only really get one launch, right? Like a breach on day three doesn't just like like lose your users, but it also creates the narrative that you're you know of your product before it has had like the chance to be visible and to grow. Um, but the good news and the point of kind of today and this webinar is security and speed aren't always opposites, right? They're both downstreams of good defaults. So, you can have both, but you just need to know which decisions like actually matter and like how to do it securely from the beginning. Um, little bit about me and how I got involved with uh with she builds and lovable last year applied all these was amazing of the fact that I got selected. These are all the stats. Um, and I remember applying kind of want to win. I saw it on like a Discord channel somewhere. Somebody was post somebody posted who was part of season one posted about it and I and you know my application was mostly just like this is a idea that I had in my mind. I'll see what happens. Um, and I was like worst case scenario I'll just learn how to code. I've been thinking about it. But besides the you know chatbt and claude and like asking it questions here and there I hadn't really built anything using AI before before um she builds in lovable. So what I feel like what lovable gave me in terms of experience was generally like very impressive.

[00:04:40]Being able to I I I did a computer science degree and I hate programming.

[00:04:44]So being able to like do what like from a logic standpoint, being able to build what I want from like the front end or the back end, the database and the hosting and having all of that logistics figured out um was amazing. Um but back then, I think it was November or December last year, there's lots of things that I thought about like from a security standpoint after the fact. Um and AI generated um most I would say AI generated code is not secure even at this point. There are a lot of people and a lot of great companies like lovable putting guard rails on it and making it more secure every single day.

[00:05:21]But there are things that you and I can do while we're building to make sure um that you know that we're building a secure application.

[00:05:29]Just a quick note I'll move from this uh point pretty quickly. Um this is mostly for like enterprise applications but like average cost of data breach is like almost 5 million and almost 80% of applications that are breached are um involve some kind of like stolen credentials. So it is a very obvious and like very common like being breached is very common these days even like the giants of giant enterprises are being breached every single day. Um and especially with vibe coding site specifically I think it was Georgia Tech. Yeah. um on their vibe coding security radar um they are tracking like all the CVEEs which are common vulnerabilities that come out um uh for um for applications uh every single day it's on a curve it's growing I think it was 35 in March and another great statistics here is like about 45% of all AI generated code introduces um the top 10 uh security vulnerabilities that are labeled by OASP and these are All vulnerabilities in production apps that are probably live today used by real people have like sensitive data in them and a lot of the build builders sometimes have no idea. A really funny scenario was I forget it got really popular on social media was um I think a few months ago where this guy on Twitter posted about like oh I just built this like great app. I forget what it does now but I don't know why I've coded it. It took me so many hours.

[00:06:56]It was amazing. within a few hours it was breached like mere hours. Um and then he posted about experience about you know how it was breached why it was what happened and you know how you secured it going forward. Um but building is public is great. Building things is amazing but there are attackers out there that are really you know out there to get you no matter what. And especially with bipoded um vulnerabilities, those are a lot of the times like lowhanging fruit that you we might not consider um that are that do have like easy fixes.

[00:07:30]The three um pillars that I would argue that every lovable or any vibe coded app needs is like what actually matters. If anything you like leave with today like these are the three things I would highly recommend that you look at and make sure that you have um some kind of controls for these three conditions. So number one is secrets right keys do not belong in any of the client side code ever and lovable has w has vault um so use it everything that touches a secret key has to go through the superbase edge function and not the browser u and this maps directly to the OASP uh AO2 OOPS has like a list every year I think that's next slide that goes through the top 10 vulnerabilities in web applications so it maps directly to that um with crypto uh cryptographic failures and a prompt you can use and I'm one of the things I want to do here is like give you easy prompts that you can run through either the beginning or the end or whenever you know whenever you feel like it throughout your build your um building journey. Um, so some like a simple prompt that you could use to make sure you're covered in terms of secrets could be like, you know, move all API calls with secret keys to the edge the sum of based edge functions so they're not exposed in the browser. And that should cover most if not all of your secrets. Um, lovable is amazing in terms of the AI background, but you have sometimes you have to tell the uh the you have to prompt your AI to make sure that it does what it's supposed to do or like what you want it to do. R RLS is also really important role level security um that's the thing that most widecoded applications have seen um on like on in the public. So um it's off by default or used to be off by default.

[00:09:16]It's not anymore when it's off and your like your anonymous key is the client which is it's usually by design. Um anyone can query your database directly.

[00:09:26]There's no login required and the simple prompt is right here. Just make sure you enable your RLS on all tables in Superbase and add policies.

[00:09:35]Um I'll go a little bit into RLS later as well. A third is access control.

[00:09:41]Sometimes what let's say you're building an app, you know, you go through different phases. A lot of the times what happen is like oh like change this and remove this, but your AI sometimes reads it as like make this like button let's say hidden instead of like actually removing everything about it.

[00:09:57]So, and that's sometimes what happens with like when you're prompting with natural language, things are ambiguous.

[00:10:02]So, unless you specifically say maybe like, hey, remove this button completely, remove any connections with it, don't just hide it and you forget about, you know, being so expansive for that one like, you know, simple button in your uh application. It might not do it exactly as you wanted to. So, hiding a button is not authorization. you and I might never see it. If we don't read the code directly, which I personally never do unless I'm really digging into something. Um, so like if you call an API endpoint directly, you get the data.

[00:10:35]Every route I would say like needs a serverside check. No matter like as you're building it, you should have a server side check. So even if your AI fails you and hides the button, no attacker can, you know, attack it. And here's a quick prompt right here that you could use um in your plan as well.

[00:10:52]within the time frame of the buildathon, how I would kind of tackle security if you want to build it in, you know, if you want to have a production ready app at the end of it would be like a little like, you know, I have a I call it a battle plan. So number one thing you can do is while you're building within your first prompt, um you can add security within your first prompt as a like oneliner at the end, right? build this app with RLS enabled on all tables, secrets in the environment variables and server side au authorization authentication on every route right one line you can add on your first prompt so lovable knows that you while you're building something you want security to be your topr priority right it saves it in the memory it builds on top of it so that's number one I would say within you know the the the halfway point like uh or like a quarter way point of 8 hours.

[00:11:48]As you keep like adding your features, keep checking. Open the Superbase table table editor. Verify that there's no keys existing in the client JavaScript.

[00:11:58]Test your O by logging out and trying to access things directly. Um, and every new table, make sure that the that you're adding that you check the policies. I remember when I was building u I had like a very simple login page and I I published it for like a few seconds. I test it out and I didn't realize that it had absolutely no checks on it. I remember just like logging in with like Alice. Test.com with 1 2 3 4 5 6 password and log. It was it was letting everyone sign up and log in whether the email was valid or not, whether the password had any like certain policies or not. So there's lots of ways you can do au a authentication on your lovable app. Make sure that you choose what's right for you. I think there's Google au if I'm right there's Google to do it. There's a magic link way to do it. So just make sure what you're doing is you know you know what you're aware you're aware of like what your authentication looks like. Around the halfway mark you definitely want to do like a security pass um before publishing. uh your uh your lovable app will always run like a basic security check and I think it runs it periodically while you're building as well. Um so run the security reviewer add rate limiting to your login and sign up endpoints that just helps people to like they can't DDoS your application while uh while it's in production so it's there and then validate all your inputs on the server and not just the form right server side security is really important because anybody can put in whatever they want on the input field but it shouldn't call your API or shouldn't call your database on the back end um you can run an SQL query very quickly um something googleable um I'll talk about it in a minute as well to make sure that you confirm that your RLS is actually on and by the end time when you're ready to ship and you're ready to you know publish your application on on like online preview the branch you want to enable autofix in your project settings and run a deep scan before you publish right go through the checklist we'll hit in the next couple of slides uh but lovable also has like a deep security AI reviewer on um that's available to you.

[00:14:09]I think that takes about I think the basic would take about like 10 to 15 seconds to run and the deep runs to like 2 to four minutes. So it takes a little bit of time comparatively but definitely like much easier than for you to run test cases one by one by one. Um so the key point here is right like you don't want security just to be like the one deep scan at the end and maybe you have like I don't know like 50 things to fix or 20 things to fix. You want to kind of go like weave it into every single phase and most of it should not cost you more than five to 10 minutes and hopefully like not too many tokens as well.

[00:14:47]Um, and a lot of the times like lovable is really great. There's they have a lot of good guidance as well. So if you want to look at how this is I when I was doing my research after the fact, this is a great blog site on like how lovable already does a lot of things for you. So kind of like I mentioned they have a cloud they have a database edge functions that are already secure from default. Walt for all your security uh for all your keys and your tokens and things like that. RS already exists. You just have to you know do a sanity check and make sure that it exists. There's audit locks for everything. If anything breaks you can always revert back to the last working version and you know work uh work from it afterwards. And also um Lovable does real time alerts. I don't remember if that was a thing when I was um doing it back in November, December, but since I've been building after that, it's just been great. Um I I personally from a security standpoint what I'm not, you know, stuck in the 48 hour timeline anymore. Um I try to fix the second something comes about, I fix it before moving forward. Generally good practice, but something to you know, something to consider based on your time constraints.

[00:15:54]Um there's also a security memory in um uh in uh Lovable. So basically the scanner will learn like your project's security profile over time. So you will have like fewer repeat flags of um smaller issues and more like relevant findings. Um I think I saw some stat about this specifically that it was like there was 20% 20 to 25% reduction um because of the security memory in like uh repeat like low like low hanging fruit findings. Um and another thing lovable already does for you that you should just you know validate if you want to they do run dependency checks on every edit of your application. So let's say you ask um lovable to build you like a PDF reader and it downloads some kind of library that reads PDF. Um this supply chain security is like a pretty big thing happening in most of in most web applications right now. So luckily lovable already does that for you. But something to be aware of while you're building. Um and then I just found out a couple of days ago autofix is an option.

[00:17:03]So if you go in your project in your project settings and right in the settings there's this thing called autofix security issues and you can turn it on or off if you are you know wanting to publish and ship something right in 48 hours I would recommend just turning it on um and it fixes like the no um uh it fixes issues that will not affect your build um so non-breaking changes only which is amazing.

[00:17:28]Um, and I kind of like I mentioned before, something to consider is that the basic scan uh runs it when it runs every single time when you publish or before publishing, but it's not the same as the deep scan. Basic scan would catch things like configuration issues and RLS and like the more the common stuff, but the deep scan will really help you get like the full AI powered review of your codebase. And it takes about two to four minutes at the maximum I would say. So definitely before publishing and going live I would recommend um uh you know pushing your deep scan and taking a few minutes there.

[00:18:09]Um now that you have all this information what are some things that you know differentiate between like a purely webcoded build versus like a security vcoded build. Here are some of the things right you would have like hidden elements in uh your UI versus like in a secure build you would have roles that you know constrain you like every single user from seeing XYZ if you're really consider consider like worried and uh considering RLS um another query you can run right now like if you have it open um and you have something built out is just run the SQL query and I'll share my slides after so you can copy paste it um run it I ran it this morning. All my tables, my nine public tables have RLS enabled. Great.

[00:18:52]Don't have to think about it after this.

[00:18:54]Um, a great resource for RLS and security uh in vibecoded apps is um this uh this application called vibeappscanner.com.

[00:19:04]I find the I found the guide on how to do it. It goes through multiple phases of like you know creating your RSL RLS rules. You can look into that if you want, but at the very bare minimum, you just want to make sure that this is RS is enabled in all your public tables.

[00:19:19]Bare minimum, very easy to do. One little prompt.

[00:19:24]Um, and while coming on to the end of this, here's just if you want to take a screenshot of this later or I'll send you the slides later. Want to build something securely, here are I would say eight check marks. And if you have this covered, I would say most of your application is probably you you should feel really secure about this. And since provide coding, you can prompt all of this. And I have prompts that you could use for um every single one of these um considerations. Um the categories here fall into the OASP category. So top 10.

[00:19:57]So this is I think two is crypto failures, whatever that might be. So you're targeting most of the OOP's top 10 categories. you're making sure the most common bipecoded um applications uh the vulnerabilities found in most common bioded applications are all covered should not take you more than a few minutes and all the prompts are right here. So again, don't need to be a security engineer. Just want to go through a fun checklist and you know, make sure and feel a little bit safer before like just personally feeling, you know, before you published. Um, and yeah, so I think realistically if you build it throughout your pipeline of your 48 hours, prompt it, let it go, come back and, you know, make sure it's fixed.

[00:20:40]Um, and that's that's pretty much my most my presentation. Um, I remember when I first went in um in season 2 thinking like worst case I don't submit anything, but I I'll get some experience. I'll get some free credits.

[00:20:53]Um, and I'll try to build something and learn how to prompt and pro, you know, make sure things are uh that I'm kind of keeping up with the trends of the world.

[00:21:02]Um, but I was able to submit something.

[00:21:04]It was a great feeling. But I do realize that the complete doesn't necessarily mean like when the app is like functional. It also means like when you like hand it off to a stranger or like when you publish it live that it won't like leak your data or like any sensitive data that you have saved in your um in your application. So three things before um before like I leave you guys definitely run lovable security scanner. It's there for you. It works within the platform, right? Why would we not use that to our advantage? Basic runs every time. Deep you want to run right before you publish. Um number two, check your superbase RLS. that's like a pretty big vulnerability in the vibe coded world. So um that should be on top of your framework. And then you also if you want you can add security like within your first prompt. So generally speaking like it saves in your security memory. It's being thought about like every single prompt going forward. So it's not coming in as like an afterthought.

[00:22:02]And that's it. I'll leave some time for questions. Um and if you want to connect with me on LinkedIn, I love talking about AI security and product security in general. um you can see, you know, reach out to me there. But yeah, leave some time for questions.

[00:22:14]>> Wonderful. That was great. And we do have it looks see like at least two questions. Um Kristen asked, "Can you show us where in lovable you're talking about um so probably where the security stuff is, it's uh over a lot of our heads. Um those of us who aren't security or tech oriented or tech experienced.

[00:22:38]>> Yeah. So number one, so in your projects, I have some none of them are like probably like projects I would publish yet, but there exists, right? So this is what I've built um when I was in season 2. I want to update it. But within your project, if you go settings and I think within general right here, so there's the autofix security issues right there in general. You definitely want to keep it on. Doesn't hurt to like it doesn't really do anything besides just work in the background for you.

[00:23:07]That's number one. Number two, within lovable it whenever like security issues pop up, it pops up right on the your like where you're prompting. So you can look at them here. I have a critical not going to publish this anytime soon. Um basic security scan again I like I said it happens every like it happens in the background for you for free. And this is where the deep security scan I would recommend to do before you go publish.

[00:23:32]Is there anything else I'm missing Whitney that would be interesting from a security standpoint that's on the platform? No, I mean you've touched on a lot of the new things we've added. Um, so as you can see uh in the bottom left above the chat box. Yeah. Um, you will be able uh to see it's like warning you in advance. Um, so we are trying to be very proactive.

[00:23:54]>> Um, you can also do that quick scan versus a deep scan. Um, as long as you go through the try to fix button and and select which ones you want to, it'll be free. it won't cost you anything. Um, if you want to go a step further, there is a connector called Iikido >> that does penetration testing.

[00:24:15]>> I personally still don't really understand it. So, I would just say that's for those who can can learn that.

[00:24:24]Um, power to you if you can. Um, we really really want it to be secure when you submit it. Um, so just try to address everything that is critical or an error. Warnings are more up to you because there will be things that um are warnings and are you're actually intending for them to be that way. Um, for example, with uh maybe uh uh maybe you're building a networking site and you want people's pictures to be shared, you would just have to click on it if you don't mind clicking on one sauna.

[00:24:57]>> Yeah.

[00:24:57]>> Um and open it up.

[00:24:59]>> Yeah. or or and then you would click ignore issue and just uh give an explanation as to why.

[00:25:07]>> Um uh we have a question. Marami asks would you recommend uh using superbase as an additional security layer? What are the advantages of using superbase versus lovable cloud only?

[00:25:21]>> So it really depends on like your use cases. I would say I think superbase just there's first of all there's like a natural integration with superbase already, right? that exists and as like a big company they're pretty I would say like their security policies are right already like established from like the front go for you both are great options there's nothing wrong either way it really just depends on your use case but either way it should work as long as you're you know following the basic security principles um superbase I just think having an additional layer always helps can't hurt um and since lovable has like a pretty good integration with it already it's um right there for So I will uh just to clarify you have to use one or the other. You can't use both. Um and cloud is very much superbase. It's just with lovable branding and a few different things. Um so just keep that in mind. Uh I haven't used superbase myself in quite a while.

[00:26:22]Uh, so you'll have to um you'll have to correct me if anyone knows and I'm wrong, but I know that whenever I was using it, there were some security things that couldn't be addressed in lovable and you had to go in superbase yourself and address.

[00:26:38]>> So just keep that in mind in case it's still the case.

[00:26:43]>> Um, and then can you give an example of how to scaffold security in the first prompt? What does that look like and what would good look like?

[00:26:53]>> Yeah, I think following even if it's like kind of like I was mentioning the oneliner of the top three things that I think that I've seen in vibe coded apps, right? Build this application with security in mind, right? build this application with RLS RLS enabled on all tables. Secrets uh your secrets are secure and your server side authentication I would say is like my number one go-to like very low hanging fruit findings like most findings are input validation or output validations or like issues or injections right there. Um, so that is my number one tip is like your first prompt or like when you're starting your project, add this oneliner for security and it should hopefully follow through and at the end. Um, and you know, do it from the every, you know, every what since it's a 48 hour like every few hours I would say try to check what's what's being built and how if it's been built securely or not.

[00:27:46]>> Great. And let's see. Um, when someone remixes another person's project, how does this affect the security keys?

[00:27:57]>> So, it doesn't affect security in any from a security standpoint, you're just inheriting what somebody has already built, right? So, whatever they have in terms of issues that already exists on your end. So from that standpoint, when you're remixing something and bringing something new into like your environment, I would do a check before you bring it in to see if there's anything that you're that you have existing. Number one, once it's remixed, right? Once you have it all in your environment, do another check to make sure you're addressing any security vulnerabilities before you start building on top of it and, you know, potentially creating more issues. So my again, my tip there would be just like start it from the get- go. the first prompt after you remix something, double check the security and like check the, you know, the security scan unlovable that has it and fix all those issues before you build on top of it.

[00:28:47]>> Yes. And and as far as the keys and secrets, those are all going to essentially be broken, which means when you remix, they don't carry on. You have to set up all the keys again and things like that.

[00:29:00]>> Yeah. This should never be transferred over. And that's the >> that's Yeah, I was gonna say if that's due, that's a really that's a different issue. That's not a you issue at that point.

[00:29:10]>> That that's a please let us know right away. Um and uh just so you know, um when you remix, which is when you take a project, either your own or someone has given you access to a project in settings, you can go into in the menu and go to remix. It's essentially saying like duplicate, copy and paste. Um and what it does is it makes a rep uh replication of that project minus the backend. the back end being the database tables, things like that and minus the security keys, the the layout, the how things are supposed to work, all of that remains, but you would have to but if you are using um an API for Google Docs, which we have a connector um but same thing here um if you'd have to go and reconnect it um and set up the database in the back end. Um, so just so you know what's what kind of transfers and replicates is the code, the uh infrastructure, not the data or your keys.

[00:30:22]And I just answered the next question.

[00:30:24]What does remix mean? So that worked.

[00:30:26]Um, all right. I don't see any other anything else, uh, Sana, before we leave.

[00:30:31]>> No. Oh yeah, I would love to connect with everyone who's, you know, I would love to meet I'm going to be active on Discord, so I'm going to, you know, see your questions and your projects. So, I'm really excited about everyone.

[00:30:40]>> Thank you so much. And thank you for being active in Discord. Um, I know that I heard a lot from season 2, how much it meant that season 1 was there. Um, so I'm sure both seasons being there for season 3 is going to be just as meaningful. Um, so appreciate you uh taking time today and for being supportive throughout this season.

[00:31:01]No, thank you so much >> everybody.