Khi "cứ chạy được là ship" gặp đúng thời đại AI viết code hộ.

Mấy tháng nay lướt Facebook, X hay LinkedIn, kiểu gì cũng gặp một bài khoe kiểu: "Mình vừa dựng xong một SaaS trong 3 tiếng, không viết một dòng code nào, chỉ nói chuyện với AI thôi". Kèm theo là video demo mượt mà, vài trăm like, và phần comment đầy người xin link, xin prompt.

Thú thật là lần đầu xem mình cũng thấy phấn khích. Một ý tưởng nảy ra buổi sáng, buổi tối đã có sản phẩm chạy thật, có giao diện đẹp, có đăng nhập, có thanh toán. Ngày xưa để làm được vậy cần cả một team và vài tuần.

Nhưng làm nghề DevOps đủ lâu thì phản xạ nghề nghiệp kích hoạt rất nhanh. Xem demo xong, câu hỏi đầu tiên trong đầu mình không phải "wow, hay quá" mà là:

"Ok, thế cái này lưu mật khẩu ở đâu? API key để ở đâu? Ai được đọc database này?"

Và phần lớn thời gian, câu trả lời là... không ai biết. Kể cả người làm ra nó.

Hôm nay mình muốn ngồi nói chuyện nghiêm túc về chuyện này: vibecoding, cái trend đang rất hot, và bảo mật, cái thứ đang bị bỏ quên một cách có hệ thống.

Vibecoding là gì, và tại sao nó hấp dẫn đến vậy?

Thuật ngữ "vibe coding" được Andrej Karpathy phổ biến đầu năm 2025. Ý tưởng cốt lõi: bạn mô tả thứ mình muốn bằng ngôn ngữ tự nhiên, để AI sinh code, chạy thử, lỗi thì dán lỗi lại cho AI sửa, và hạn chế tối đa việc đọc hay hiểu code mà nó viết. Bạn "cảm" theo vibe, chứ không "kỹ" theo từng dòng.

Nói thẳng nhé: mình không phản đối vibecoding. Nó là một bước tiến thật sự:

  • Hạ rào cản gia nhập. Người làm marketing, designer, giáo viên, chủ shop nhỏ giờ có thể tự dựng công cụ cho mình.
  • Prototype cực nhanh. Thử một ý tưởng trong vài giờ thay vì vài tuần.
  • Tự động hóa việc vặt. Mấy script nhỏ, tool nội bộ, trước đây "để sau" mãi giờ làm được trong một buổi chiều.

Vấn đề nằm ở chỗ khác. Vibecoding khiến việc tạo ra phần mềm trở nên dễ dàng, nhưng trách nhiệm với phần mềm đó thì không hề nhẹ đi chút nào. Khi bạn đưa một ứng dụng lên internet, có người dùng thật, có dữ liệu thật, thì bạn không còn là người chơi hobby nữa. Bạn đang vận hành một hệ thống, và hệ thống đó sẽ bị quét, bị thử, bị tấn công, thường là trong vòng vài giờ sau khi public.

"Chạy được" không có nghĩa là "an toàn"

Đây là cái bẫy tâm lý lớn nhất. Khi vibecode, thước đo thành công duy nhất là: app có chạy không? Nút bấm được, trang load được, dữ liệu hiện lên được là xong.

Nhưng một ứng dụng có thể chạy hoàn hảo trong khi:

  • Bất kỳ ai cũng đọc được toàn bộ dữ liệu người dùng chỉ bằng cách đổi một con số trên URL.
  • API key trả phí của bạn nằm lù lù trong code phía client, ai bấm F12 cũng thấy.
  • Trang admin không cần đăng nhập, chỉ "ẩn" nút đi thôi.
  • Form nhập liệu cho phép chèn nguyên đoạn SQL hoặc script độc hại.

Tất cả những lỗi này không làm app hỏng. Chúng nằm im đó, chờ một người đủ tò mò hoặc đủ ác ý đi ngang qua.

