Vibe coding đang ship app quá nhanh, nhưng bảo mật đang tụt lại phía sau

Bên r/vibecoding đang có một bài khá đáng chú ý: một developer dành vài giờ soi các app được làm bằng Lovable và thấy ra một loạt lỗi bảo mật ở mức rất cơ bản. Điểm đáng nói không nằm ở chuyện “tool nào tệ”, mà ở chỗ đây là một cảnh báo rất thật cho cả làn sóng vibe coding: app chạy được chưa bao giờ đồng nghĩa với app đủ an toàn để đưa cho người dùng thật.

Chuyện gì đã bị lộ ra

Theo chia sẻ từ bài Reddit, chỉ với trình duyệt thường và DevTools, tác giả đã thấy nhiều kiểu lỗi mà anh em làm sản phẩm không được phép xem nhẹ:

• Bảng Supabase mở toang vì Row Level Security không bật hoặc bật nhưng không có policy đúng.
• Trạng thái trả phí như is_paid hoặc is_subscribed có thể bị sửa từ phía client.
• Stripe secret key xuất hiện trong JavaScript bundle thay vì chỉ nằm ở backend.
• File .env hoặc tài nguyên nhạy cảm bị public trực tiếp qua web server.
• Route quản trị như /admin không có lớp xác thực đủ chặt.

Nếu đúng như mô tả, đây không phải lỗi kiểu “cao siêu mới khai thác được”. Đây là nhóm lỗi mà chỉ cần người tò mò một chút là đã đủ thấy cửa vào.

Vì sao vibe coding rất dễ dính nhóm lỗi này

Vấn đề gốc là AI thường tối ưu cho kết quả nhìn thấy ngay:

• form submit thành công
• dữ liệu ghi được xuống database
• thanh toán gọi được API
• dashboard mở lên được

Nhưng bảo mật lại nằm ở phần không nhìn thấy ngay trong demo. Muốn app an toàn thì phải có thêm tư duy kiểm soát quyền, tách bí mật khỏi client, khóa route nhạy cảm, kiểm tra cấu hình deploy và đặt giả định rằng người dùng sẽ thử nghịch mọi thứ họ thấy trên trình duyệt.

Khi một founder hoặc maker không có nền tảng backend/security dùng vibe coding để ra mắt nhanh, họ rất dễ chấp nhận trạng thái “đã chạy” như thể đó là “đã xong”. Đây là chỗ nguy hiểm nhất.

Chi tiết đáng chú ý nhất: Supabase và RLS

Supabase là stack rất hay gặp trong các app vibe coding, nên lỗi RLS đáng được tách riêng ra. Tài liệu của Supabase nhấn mạnh khá rõ: với bảng nằm trong schema public hoặc schema bị expose ra ngoài, RLS cần được bật và phải có policy phù hợp; nếu không thì dữ liệu có thể bị truy cập sai phạm vi khi ứng dụng gọi từ môi trường client hoặc các luồng public API.¹

Nhìn theo góc vận hành sản phẩm, RLS không chỉ là một checkbox kỹ thuật. Nó là hàng rào cuối cùng giữa:

• dữ liệu của từng user
• logic subscription
• các bảng nội bộ mà app frontend không nên chạm trực tiếp

Nếu anh em đang làm app kiểu AI builder + Supabase, thì kiểm tra RLS nên được xem là bước bắt buộc trước khi quảng bá sản phẩm.

Điều bài Reddit nhắc rất đúng

Có một ý rất đáng giữ lại: AI tạo ra thứ “hoạt động được”, chứ không tự chịu trách nhiệm cho mô hình đe dọa của hệ thống.

Nói thẳng ra:

• AI có thể viết query giúp app chạy
• AI có thể cắm key để request thành công
• AI có thể dựng admin panel rất nhanh

Nhưng AI không tự chịu hậu quả khi key bị lộ, bảng dữ liệu bị đọc hàng loạt, hay người dùng bị truy cập trái phép. Phần đó vẫn là trách nhiệm của người ship sản phẩm.

Checklist ngắn trước khi đưa app vibe coding ra ngoài

Nếu anh em đang có app thật, có user thật, hoặc ít nhất đang cắm API/Stripe/Supabase thật, nên rà ngay các điểm này:

1. Kiểm tra tất cả bảng Supabase có bật RLS hay chưa, và policy có đúng actor hay chưa.
2. Tìm trong bundle frontend các chuỗi nhạy cảm như secret key, service role, webhook secret.
3. Thử truy cập trực tiếp các đường dẫn như .env, .git/HEAD, /admin, /dashboard, /settings trong cửa sổ ẩn danh.
4. Xác minh mọi thay đổi quan trọng như nâng gói, đổi role, export dữ liệu đều đi qua backend có kiểm tra quyền.
5. Soát lại biến môi trường ở nền tảng deploy để chắc rằng chỉ public key mới đi ra client.
6. Thêm một vòng review thủ công trước khi launch, đừng tin hoàn toàn vào kết quả AI sinh ra.

Góc nhìn đáng rút ra cho cộng đồng

Bài viết này không phải tín hiệu để anh em né vibe coding. Ngược lại, nó nhắc đúng một thực tế: tốc độ tạo sản phẩm đang tăng rất mạnh, nên kỷ luật kiểm tra bảo mật cũng phải tăng theo.

Nếu giai đoạn 2024 là “làm thử cho nhanh”, thì giai đoạn 2026 có lẽ phải là “ship nhanh nhưng có hàng rào”. Với các sản phẩm có user, tiền, dữ liệu, hoặc quy trình nội bộ thật, mindset hợp lý không còn là:

• app chạy ổn là đủ

mà phải là:

• app chạy được, phân quyền đúng, bí mật không lộ, và có thể chịu được một người dùng tò mò mở DevTools ra soi

Đó mới là mức tối thiểu để vibe coding đi từ demo sang sản phẩm thật.

1. Supabase Docs, Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security ↩