Một post đang hot bên r/vibecoding mấy hôm nay khá buồn cười, nhưng cũng là một lời nhắc rất thật cho anh em đang build sản phẩm bằng AI.
Một builder khoe kiểu: đã đốt cả đống token để vibe code backend, gần như không có kinh nghiệm dev mà vẫn làm ra hệ thống chạy được. Phía dưới có người vào cà khịa rằng chỉ cần 20 phút là có thể tìm đường vào database. Tưởng chỉ là combat comment cho vui, nhưng sau vài lượt trao đổi thì câu chuyện chuyển hẳn sang hướng khác: người kia phát hiện trang admin đang render lộ cấu trúc trước cả khi người dùng phải đăng nhập.
Điểm đáng nói là họ không cần truy cập sâu mới chứng minh được vấn đề. Chỉ từ những gì giao diện lộ ra, người này đã đoán đúng tab đầu tiên của dashboard admin và các chỉ số bên trong như thành viên hoạt động, tổng số job, job chờ xử lý, worker đang hoạt động, estimated revenue, MRR và recent activity. Chủ hệ thống cuối cùng phải thừa nhận là đối phương nói đúng.
Vì sao tình huống này đáng chú ý
Nếu nhìn ở góc độ cộng đồng, đây là một mẩu tin vui vẻ đúng chất internet: một màn bóc lỗi ngay trong phần bình luận. Nhưng nếu nhìn ở góc độ vận hành sản phẩm, đây là lỗi không vui chút nào.
Vấn đề ở đây không chỉ là “có bug”. Vấn đề là cảm giác hoàn thiện do vibe coding tạo ra rất dễ đánh lừa người build:
- Giao diện nhìn đủ đẹp để nghĩ rằng hệ thống đã ổn
- Backend có thể chạy được vài luồng chính nên dễ sinh chủ quan
- AI giúp ship rất nhanh, nhưng không tự đảm bảo boundary về auth, permission và data exposure
- Khi thiếu review kỹ thuật, lỗi kiểu render trước rồi mới chặn sau rất dễ lọt qua
Nói ngắn gọn: sản phẩm có thể chạy được, nhưng chưa chắc đã an toàn để cho người thật dùng.
Lỗi cốt lõi trong case này là gì
Từ chuỗi ảnh chụp, thứ bị lộ không nhất thiết là database theo nghĩa đã bị xâm nhập hoàn toàn. Nhưng chỉ riêng chuyện admin portal render ra cấu trúc dashboard trước bước xác thực cũng đã là một tín hiệu đỏ.
Trong thực tế, kiểu lỗi này thường đến từ một trong vài mẫu quen thuộc:
- Frontend đã gọi sẵn dữ liệu hoặc metadata trước khi check session xong
- Route admin bị che bằng UI nhưng không chặn chặt ở server
- Component render skeleton hoặc state mặc định chứa thông tin nhạy cảm
- Middleware auth có tồn tại nhưng đặt sai tầng hoặc fail-open trong một số path
- Builder test trên môi trường local thấy “vào được” rồi nghĩ production cũng ổn
Đây chính là chỗ vibe coding dễ đẩy anh em vào bẫy. AI rất giỏi dựng nhanh một flow trông có vẻ đúng, nhưng bảo mật thì không thể dựa vào cảm giác “nó có vẻ hợp lý”.
Bài học thực chiến cho anh em đang build bằng AI
Nếu đang dùng Cursor, Claude, GPT hay agent nào đó để ship sản phẩm, mình nghĩ có 5 thứ nên check ngay:
1. Chặn ở server trước, không chặn ở giao diện trước
Không bao giờ coi việc ẩn nút, ẩn menu hay redirect ở frontend là bảo mật. Route nhạy cảm phải bị chặn từ middleware, API layer và query layer.
2. Kiểm tra trạng thái chưa đăng nhập
Mở tab ẩn danh rồi thử toàn bộ luồng:
- vào thẳng URL admin
- refresh ở trang con
- mở DevTools xem response trả về gì
- kiểm tra HTML render ban đầu có lộ label, số liệu hoặc cấu trúc không
Rất nhiều lỗi lộ dữ liệu xuất hiện chính ở bước này.
3. Soát các component dashboard
Dashboard là nơi AI hay sinh ra rất nhanh vì mẫu code có sẵn nhiều. Cũng vì vậy, đây là vùng dễ bị copy sai pattern nhất. Hãy kiểm tra xem component có:
- hardcode dữ liệu mẫu
- fetch trước khi auth hoàn tất
- render tên tab, metric, schema hoặc placeholder quá chi tiết
- để lộ endpoint nội bộ trong source
4. Tách rõ “demo chạy được” với “production dùng được”
Một app hoạt động được trong demo không đồng nghĩa đã đủ chuẩn để public. Trước khi mở cho user thật, ít nhất nên có checklist:
- auth
- permission
- rate limit
- logging
- error handling
- secrets
- basic abuse testing
5. Nhờ người khác phá thử
Case trên thực ra là một dạng review miễn phí từ cộng đồng. Trước khi ra mắt, nên nhờ ít nhất một người có tư duy kỹ thuật vào thử theo hướng ngược lại: không hỏi app làm được gì, mà hỏi nó lộ gì, hở gì, vỡ ở đâu.
Tin tốt và tin xấu của vibe coding
Tin tốt là vibe coding đang giúp rất nhiều người không chuyên tạo được sản phẩm nhanh hơn bao giờ hết. Điều này là thật, và mình nghĩ nó vẫn sẽ tiếp tục mở rộng thị trường builder nhỏ lẻ.
Tin xấu là tốc độ build tăng lên không kéo theo năng lực kiểm soát chất lượng một cách tự động. Những phần “không sexy” như auth, permission, trạng thái lỗi, bảo mật biên và kiểm thử lạm dụng vẫn là nơi sản phẩm chết nhanh nhất.
Nói cách khác, AI rút ngắn thời gian từ ý tưởng tới demo, nhưng không xoá được nhu cầu review kỹ thuật.
Góc nhìn vận hành
Nếu anh em đang làm sản phẩm để bán hoặc vận hành nội bộ cho doanh nghiệp, mình nghĩ đây là điểm cần nhớ:
- đừng đo độ trưởng thành của hệ thống bằng tốc độ ship
- đừng lấy việc app chạy được làm bằng chứng app an toàn
- đừng để agent tự sinh cả backend lẫn auth mà không có vòng kiểm tra độc lập
Một lỗi lộ admin UI nghe có vẻ nhỏ, nhưng trong môi trường thật nó có thể kéo theo mất dữ liệu, bị spam hệ thống, lộ cấu trúc vận hành hoặc tạo bàn đạp cho tấn công sâu hơn.
Vậy nên nếu hôm nay anh em đang khá tự tin vì AI vừa giúp ship xong một dashboard đẹp và mượt, có lẽ việc nên làm tiếp theo không phải là khoe thêm screenshot, mà là mở cửa sổ ẩn danh và thử phá chính sản phẩm của mình.
Top comments (0)