Vibe code xong web app: 7 lỗ hổng AI hay để lại và cách tự kiểm tra trong 30 phút

Chỉ cần mô tả bằng lời, các công cụ như Lovable, Bolt, v0, Replit, Cursor hay Claude Code đã dựng được một web app có đăng nhập, có database, có trang quản trị. Người không biết code cũng làm được app quản lý khách hàng, app đặt lịch, trang bán khóa học trong một buổi tối.

Vấn đề là app chạy được chưa chắc đã an toàn. AI viết code để tính năng hoạt động, còn phần "ai được xem dữ liệu nào" thường bị bỏ sót, và người làm app không biết để hỏi.

Số liệu năm 2026

• UpGuard (14/10/2026) quét khoảng 300.000 tên miền dùng Supabase (database hay đi kèm Lovable, Bolt). Kết quả: 16.326 database cho người ngoài đọc được bảng dữ liệu, và hơn một nửa trong số đó có dấu hiệu chứa thông tin cá nhân. Một số còn lộ mật khẩu dạng chữ thường, số hộ chiếu, tin nhắn riêng.
• Shippable (22/10/2026) đọc mã nguồn của khoảng 25.000 repo công khai làm bằng 5 công cụ AI. Tỉ lệ repo có ít nhất một lỗi bảo mật: Bolt 51%, Cursor 31%, Lovable 29%, v0 26%, Replit 18%.
• RedAccess (5/2026) tìm thấy khoảng 380.000 app và tài nguyên làm bằng Lovable, Base44, Replit, Netlify đang công khai trên mạng. Khoảng 5.000 trong số đó chứa dữ liệu nhạy cảm của doanh nghiệp: lịch tàu của công ty vận tải, dữ liệu thử nghiệm lâm sàng, hội thoại chăm sóc khách hàng, số liệu tài chính nội bộ của ngân hàng.

Các nền tảng đều có chung câu trả lời: cấu hình app là trách nhiệm của người tạo app. Nói cách khác, nếu app của bạn lộ dữ liệu khách hàng, người chịu trách nhiệm là bạn.

7 lỗ hổng hay gặp nhất

1. Database mở cho cả thế giới đọc

Với Supabase, trình duyệt của người dùng nói chuyện trực tiếp với database bằng một khóa công khai (anon key, hay publishable key). Khóa này được thiết kế để ai cũng thấy. Thứ bảo vệ dữ liệu là Row Level Security (RLS): các luật quy định mỗi người được đọc, sửa dòng dữ liệu nào.

Nếu bảng chưa bật RLS, hoặc bật nhưng luật viết kiểu "ai cũng được đọc", thì bất kỳ ai mở công cụ dành cho nhà phát triển (DevTools) trên trình duyệt, copy khóa công khai là tải được toàn bộ bảng users, orders...

Điểm dễ sập bẫy: theo UpGuard, bảng tạo qua API hoặc SQL không tự bật RLS. Supabase chỉ bật mặc định khi bạn tạo bảng bằng giao diện Table Editor. Mà agent AI thì tạo bảng bằng SQL.

Shippable thấy 25,6% repo Bolt có bảng mở cho mọi người.

2. Người dùng tự nâng quyền cho mình

AI hay lưu vai trò (role: admin) hoặc gói dịch vụ (plan: pro) ngay trong bảng hồ sơ người dùng, rồi cho người dùng sửa hồ sơ của chính mình. Kết quả: ai biết mở DevTools có thể tự đổi mình thành admin hoặc tự nâng lên gói trả phí.

Lỗi này có ở 16,7% repo Bolt.

3. Khóa bí mật nằm lộ trong code

Có ba dạng hay gặp:

• File .env bị đẩy lên GitHub cùng code (13,5% repo Lovable, 10,4% repo Bolt).
• Khóa bí mật được đặt trong biến môi trường có tiền tố VITE_ hoặc NEXT_PUBLIC_. Các tiền tố này nghĩa là "đưa vào code chạy trên trình duyệt", nên ai xem mã nguồn trang cũng thấy.
• Dùng nhầm service_role key (hay secret key) của Supabase ở phía trình duyệt. Khóa này bỏ qua mọi luật RLS, lộ ra là mất toàn bộ database.

Khóa API của OpenAI, Claude, Gemini bị lộ theo cách này có thể biến thành hóa đơn hàng nghìn đô chỉ sau một đêm. Xem bài Lộ API key AI khi vibe code.

4. Đăng nhập chỉ là cái vỏ ngoài giao diện

App hiện màn hình đăng nhập, nhưng dữ liệu đã được tải về trình duyệt từ trước, hoặc API phía sau không kiểm tra người gọi là ai. Người dùng thường không thấy gì bất thường, nhưng ai gọi thẳng API là lấy được dữ liệu.

Tháng 10/2026, một chuỗi cà phê ở Nam Phi bị báo chí phát hiện trang quản trị nội bộ (làm bằng Claude, chạy trên Railway) gửi kèm toàn bộ dữ liệu ngay cùng trang đăng nhập. Báo MyBroadband xác minh được thông tin của 132 cửa hàng.