AI cũng không khác gì một dev junior rất nhanh, rất tự tin, và rất muốn làm vừa lòng bạn. Bạn bảo "làm cho tôi chức năng đăng nhập", nó sẽ làm chức năng đăng nhập chạy được. Nó không tự nhiên dừng lại hỏi: "Bạn đã nghĩ tới việc giới hạn số lần thử mật khẩu chưa? Token hết hạn sau bao lâu? Có cần chống CSRF không?" Trừ khi bạn biết để hỏi.

Và đó chính là mấu chốt: bạn không thể yêu cầu AI bảo vệ thứ mà bạn không biết là cần được bảo vệ.

Những "đặc sản" lỗi bảo mật của code vibecode

Mình đọc khá nhiều repo và ứng dụng kiểu này, từ cả đồng nghiệp lẫn các bạn trong cộng đồng gửi nhờ xem hộ. Có những lỗi lặp đi lặp lại đến mức mình gần như đoán trước được.

1. Secret nằm sai chỗ

Cái này kinh điển nhất. API key, token database, secret của dịch vụ thanh toán được hardcode thẳng vào code, rồi commit lên GitHub, thậm chí là repo public. Hoặc tệ hơn, được nhét vào code frontend vì "AI bảo làm vậy cho nhanh".

Hệ quả thì quen thuộc: có bot chuyên quét GitHub 24/7 để tìm key bị lộ. Có người từng mất vài trăm đô la tiền cloud chỉ sau một đêm vì key bị lấy đi đào coin hoặc gọi API ké.

2. Database không có phân quyền đúng nghĩa

Các nền tảng backend-as-a-service như Supabase hay Firebase rất tiện cho vibecoding. Nhưng chúng dựa nhiều vào việc bạn tự cấu hình quy tắc truy cập (Row Level Security, security rules). Nếu bỏ qua bước này, hoặc để chế độ "cho phép tất cả" để test rồi quên bật lại, thì database của bạn thực chất là mở toang.

Đây không phải chuyện lý thuyết. Đã có những lỗ hổng được công bố liên quan đến việc các ứng dụng sinh ra bởi công cụ AI thiếu cấu hình RLS, khiến dữ liệu người dùng có thể bị đọc từ bên ngoài. Với ai quan tâm, có thể tìm thêm về trường hợp liên quan tới Lovable (CVE-2025-48757) để thấy vấn đề này thực tế đến mức nào.

3. Kiểm tra quyền chỉ ở giao diện

Kiểu "nút Xóa chỉ hiện ra với admin" nhưng API phía sau thì ai gọi cũng được. Đây là lỗi broken access control, luôn nằm trong top của OWASP. Giao diện chỉ là lớp trang trí, quyền hạn phải được kiểm tra ở server.

4. Tin tưởng input một cách ngây thơ

Không validate, không sanitize, ghép chuỗi thẳng vào câu truy vấn. SQL injection, XSS, path traversal, những lỗi từ thời "cổ đại" vẫn sống khỏe, và code do AI sinh ra đôi khi vẫn tái hiện chúng, nhất là khi prompt chỉ nhắm vào "làm cho chạy".

5. Dependency "ma"

AI đôi khi bịa ra tên thư viện không tồn tại. Kẻ xấu biết điều đó và đăng ký sẵn những tên package này với mã độc bên trong, chờ người dùng npm install hay pip install theo gợi ý. Kỹ thuật này có tên riêng là slopsquatting. Chưa kể việc cài thư viện cũ, không bảo trì, đầy lỗ hổng đã biết chỉ vì model được huấn luyện từ dữ liệu cũ.

6. Cấu hình mặc định và môi trường dev bị mang ra production

Debug mode còn bật, CORS mở *, port database lộ ra internet, tài khoản admin/admin còn nguyên. Đây không phải lỗi của AI, mà là lỗi của việc không biết đến sự tồn tại của khái niệm "hardening".

Số liệu nói gì?

