The Vibecoder  Diaries logo

The Vibecoder Diaries

Archives
January 8, 2026

New post: Users Are Sacred, Security Is Non-Negotiable

Users Are Sacred, Security Is Non-Negotiable

Every infosec guide focuses on the what and how—after all, the authors live and breathe the why—but do you? Why do you think this is important?

Data breaches, attacks, doxxing—these are personal, actual. They are events that happen to real people like you and I.

Imagine you signed up for a meditation app, you answered some questions, gave your phone number. Now you're getting more robocalls, no biggie, it's whatever, then some stranger tells you your daughter has been kidnapped and to pay a ransom. You don't even have a daughter but you still hear a kid's voice in the background. It's a scam, you know it is, but the man with a daughter doesn't. It gets worse, you start getting emails from some service you never signed up for, and one day, you are on a call with the bank disputing a charge and they sort of don't believe you.

I don't often talk about this—I used to have a stalker. It terrified me. I had to leave behind a big part of my digital identity at the time, I had to play defense, make it seem like I lived elsewhere. I got lucky, I got out unharmed but not unshaken. I'm still afraid of unknown numbers, I hide my face. I don't like cameras. It fucked me up. And I'm not the only one.

Think of every life ruined by doxxing, of every person whose private moments got exposed. Maybe you're part of the generation that grew up with no expectation of online privacy. Back in the early days of the internet you never gave out your name, not even your state or region. But then Facebook came along—sure there were others, but Facebook started this trend of having your name, your family, your data exposed. It's no wonder privacy isn't seen as a necessity nowadays. Lots of people grew up on the fallacy of "if you have nothing to hide, you have nothing to fear."

So lots of people grew up on this idea, forgot bad actors were a thing, and now, now they are stuck playing defense.


So now you are building your app. You want tons of users, you want people to love your product and gush about it to their friends. Security experts say the phrase "due care and due diligence"—if the wording is too delicate for your sensibilities, call it giving a fuck. You want users to love your app? You want trust? You gotta do the work, and that starts with actually caring.

Caring about security is the unseen part of UX. It is the foundation of trust. And it's not as hard as you think.


The Crash Course

So, because we care we are gonna learn, and since you are most likely building with AI, we are gonna keep this actionable. First, you need to understand a few concepts—nothing major, just so you know what the literature and videos are saying. Yes the AI is gonna do the work here and yes you can ask it questions, but we all need a primer.

The Vocabulary

Threat actors / bad actors - the bad guys, the villains, the trolls, or the bored kids with a script that may have been vibecoded.

Attack surface - everywhere your app can be poked at; every input, every endpoint, every form field.

Attack vector - the specific way someone gets in; the door they pick, the window they break.

CVE - Common Vulnerabilities and Exposures; the public list of known security holes with IDs like CVE-2024-1234. If your dependency has one, update it.

OWASP Top 10 - the industry standard "here's what goes wrong most often" list; your AI knows it by heart.

High ROI First Steps

Now that you got the lingo, let's get started on some high ROI items. First, you need to check what your app depends on. Using React? Check for React CVEs and check your versions. Using Netlify? Check how their security is doing. Ask the AI agent to research and cite sources—this will make the AI check current events and data instead of relying on pre-cutoff data.

Security Essentials

Input validation - never trust anything that comes from outside your code. Users lie, bots lie, forms lie. If someone can type it, paste it, or send it, assume it's hostile until proven otherwise.

Authentication vs Authorization - authentication is "who are you?" (login). Authorization is "what are you allowed to do?" (permissions). Mixing these up is how you get users accessing other users' data.

SQL injection - when user input becomes part of a database query and someone types '; DROP TABLE users;-- instead of their name. Use parameterized queries. Your AI knows how.

XSS (cross-site scripting) - when someone injects a script into your page that runs for other users. That comment field? Someone will put <script> tags in it. Sanitize your outputs.

Secrets management - API keys, database passwords, tokens. Never in your code. Never committed to git. Use environment variables, use .env files that are gitignored, and rotate them if they leak.

Rate limiting - don't let someone hit your API 10,000 times in a minute. Bots will try. Scrapers will try. Angry ex-users will try. Put a cap on how many requests one user/IP can make in a time window.

HTTPS - data traveling between your user and your server should be encrypted, not readable by anyone listening in. HTTPS comes with most providers by default—Vercel, Cloudflare Pages, Netlify, etc. If you're hosting on your own VPS, set it up yourself (Let's Encrypt is free, there's no excuse).

Principle of least privilege - sounds fancy, boils down to: whatever is doing the thing only has the minimum permissions required to do the thing. If I'm delivering your DoorDash order you don't give me your house keys. If I'm at the cash register you don't hand me your wallet, you swipe your card or give me the closest amount in cash. Same with code—your frontend doesn't need database admin access, your API route doesn't need to read every table.


