Hai startup, hai kết cục

Technical Debt — Khái Niệm Bạn Biết Nhưng Chưa Hiểu Đủ

Security Debt Khác Technical Debt Thông Thường Ở Điểm Gì

• Mất toàn bộ early adopter
• Vi phạm quy định bảo vệ dữ liệu (PDPA tại Việt Nam, GDPR nếu có user EU)
• Mất khả năng raise funding — không investor nào muốn đổ tiền vào startup vừa bị hack
• Mất nhân sự — engineer giỏi không muốn làm việc với codebase mà họ biết là thiếu an toàn

Barry Boehm và Cái Giá Của Việc Sửa Muộn

• Sửa lỗi trong giai đoạn requirements/design: chi phí cơ sở = 1x
• Sửa trong giai đoạn coding: 6x
• Sửa trong giai đoạn testing: 15x
• Sửa sau khi đã release: 100x

Ba Quyết Định Kiến Trúc Mà Solo Builder Thường Làm Sai

• Dùng thư viện auth đã được audit: NextAuth, Passport.js, Auth.js, hoặc managed service như Clerk, Supabase Auth
• Password phải hash bằng bcrypt/argon2 — không phải MD5, SHA1, hay SHA256 thuần túy
• Session token phải có expiry hợp lý và phải invalidate được server-side khi logout
• Implement rate limiting trên login endpoint từ ngày đầu — brute force là attack cơ bản nhất

// ❌ Pattern sai — chỉ check user đã login
app.get('/api/documents/:id', requireAuth, async (req, res) => {
  const doc = await Document.findById(req.params.id)
  return res.json(doc)
})

// ✅ Pattern đúng — check user có quyền với resource cụ thể
app.get('/api/documents/:id', requireAuth, async (req, res) => {
  const doc = await Document.findOne({
    _id: req.params.id,
    owner: req.user.id  // Chỉ trả về nếu document thuộc về user này
  })
  if (!doc) return res.status(404).json({ error: 'Not found' })
  return res.json(doc)
})

# .env file bị commit vào git
DATABASE_URL=postgresql://admin:supersecret@localhost/prod
JWT_SECRET=myverysecretkey123
STRIPE_SECRET_KEY=sk_live_xxxxx

const stripe = new Stripe('sk_live_xxxxx') // ❌

• .env phải có trong .gitignore từ commit đầu tiên — không phải "sẽ thêm sau"
• Dùng environment variables hoặc secret manager (AWS Secrets Manager, Doppler, Vault)
• Rotate tất cả credentials nếu bạn không chắc chắn 100% chưa bao giờ commit

Security Invariants — Khái Niệm Bạn Cần Biết

• "Không có user nào có thể đọc data của user khác trừ khi được explicit grant."
• "Mọi input từ bên ngoài đều phải được validate trước khi xử lý."
• "Không có credential nào được hardcode trong source code."
• "Mọi action thay đổi data phải được log với timestamp và actor."

1. Hỏi: "Data nhạy cảm nhất trong app của tôi là gì?" (PII, payment info, private content)
2. Hỏi: "Thứ tệ nhất có thể xảy ra nếu data đó bị lộ?"
3. Hỏi: "Điều gì phải luôn đúng để điều đó không xảy ra?"
4. Viết ra 4-5 câu khẳng định — đó là invariants của bạn
5. Review lại chúng mỗi khi thêm feature mới có ảnh hưởng đến data model

Vibe Coding + Security Debt — Nhân Tố Nhân

Minimal Security Baseline Cho Solo Builder

• Xác định 4-5 security invariants cho domain của bạn
• Setup .gitignore đúng cách, không bao giờ commit .env
• Chọn managed auth solution thay vì tự viết

• Mọi query lấy data đều filter theo owner — đây là convention, không phải option
• Dùng ORM với parameterized query — không bao giờ string concatenation trong SQL
• Thiết kế data model với tư duy "ai được phép xem table này?"

• Authentication + Authorization tách biệt và nhất quán
• Validate input ở layer nhận — không tin tưởng bất kỳ thứ gì từ client
• Rate limiting trên mọi endpoint public, đặc biệt auth endpoint

• Chạy OWASP ZAP hoặc tương đương để scan một lần
• Review tất cả environment variable — không có gì hardcode
• Có kế hoạch "nếu bị breach, tôi làm gì trong 24 giờ đầu?"

Câu Hỏi Đúng Không Phải Là "Khi Nào Làm Security"