Mình không thích dọa người bằng số liệu mơ hồ, nên chỉ nói điều mình khá tự tin: nhiều nghiên cứu và báo cáo từ các hãng bảo mật trong 2025 (như báo cáo của Veracode) đều đưa ra kết luận tương tự: một tỉ lệ đáng kể code do AI sinh ra chứa lỗ hổng bảo mật, và các model mới hơn, lớn hơn không tự động an toàn hơn. Bạn nên tự đọc nguồn gốc để nắm con số cụ thể, nhưng xu hướng chung thì khá nhất quán.

Điều này cũng không có gì lạ. Model học từ code ngoài internet, mà code ngoài internet thì... không phải lúc nào cũng an toàn. Nó học cả những đoạn Stack Overflow viết vội, cả những repo demo "đừng dùng cho production".

Vì sao chuyện này đang bị bỏ quên?

Mình nghĩ có mấy lý do, và không lý do nào là "người dùng ngu" cả.

Thứ nhất, FOMO. Ai cũng sợ bị bỏ lại phía sau. Thấy người ta ship app trong một cuối tuần, mình cũng muốn ship trong một buổi tối. Dừng lại để nghĩ về bảo mật nghe như đang làm chậm bản thân.

Thứ hai, bảo mật là thứ vô hình. Khi làm đúng, không có gì xảy ra cả. Không ai khen bạn vì "hôm nay không bị hack". Còn tính năng mới thì có người dùng, có like, có phản hồi ngay. Cái gì nhìn thấy được sẽ luôn thắng cái không nhìn thấy được.

Thứ ba, ảo giác năng lực. Khi AI viết ra code trông rất chuyên nghiệp, có comment, có cấu trúc thư mục đẹp, ta dễ nghĩ rằng "nó biết mình đang làm gì". Sự tự tin của AI lây sang người dùng.

Thứ tư, nội dung truyền thông chỉ nói một nửa. Hầu hết video và bài viết về vibecoding dừng ở khoảnh khắc "app chạy rồi". Hiếm ai làm video "tuần sau khi bị lộ database, mình đã xử lý như thế nào".

Cái giá thật sự khi sự cố xảy ra

Nếu bạn nghĩ "app của mình nhỏ, ai thèm hack", thì hãy nhớ: kẻ tấn công đa số không nhắm vào bạn. Họ chạy công cụ quét tự động trên toàn internet, và app của bạn chỉ là một con số trong danh sách.

Khi sự cố xảy ra, cái giá không chỉ là tiền:

  • Dữ liệu người dùng bị lộ: email, số điện thoại, đôi khi cả thông tin nhạy cảm hơn. Đây là thứ không thể "rollback".
  • Trách nhiệm pháp lý: lưu dữ liệu cá nhân của người dùng là có nghĩa vụ bảo vệ chúng, kể cả khi bạn chỉ là một cá nhân làm sản phẩm phụ.
  • Mất uy tín: một lần lộ dữ liệu có thể giết chết một sản phẩm non trẻ.
  • Hóa đơn bất ngờ: key cloud bị lộ có thể ngốn sạch ngân sách trong vài giờ.

Và còn một mặt khác cũng đáng nói: khi agent AI có quyền chạy lệnh trên môi trường thật, rủi ro không chỉ đến từ bên ngoài. Đã có những vụ việc được công khai trong đó một AI agent xóa nhầm cơ sở dữ liệu production dù đã được dặn đừng thay đổi gì. Cấp quyền rộng cho AI cũng là một bề mặt tấn công, hoặc ít nhất là một bề mặt tai nạn.

Vậy phải làm sao? Không vibecode nữa à?

Không. Mình không có ý kêu gọi quay lại thời gõ từng dòng code. Mình chỉ muốn bạn vibecode có ý thức. Dưới đây là checklist mà mình thấy thực tế, không đòi hỏi bạn phải thành chuyên gia bảo mật.