Working With AI For Security

Your starting point with AI—in your coding agent, paste this:

Security Audit Request

Perform a thorough security review of this codebase. Be paranoid - assume everything is broken until proven otherwise.

Tailor your explanations to my technical level and use appropriate metaphors to explain complex concepts.

1. AUTHENTICATION & AUTHORIZATION
   - How do users prove who they are?
   - How is access to resources controlled?
   - Can users access other users' data?
   - Are there any endpoints that skip auth checks?

2. INPUT HANDLING
   - Where does user input enter the system? (forms, URLs, API params, file uploads)
   - Is all input validated and sanitized?
   - Check for SQL injection, XSS, command injection vectors

3. DATA EXPOSURE
   - What sensitive data exists? (emails, passwords, PII, payment info)
   - Is it encrypted at rest and in transit?
   - Are API responses leaking data they shouldn't?
   - Check for exposed .env files, hardcoded secrets, verbose error messages

4. DEPENDENCIES
   - List major dependencies and their versions
   - Flag any with known CVEs
   - Note anything outdated

5. ACCESS CONTROL
   - Are admin functions properly protected?
   - Is there rate limiting on sensitive endpoints?
   - Can actions be replayed or forged?

Report findings by severity (CRITICAL / HIGH / MEDIUM / LOW) with specific file paths and line numbers. For each issue, explain what an attacker could do and how to fix it.

Fixing What You Find

Now that you run your audit you are gonna see items to fix. That is normal—even before AI, humans made mistakes, gross oversights. But with due care comes due diligence, so now we fix.

As much as we are vibing our way through this, we are learning why things went wrong. We need to understand the root cause of things. Sometimes it's from our previous carelessness, sometimes it's because AI defaulted to certain patterns. It's important that we do not internalize the shame, just the lessons. Mistakes are expected. We can only grow and learn, and limit the damage they can do.

So now you have action items. Go by priority, fix the most critical ones.

One by one. It's tempting to one-shot and try to prompt for "make my app secure" but that's not how it works. You need to give AI constraints. Security is about knowing what risks can be taken and what risks cannot. If we wanted absolute security we would not have anything public. It's about reducing attack surface—like making your hitbox smaller.

Work on each one by one. Ask why it happened. Document it.

Example: Login form had no client-side input validation. Why: We assumed the auth provider did it but we didn't check.

Example: API endpoint returned full user objects including email and location. Why: We reused the internal database model for the API response, never created a filtered version for public consumption.

Example: Admin route had no authentication check. Why: Built it quickly for testing, meant to "add auth later," shipped without it.


Staying Vigilant

So, we did our due diligence, but the work is never fully done. Security is necessary, it requires constant vigilance. It's a loop of evaluate/audit, resolve, test/check functionality. That's the meat of it, now for the potatoes.

Bad actors don't sleep—well, their scripts and automated tools don't. We must be proactive in our security. Part of caring means caring to check in and pay attention.

So, aside from auditing periodically, we monitor for strange activity. Is your homepage getting hit a lot with weird looking traffic? Your app could be yoga for soccer moms in the midwest and suddenly you get 10k hits from Estonia. Nothing against soccer moms in Estonia, though I guess they call it football in Europe. Traffic spikes from launches are one thing, but we are talking about this having no natural explanation. Most users don't have a VPN, certainly not in that country. Or maybe someone is hitting your endpoints for payment, maybe their response is unbelievably slow.

When you have this knowledge you can act fast and defend, and eventually set up automated systems to do so. Most web providers like Vercel do defend for you, so you won't need to have your own dashboard or alerts but you will need to check in here and there. And you need to know what's going on.


A Quick Word on AI Chat Interfaces

It's its own article series, one I will write, but the basics are the same: sanitize those inputs and check for known attack patterns. Ask your AI agent to build systems to defend against prompt injection.


Security Is Not a Cost Center

Security isn't a cost center. It's not a drag or a corner to cut. It's what separates "We are shutting down" from "We had 20 minutes of downtime, an incident was detected and handled, user data is safe and the threat actors were identified."

I don't know about you but I would rather give a million boring briefings than say the app is FUBAR.

Security is layers that reduce risk, each building on the last.


Go Do It

The moment you finish this article you go to that coding agent. You know what to do. You know what to learn.

If you take one thing from this article: start caring and learn to do something that turns care into action.

That's what infosec is. Care turned into action.


Read on vibecoder.date

Don't miss what's next. Subscribe to The Vibecoder Diaries:
Share this email:
Share on Twitter Share on Reddit Share on Bluesky
blog.vibecoder.date
Powered by Buttondown, the easiest way to start and grow your newsletter.