pov: you vibe coded an app in a weekend. it's live, but it's not secure.

Slide 1

pov: you vibe coded an app in a weekend. it's live, but it's not secure.

pov: you vibe coded an app in a weekend. it's live, but it's not secure. @tobi.the.og

Slide 2

0 0 0 1 1 0 1 0 0 0 1 1 0 0 0 0 1 0 0 0 1 1 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 0 0 1 1 1 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 1 1 1 0 0 1 0 0 0 1 1 0 0 0 0 1 1 1 1 1 0 1 0 the warning AI will help you ship faster than ever. it will not tell you when your app is a security disaster waiting to happen. that's on you. here's the checklist every vibe coder needs to go through before they ship. your AI can fix most of it. but you need to know what you're fixing. @tobi.the.og

Slide 3

1. exposed api keys API keys are the passwords your app uses to talk to other services. leave them exposed and someone else is using them - on your bill. if they're in a public github repo, bots are already scanning for them. right now. fix: - store keys in .env files only - add .env to .gitignore - use server-side calls (backend), not client-side (frontend) - rotate any exposed key immediately AI will write the code. it won't always remind you to hide your keys. @tobi.the.og

Slide 4

2. no rate limiting rate limiting controls how many times someone can hit your app per minute. without it, one bot can drain your server and your bank account. fix: • add rate limiting to every public endpoint • use upstash or express-rate-limit (both free) • set tighter limits on login pages specifically this is a 30 minute fix. skipping it is a $3,000 mistake. @tobi.the.og

Slide 5

3. input sanitization every text box in your app is a potential attack surface. input sanitization means checking what users send before your app does anything with it. SQL injection. XSS. prompt injection if you're using AI. all of these start with unchecked user input. fix: • never trust user input. **ever.** • validate everything server-side, not just in the browser • never build database queries by gluing strings together. • use the safe methods your database library provides. @tobi.the.og

Slide 6

4. RLS row level security (RLS) is the rule that says "user A can only see user A's data." skip it and every logged-in user can read everyone else's data. it also means a user could edit their own pricing tier or permissions directly. yes. that has happened to real products. fix: - enable RLS on every table. no exceptions. - write rules for who can read, add, edit, delete - test it by logging in with a second account - never rely on frontend checks alone - enforce at the database level if you're on supabase, RLS can be confusing. take extra care - the docs are your friend. not doing it is not an option. @tobi.the.og

Slide 7

the checklist before you ship, run through this: * API keys in .env, not in code * .env in .gitignore * rate limiting on all public endpoints * user input validated server-side * RLS enabled on every table * tested with a second account built something that does all of this automatically - i use it on my own apps. comment "ship" if you want in. @tobi.the.og

Slide 8

you probably won't see this page again. follow @tobi.the.og i build things, break things, and share everything in between.