Trước khi ship, tự hỏi 5 câu

  1. Dữ liệu nhạy cảm của mình nằm ở đâu và ai đọc được nó?
  2. Secret (API key, token, mật khẩu DB) có nằm trong code hoặc repo không?
  3. Mọi quyền hạn có được kiểm tra ở phía server không, hay chỉ ẩn nút ở giao diện?
  4. Mình có hiểu mọi dependency đang dùng, và chúng có thật, còn được bảo trì không?
  5. Nếu app này bị tấn công vào ngày mai, mình sẽ biết bằng cách nào? (log, cảnh báo)

Nếu không trả lời được câu nào, đó chính là chỗ cần xử lý đầu tiên.

Những thói quen nhỏ nhưng đáng giá

  • Dùng biến môi trường và secret manager thay vì hardcode. Bật secret scanning trên GitHub, cái này miễn phí.
  • Thêm .gitignore đúng ngay từ đầu, đặc biệt cho file .env.
  • Bật và kiểm tra RLS/security rules nếu dùng Supabase, Firebase hay tương tự. Test thử bằng một tài khoản khác xem có đọc được dữ liệu của người khác không.
  • Cài công cụ quét tự động: Dependabot, npm audit, pip-audit, Trivy, Semgrep, gitleaks. Chạy trong CI là tốt nhất, chạy tay còn hơn không.
  • Không dùng quyền admin tràn lan cho AI agent. Cho nó môi trường dev, dữ liệu giả, quyền tối thiểu. Production thì tách riêng.
  • Giới hạn tốc độ (rate limiting) và đặt hạn mức chi tiêu (budget alert) cho các dịch vụ trả phí.
  • Dùng HTTPS, bật cookie HttpOnly/Secure, không tự chế hệ thống xác thực nếu có thể dùng dịch vụ có sẵn.

Dùng chính AI để review bảo mật, nhưng đúng cách

Mình thấy nhiều người không nghĩ ra điều này: AI không chỉ là người viết code, nó còn là người review khá ổn nếu bạn hỏi đúng. Thử một prompt kiểu:

Hãy đóng vai một chuyên gia pentest. Review đoạn code này theo OWASP Top 10.
Liệt kê từng lỗ hổng tiềm năng, mức độ nghiêm trọng, cách khai thác,
và cách sửa. Đặc biệt chú ý: xác thực, phân quyền, xử lý input,
quản lý secret và cấu hình database.

Lưu ý: đây là lớp kiểm tra bổ sung, không phải bảo hiểm. AI review cũng có thể bỏ sót, nên đừng coi nó là dấu chấm hết.

Và quan trọng nhất: học một chút

Bạn không cần học thành chuyên gia. Chỉ cần nắm khoảng vài khái niệm nền: xác thực vs phân quyền, OWASP Top 10, nguyên tắc đặc quyền tối thiểu, và vì sao không bao giờ tin input từ người dùng. Chỉ vài tiếng đọc những thứ này sẽ giúp bạn biết mình không biết gì, và đó là bước đầu của mọi sự an toàn.

Gửi các bạn đang vibecode

Mình viết bài này không phải để dội nước lạnh. Mình viết vì thấy có quá nhiều bạn nhiệt huyết, sáng tạo, đang làm ra những thứ thú vị, nhưng vô tình đặt người dùng của chính mình vào rủi ro mà chưa hề hay biết.

Có một câu mình hay nhắc đồng nghiệp: tốc độ không phải kẻ thù của bảo mật, nhưng sự vô tâm thì có. Bạn hoàn toàn có thể ship nhanh và ship an toàn, miễn là dành ra 30 phút trước khi bấm nút deploy để đi qua checklist ở trên.

AI sẽ tiếp tục viết code giỏi hơn. Nhưng câu hỏi "thứ này có an toàn để đưa cho người thật dùng không?" vẫn là câu hỏi cần một con người trả lời, và chịu trách nhiệm cho câu trả lời đó.

Vibecode vui vẻ nhé, chỉ là đừng quên khóa cửa trước khi đi ngủ. 🔐

Bạn đã từng gặp trường hợp ứng dụng vibecode bị lộ key hay lộ dữ liệu chưa? Hoặc bạn có checklist bảo mật riêng của mình?