Shippable cũng thấy 11,3% repo Bolt có edge function (hàm chạy trên máy chủ) không kiểm tra quyền truy cập.

5. Đổi số trên đường dẫn là xem được dữ liệu người khác

Đường dẫn kiểu /don-hang/1024: đổi thành /don-hang/1025 là xem được đơn hàng của khách khác. Đây là lỗi kinh điển (gọi là IDOR), và AI rất hay mắc vì nó chỉ kiểm tra "đã đăng nhập chưa", không kiểm tra "dữ liệu này có phải của người này không".

6. Kho file mở công khai

Ảnh CMND khách gửi, hợp đồng, hóa đơn PDF được lưu vào kho file (storage bucket) để chế độ công khai. Ai có đường dẫn, hoặc đoán được tên file, là tải được. Có ở 8,5% repo Bolt.

7. Tin dữ liệu do trình duyệt gửi lên, nhất là ở phần thanh toán

• Giá tiền được gửi từ trình duyệt lên máy chủ. Sửa giá trong DevTools là mua hàng 1.000 đồng.
• Webhook thanh toán (thông báo "đã thanh toán" từ cổng thanh toán) không được xác thực chữ ký, nên ai cũng có thể gửi một thông báo giả để kích hoạt đơn hàng.
• Mã giảm giá, token đặt lại mật khẩu tạo bằng hàm ngẫu nhiên yếu (Math.random()), đoán được. Lỗi này xuất hiện ở mọi công cụ, từ 6,6% đến 14,4% số repo.

Tự kiểm tra trong 30 phút

Không cần biết code, bạn vẫn làm được các bước sau. Dùng một tài khoản thử và dữ liệu của chính bạn, đừng thử trên app của người khác.

1. Mở trình duyệt ẩn danh, chưa đăng nhập, gõ thẳng đường dẫn các trang quản trị, dashboard, trang chi tiết đơn hàng. Vào được, hoặc thấy dữ liệu chớp lên trước khi bị chuyển về trang đăng nhập, là có vấn đề.

2. Tạo 2 tài khoản thử. Đăng nhập tài khoản A, copy đường dẫn một đơn hàng hay hồ sơ, rồi mở bằng tài khoản B. Thử đổi số ID trên đường dẫn.

3. Nếu dùng Supabase: vào Dashboard, mở mục Advisors → Security Advisor. Mọi cảnh báo kiểu "RLS disabled" phải được xử lý. Mở Table Editor, kiểm tra bảng nào cũng có biểu tượng RLS đang bật và có policy cụ thể.

4. Tìm khóa bí mật trong code:

   • Kiểm tra repo GitHub có file .env không. Nếu có, coi như mọi khóa trong đó đã lộ.
   • Tìm các chuỗi sk-, service_role, secret trong code.
   • Bật Secret scanning và Push protection trong phần Settings → Code security của repo GitHub.

5. Xem mã nguồn trang trên trình duyệt (Ctrl+U, hoặc tab Sources trong DevTools), tìm các chữ sk-, key, secret. Thấy khóa của OpenAI, Claude, cổng thanh toán là phải đổi ngay.

6. Gõ site:tenmiencuaban.com trên Google xem có trang nội bộ, trang quản trị nào bị lập chỉ mục không. Kiểm tra chế độ hiển thị của project trên Lovable, Replit, Base44 đang là public hay private.

7. Bắt AI tự rà lại. Dán vào công cụ bạn đang dùng một yêu cầu như:

   Hãy rà soát bảo mật toàn bộ project này với vai trò người kiểm thử. Liệt kê: bảng nào chưa bật RLS hoặc có policy cho phép đọc/ghi quá rộng; cột nào người dùng tự sửa được mà ảnh hưởng tới quyền hoặc gói dịch vụ; khóa bí mật nào nằm trong code phía trình duyệt hoặc trong biến VITE_/NEXT_PUBLIC_; API hoặc edge function nào không kiểm tra người gọi; chỗ nào tin giá tiền hoặc dữ liệu do trình duyệt gửi lên; webhook thanh toán có xác thực chữ ký chưa. Chỉ báo cáo, chưa sửa.

   Sau đó yêu cầu sửa từng mục một và kiểm tra lại bằng các bước 1–2. AI rà lại giúp phát hiện nhiều lỗi, nhưng không thay được việc tự thử: chính AI đã viết ra các lỗi này.

Khi nào nên nhờ người có chuyên môn?

Bản demo cho bạn bè xem thì rủi ro thấp. Nhưng nếu app lưu thông tin khách hàng thật, nhận thanh toán, hoặc dùng trong công ty, nên có người hiểu bảo mật rà soát trước khi đưa vào dùng thật, và rà lại sau mỗi lần thêm tính năng lớn. Chi phí cho một lần rà soát rẻ hơn nhiều so với một vụ lộ dữ liệu khách hàng.

Nguồn tham khảo: UpGuard, Shippable, Axios, MyBroadband.