Security Fundamentals Course Intro

The number one issue that I've been seeing so far is misconfigured RLS or row level security. If you do any sort of vibe coding with AI or you've used Supabase or Firebase, you have probably heard of RLS. There's also been a ton of drama with vibecoded apps getting hacked, data breaches, all the data leaking. Almost every single headline that you've seen where this has happened is probably because of a misconfigured RLS. The way that apps are supposed to work is you have your front end which could be your application, and then you have a backend and then you have a database which is where all of the user data is being stored. Your front end should never talk directly to the database. It has to go through the backend to do that.

And then came Firebase and Supabase and their whole pitch was you don't need a backend to develop an app. They gave you these client libraries that you install on your app directly on the front end and your app can talk directly to the database securely. This was a very controversial thing because it goes against this whole front-end backend database architecture. Now obviously, this wasn't great from a security standpoint. So their solution was to add something called RLS, or in the case of Firebase, it's called Firebase Security Rules. What RLS does is it acts as a filter. So even though your app is talking directly to the database, RLS limits what it can access. You can set rules like a user can only access their specific data.

Without RLS, someone could hit your database and just download the entire thing. But when RLS is configured correctly, they should only be able to access their own data. But there is a huge problem - if you misconfigure this, it can be very devastating. Firebase actually had a huge issue with this. Previously, when you spun up a Firebase instance, their security rules were completely off. Everything was just open to view and download by default. They did this so developers could move faster. They tried adding a warning, but that wasn't enough. So many apps got hacked that they actually had to change their policy to automatically lock your database after a certain number of days.

In my case, for my calorie tracking app, I'm using Supabase and I was confident I configured RLS correctly. I even had Claude and Cursor double check it. But I made a big mistake. I had RLS configured correctly where users can read and write only their own data. But I made the mistake of storing the subscription status and the rate limits on the same table. Which meant that they were able to modify their subscription status to give themselves premium. And even worse, they were able to modify the rate limits and then they could just hit my AI endpoint unlimited and rack up a $10,000 bill.

I actually decided to audit a couple people's apps in preparation for this video. Some of the apps were vibe coded by nontechnical people, but a lot of them were actually vibecoded by people with technical experience, and over half of them had the exact same problem. I was able to manipulate the apps to give myself premium access. There was one instance I was able to download a user's entire table so I could see all the data on Supabase. I saw information I was absolutely not supposed to see.

My number one tip is to double check your RLS configurations. Not just in a general way like asking Claude Code 'hey, check my RLS configuration.' I mean in a very specific way - try to think through specific scenarios of where RLS will fail. Prompt it with very specific things like: can users bypass their subscription status? Can they modify their rate limits? Is there a scenario where a user can read another user's data? You have to be creative and do some critical thinking. I created a free markdown file with common scenarios - feed it into Claude Code and Cursor and ask it to audit your codebase.

The most common vulnerability pattern I'm seeing with RLS is storing sensitive data like subscription status or rate limits on the user table itself. Claude Code and Cursor just don't have a problem with you doing this. The second most common pattern is misconfiguration where users can see other people's data. And one more very important thing - if you're using Claude Code and Cursor, please use the Supabase or Firebase MCPs. Even if you're using AWS and Azure, use the CLI and give it to Claude Code and Cursor so it can audit the configurations directly.

Mistake number two is adding no rate limits. This is a huge one, especially if you have an app that has any sort of AI features. You might be thinking, well, I put limits on my front end, so they can only generate five generations a day. But the problem is, if someone finds your endpoint, they can bypass any limits you put on the front end because they're going directly to the back end. And finding those backend endpoints is not hard at all. Anybody can see this in the network tab. And yes, this does apply to mobile apps.

You need rate limits on the back end because front-end rate limits are not going to cut it. The way that I personally do it is I have per user rate limits. I store the number of generations a user has made on a table and the rate limits for that user also on the table. Every time someone calls the back end, I just check if they're within the limits. But remember mistake number one - make sure not to put the limits on the same table as the user data they're allowed to edit.

Another approach you can use in combination with per user rate limits is to add IP-based rate limiting. Set it up where a single IP address can only hit your backend endpoints a certain number of times per hour, per minute, per week. Even if someone spins up a million accounts and bypasses your user-based rate limiting, the IP-based rate limiter should stop them. Technically they can rotate their IP address with proxies, but at that point it's so costly it's usually not worth it.

