How not to leak user data: basic security for Vibcoders

Imagine: you made a pet project – a bot store, a dashboard for freelancers or a simple SaaS. Everything works, people register, leave an email, a phone, pay money. And then one day, you get a letter saying, "We have a leak, your data is public.".

Just because you use Supabase, NextAuth or Clerk doesn’t mean you’re automatically safe. We need to set it right. Let's go.

## Why even a simple pet project can leak data

Your users trust you:

• email and password
• phone
• payment
• personal photos and documents

If the data leaks, it's not just "oh, sorry." These are complaints, loss of trust, and at worst, fines (in Russia and Europe, they are punished for this).

The most common causes of leaks in Vibcoders in 2026:

1. Passwords are stored in open form
2. The API is available to everyone (without checking who you are)
3. Secrets (keys) are in the code on GitHub
4. There is no protection against “password brutes”
5. SQL injections or XSS

The good news is that all this is solved by 8-10 simple rules. And AI will help you implement them in one evening.

## Rule 1. Never keep your passwords open 2

What do you do? Use hashing. This is when the password turns into a “porridge” that cannot be restored back.

The best options in 2026:

• Argon2id is the strongest now (OWASP recommendation)
• bcrypt - a little easier but still great
• scrypt is also a good one

Example in code (Next.js + Supabase) Supabase does this automatically upon registration. Just DO NOT use supabase.auth.signUp with a raw password in your database!

Example in FastAPI + Prisma:

from passlib.context import CryptContext

pwd_context = CryptContext(schemes=["argon2"], deprecated="auto")

def hash_password(password: str) -> str:
    return pwd_context.hash(password)

# При регистрации:
hashed = hash_password(user_password)

Prompt for AI: «Используй только Argon2id для хэширования паролей. Никогда не храни пароль в plaintext. Покажи пример регистрации пользователя.»XX

## Rule 2. Always use HTTPS (SSL)

In 2026, without HTTPS, your browser will mark your site as “not secure.”.

How to do it in 2 minutes:**

• On Vercel / Railway / Render – switched on automatically
• A free certificate from Let’s Encrypt
• In Supabase, everything is already with HTTPS

Prompt for AI: «Установи SSL сертификат на домен [название домена] от Let's Encrypt.»XX

** Check: * Go to your website and look at the lock in the address bar. It should be green.

## Rule 3. Keep secrets (API keys, JWT secrets)

Don't ever do that

#.env in the repository
SUPABASE KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Do this:

• .env add to .gitignore
• In production, use:
  • Vercel - Environment Variables
  • Railway → Variables
  • Docker Secrets / GitHub Secrets

Prompt for AI: “Never commit .env. Show me how to read the secrets from environment variables in Next.js and FastAPI

Новые модели очень хорошо справляются с безопасностью, но лучше это контролировать вручнуюXX

## Rule 4. Protect APIs from Others (Authentication + Authorization)

"Authentication" - "Who are you?" Authorization - "What can you do?"

The easiest and safest options in 2026:**

Example of route protection in Next.js (App Router):

// middleware.ts
import { createMiddlewareClient } from '@supabase/auth-helpers-nextjs'

export async function middleware(req) {
  const res = NextResponse.next()
  const supabase = createMiddlewareClient({ req, res })
  const { data: { user } } = await supabase.auth.getUser()
  
  if (!user && req.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', req.url))
  }
  return res
}

## Rule 5. Row Level Security (RLS) in Supabase is your superpower

It's the magic of PostgreSQL. The user sees only their data.

** Example of policy:**

The user sees only his orders.
create a policy "Users can view own orders"
on orders for select
using (auth.uid() = user id);

AI generates such policies very well. Just tell them, “Write RLS policies so the user can only see their data.”.

## Rule 6. Protection against overcrowding (Rate Limiting)

So the bot doesn't go through passwords.

In Next.js:

import rateLimit from 'express-rate-limit'

const limiter = rateLimit
windowMs: 15 * 60 * 1000, // 15 minutes
max: 5 // maximum 5 entry attempts
}

** In FastAPI:** Use slowapi or fastapi-limiter.

## Rule 7. Validation of all data at the entrance

Never believe what comes from the user.

In Next.js:

import { z } from 'zod'

const registerSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8).max(100)
})

** In FastAPI:**

from pydantic import BaseModel, EmailStr

class UserCreate(BaseModel):
    email: EmailStr
    password: str

## Rule 8. Do not store excess in a JWT token

Bad example:

{
"userId": "123",
"email": "user@example.com",
"isAdmin: true,
"PasswordHash": "..." // ← NOT!
}

Good:

{
  "sub": "123",
  "role": "user"
}

The rest of the request is from the userId database.

## Rule 9. Protection against XSS and CSRF

• In Next.js, everything is automatically protected (if you use Server Components)
• In HTML, use escaping
• For forms – CSRF tokens (NextAuth makes itself)

## Rule 10. Regularly update dependencies

In 2026, vulnerabilities are found every week. Use it:

• npm auditXX
• dependabot on GitHub
• Renovate

## Ready-made prompt for AI so that it immediately writes safe code

When writing any code, always follow:
1. Argon2id for passwords
2. Never log sensitive data
3. Rate limiting on all auth-endpoints
4. RLS at Supabase
5. Validation via Zod/Pydantic
6. Secrets only through env

Task: [Describe your feature]
First, list all the security measures you will use.
Then write the code.

## Checklist before depletion (copy and mark)

• Passwords are hashed (Argon2id)
• HTTPS enabled
• .env at .gitignore
• Rate limiting on login/registration
• RLS politicians set up
• All API routes are protected by user verification
• No sensitive data in JWT
• Validation of all forms
• npm audit clean
• Test account verified

## What to do if something has already been leaked

1. Change all passwords immediately (and ask users)
2. Disable the compromised keys
3. Add a notification to users
4. Turn on 2FA wherever possible
5. Analyze what exactly leaked