So I’m going to describe a person this post is for, if this is you, I think I can be of some assistance:

  • you are new to coding
  • you are blown away by how it unlocks this magical ability that was previously inaccessible without years of training and effort
  • you’ve daydreamed of business and app ideas but never knew where to start before or how to build them
  • you’ve been vibe coding non-stop and burning through tokens
  • you’re unsure about what’s secure, where the common pitfalls are, and what to even ask the AI agent to verify

I also want to briefly talk about how I’m going to frame this post. It’s from the perspective I would have wanted if I were starting from scratch today. This is meant to be informational and helpful. A solid jumping off point without going too deep in the weeds. I remember the feeling of not knowing even where to start. Hopefully this will give some direction. My goal is to cover some security concepts from a high level and if by the end of this post you could explain them to a friend or (probably even more importantly) are able to ask Claude or your Agent about them for your specific use-case I will have succeeded.

Security is one bucket in the bigger picture of what makes an app real. If you haven’t seen the whole map yet, start here.

And now, onto it!

I will be using a hotel as a metaphor as I think it does a great job of conveying the concepts in a relatable way. I’d also like to highlight how they apply to web apps. I’m going to boil it down to the bare minimum and, when it comes to your vibe coded app, try to help you answer the question:

Who’s allowed in, what are they allowed to do, and is it safe?

Cool. Enough preamble. Let me set the scene. You are in charge of security at a fun beach-side resort. This place has got it all! I’m talking gourmet meals, full bar, live music, a spa, shops, a pool with a swim up bar and water slide. You name it. All sorts of really fun things, some included, some extra.

Now, with this cool beach-side resort you need a way for people to come in from out in the world and prove that they are supposed to be there and check-in. This is the lobby. You typically show a form of ID and give a credit card. After guests prove they are who they say they are, they are given a room key. This is authentication.

How this applies to web apps

This would be the public login page. Anyone can access it. They have to provide some sort of credentials like a username and password and they are given their room key (which under the hood is something like a token or a cookie).

Once the guest has checked in and is given a room key, they are authenticated. If they go to their room and swipe their key, it will unlock the door and let them in. If they go to the pool, they can swipe their key to get in there too. They have proper credentials. But the next question is, what else can they do with their key? And more importantly, what can they not do? This is authorization. If they take their key and try to swipe it at a staff-only room, (hopefully) it will not work. If they take their room key and swipe it on another guest’s room, you better hope it doesn’t work. So to boil it down: authorization is what a valid user is allowed to do.

How this applies to web apps

Just logging in (authentication) isn’t enough. There will be functionality that some users should have and other users shouldn’t. You’ll likely have admins who have special privileges (think housekeeping being able to unlock any room). If this isn’t given proper care and attention, users of your app could read and/or manipulate other users’ data. Not good!

So, to take it a little further, we have authentication (who’s allowed in), authorization (what they are allowed to do), but we still need to enforce those rules. Let me give a couple examples: let’s say a guest just checked in. They showed their ID and gave a valid credit card. They are a legitimate guest and now have a room key. A couple hours later, they come back to the front desk and say “I’m a valid guest here, you can check my room key, please give me the room key for room 102 as well”. That may seem a bit laughable from the perspective of a resort lobby but from a software perspective and from a vibe coded app, this is actually a very common trap.

How this applies to web apps

The server must enforce that the request being made is authorized to see that data or make that change. So if a user asks for another user’s data, they may have a valid token, but their token may not be allowed to see that other user’s data.

Second example: a guest goes to the Michelin Star restaurant, has a fantastic meal with a lobster stuffed into a steak stuffed into a duck and sprinkled with gold. It was incredible and cost $2000. “Not a problem!” The guest says. “Just charge it to my room, room 5!” Only, the user is not staying in room 5…

How this applies to web apps

These are both examples that fall under the umbrella of broken access control if you want to look it up and read more about it. There is also a principle relating to not trusting the client (the browser or mobile app, for example) and enforcing requests that comes from the client on the server itself. In the examples above that would be not allowing a user with a valid room key to ask for a different room key they are not entitled to have and also validating a user’s room number before allowing them to charge a meal to the room.

Now this next one is really common for beginners and especially common with vibe coding. It’s a concept that once again may seem absurd from the perspective of a hotel but that should tell you how important it is from the perspective of a web app. Here we go: you walk into the lobby (remember, the public place that anyone can access) and see a hotel key just sitting on the counter unattended. And right next to it a Resort Staff Credit Card. They’re just lying there so what the heck? You grab them, swipe the (what you find out to be) master key, go into the spa hot tub, and then proceed to buy $10,000 worth of fidget spinners from ebay on your phone (kind of weird, but hey it’s not your money!). In this case, the key and credit card represent sensitive credentials. Just as it would be dangerous and risky to leave those things accessible in a hotel, you need to protect your secrets.

How this applies to web apps

Alright, definitely a stupid example. But! It still proves the point. It is insanely common for credentials to be committed to public git repositories and/or to be hard-coded into the client for users or bad actors to find. What’s the worst that could happen? Well, imagine your app uses Claude via the API and a bad actor gets their hands on your api key.. it’ll probably cost you more than $10,000… protect your secrets and never put them anywhere public!

This post is already getting kind of long, so I think I’ll end with just one more. This one is aimed more at protecting yourself and your application from abuse. Let’s say that the resort has a bar/club/music venue that only has a finite amount of space and a maximum occupancy. It’s a Saturday night at 10:00pm and there is an incredible band playing. People can hear it from throughout the resort and it’s really popular! As people arrive, you likely have a bouncer at the door. That bouncer is there to make sure guests are over 21 (more authorization, but not the point of this example) and count the number of people who have entered and who have left the venue. Once it fills up, a line has to form and a person can only enter the venue when someone leaves. This is similar to the concept of rate limiting. Rate limiting is limiting the number of requests that can be made to your server to ensure that your resources are utilized properly and that your application can perform as intended.

How this applies to web apps

For your web app, you will likely be paying for some sort of server. That server will have a finite amount of memory and CPU available to serve all of your users. It also may make calls to APIs or services (like LLMs) that cost money per invocation. Without proper rate limiting, a bad actor (or even a surge of legitimate traffic) could overrun your server so it doesn’t work for anyone or rack up a huge bill if you have a cost associated with each request. Limiting the number of requests that you process will help mitigate this risk.

So! To conclude: my goal is that at this point you should have a high level understanding and be able to ask Claude for details regarding your app related to:

  • Authentication
  • Authorization
  • Access Control
  • Secrets Management
  • Rate Limiting

If not, please let me know and I’ll clarify as best as I can! If you also want a bigger list that you can give your agent, I’d encourage you to google the OWASP top 10. It’s a list of the top 10 security vulnerabilities that affect apps today.

Happy Tuesday and keep on vibin’!