Even if you don't have AI features, it's still good practice to add these limits because you don't want someone to unnecessarily spam your endpoint. If you're using Firebase and Supabase, these are still technically usage-based services. You're getting charged based on reads, writes, and bandwidth. Someone could hit up these services and rack up a huge bill. There are a lot of cases of people waking up to a $50,000 bill. So please add these limits even if you have no AI features.

Mistake number three is calling AI endpoints or other sensitive API calls directly from the front end. I have seen way too many people do this. I was calling things like Stripe directly from the front end. And yes, it's not just AI endpoints. It could be something sensitive like Stripe - someone can take that endpoint, manipulate prices or subscription tiers before it hits your server. I've also seen people calling email services like SendGrid and Postmark directly from the front end, which means someone can take those endpoints and start sending emails as you.

I've seen people call cloud storage providers like AWS S3 directly from the front end with hard-coded credentials. In some cases, this allows people to download and upload whatever they want to your S3 bucket. And obviously, the big really bad thing is people calling AI providers directly from the front end. If you have a photo generation service calling Vertex AI directly from your front end, someone can intercept your key and use it for whatever they want and rack up a huge bill.

The solution is very simple. Make sure that these calls are being done from your backend, not your front end. If you don't have a backend set up, this is where Supabase Functions and Firebase Functions come in. There's also a huge misconception, especially with mobile development, that if you put your API keys in an environment variable, it is just secure automatically. That is not the case. Most environment variables on all front ends are exposed. Environment variables are only safe on a backend.

Another issue I'm seeing is not adding budget caps. Whatever provider you're using, make sure to add a budget cap so that if you hit that budget cap, the services just shut off completely. It is so much better for your app to go down for a little bit than for you to wake up with a $10,000 bill.

This is kind of embarrassing, but I made a huge mistake a couple years ago where one of my environment variables got leaked - an AWS key that just had too many permissions attached. Absolutely no budget cap either. I woke up to a $30,000 bill where someone took the key and used AWS SageMaker to do machine learning training. I got lucky and the bill was waived to about $2,000. From that day forward, I started taking budget caps and hiding environment variables way more seriously.

Some services don't have budget caps. So at the bare minimum, make sure to have alerts set up where you get notified if you're approaching a budget cap. There are workarounds on services like Firebase where you can set something up to call the Google billing API and shut off spend automatically.

A question I keep getting is, is vibe coding and LLM coding inherently insecure? My honest opinion is no. I would actually argue that the apps where I used AI for coding are more secure than the ones I did a couple years ago by hand. I took Claude Code and Cursor, threw it at some of my old code bases, and there were so many vulnerabilities that it caught. LLMs can see things that a lot of humans miss. It can think through edge cases I wouldn't have thought of. And more importantly, it doesn't get fatigued.

When I was coding by hand, security was like the last thing I was thinking about. I was so tired just building features that I just didn't have enough time to think about it properly. When you're using AI for coding, not only does the LLM not get fatigued, but I am less fatigued as a developer. I have a lot more of a clear head to think through edge cases and have good conversations about security.

When I say vibe coding, I'm not talking about just shipping things without looking. That will always have inherent security issues, same as just coding by hand and not caring. The vibe coding that is more secure is where you know what's going on, you're in control, you can still move super quickly, but you at least care and are deliberate about security. My favorite conversations to have with Claude are the ones where we're deliberately talking about security - 'What about this scenario? What about prompt injection?' It gives me peace of mind when I ship something.

If you're watching this and thinking you need to check your app - grab the markdown file linked in the description, paste it into Claude Code or Cursor, and let it audit your codebase. Install the Supabase or Firebase MCP if you're using those services. Try to break your own app. Think like someone who wants to abuse your system. That alone will catch the majority of issues.

Again, this is not comprehensive. This is barely scratching the surface. This was just the common stuff that I've been seeing recently that I wanted to call out, especially with people who are vibe coding or building really quickly with AI. If you guys have any security tips or there's something that I missed that you really think I should cover in a part two, please leave a comment down below.