# Lovable có an toàn cho production không?

Cyfendo · 20 tháng 10, 2026

Lovable có thể chạy một ứng dụng production. Một ứng dụng Lovable cụ thể có an toàn hay không phụ thuộc vào mã và các quy tắc cơ sở dữ liệu được tạo ra cho nó, và Lovable coi đó là trách nhiệm của chủ ứng dụng. Trong hầu hết ứng dụng Lovable, yếu tố quyết định là cơ sở dữ liệu Supabase: trình duyệt đọc và ghi trực tiếp vào đó bằng một khóa công khai, và các chính sách row-level security (RLS) là thứ duy nhất giới hạn những gì khóa đó có thể truy cập.

## CVE-2025-48757

Vào tháng 3 năm 2025, nhà nghiên cứu Matt Palmer phát hiện rằng Linkable, một ứng dụng được xây dựng bằng Lovable, trả về toàn bộ bảng `users` khi nhận một yêu cầu đã sửa đổi. Sau đó ông kiểm tra các trang công khai của 1,645 ứng dụng được xây dựng bằng Lovable và tìm thấy 303 endpoint bị lộ trên 170 ứng dụng trong số đó, khoảng 10%. Ở các ứng dụng bị ảnh hưởng, bảng người dùng và bảng giao dịch có thể bị đọc bằng khóa công khai mà không cần đăng nhập. Một hàm cơ sở dữ liệu của một ứng dụng trả về Gemini API key của ứng dụng đó cho bất kỳ ai gọi nó, và một số ứng dụng chấp nhận các yêu cầu làm thay đổi trạng thái thanh toán của đơn hàng. Palmer chỉ kiểm thử những gì truy cập được mà không cần đăng nhập.

Vấn đề được công bố vào cuối tháng 5 năm 2025 với mã CVE-2025-48757, điểm CVSS 9.3. Mục ghi trong US National Vulnerability Database ghi nhận rằng Lovable phản bác vấn đề này, với lý do mỗi khách hàng tự chịu trách nhiệm bảo vệ dữ liệu của ứng dụng mình.

Không bản cập nhật nền tảng nào có thể sửa được các ứng dụng bị ảnh hưởng, vì phần bị lỗi là các chính sách của chính từng ứng dụng. Một ứng dụng được tạo hôm nay vẫn có thể gặp đúng sơ hở đó.

## Các vấn đề khác xuất hiện trong ứng dụng Lovable

- Khóa bí mật của Supabase (`sb_secret_...`) hoặc khóa `service_role` cũ nằm trong mã front-end. Cả hai loại đều bỏ qua hoàn toàn RLS.
- Edge function lấy ID người dùng từ thân yêu cầu thay vì từ phiên đăng nhập, khiến người gọi có thể hành động như bất kỳ người dùng nào.
- Đơn hàng được đánh dấu đã thanh toán vì trình duyệt báo thành công, chứ không phải vì webhook có chữ ký của nhà cung cấp dịch vụ thanh toán đã xác nhận.
- Tệp riêng tư được lưu trong bucket công khai.

## Lovable kiểm tra những gì

Theo [tài liệu bảo mật của Lovable](https://docs.lovable.dev/features/security) (tháng 10 năm 2026):

- Một bản quét nhanh chạy khi bạn mở hộp thoại xuất bản. Nó tìm các bảng không có RLS, chính sách cho phép tất cả mọi người, tính năng bảo vệ chống mật khẩu bị rò rỉ đang tắt, lỗ hổng nghiêm trọng trong các package npm, và máy chủ MCP bị lộ mà không cần đăng nhập.
- Một bản quét sâu, do bạn bắt đầu từ chế độ xem Security, xem xét cơ sở mã để tìm vấn đề kiểm soát truy cập, endpoint không yêu cầu xác thực, injection, thông tin bí mật bị rò rỉ, vấn đề về thanh toán và xác thực, và việc lộ dữ liệu cá nhân.
- Các phát hiện không chặn việc xuất bản trừ khi quản trị viên không gian làm việc bật tính năng chặn.
- Wiz (phân tích tĩnh và phân tích thư viện phụ thuộc) và Aikido (kiểm thử xâm nhập bằng AI) có sẵn dưới dạng tích hợp trả phí.

Cùng trang đó nêu rằng các công cụ này không thể bảo đảm mức bảo mật hoàn toàn, và khuyến nghị bổ sung một đợt xem xét chuyên nghiệp cho những ứng dụng xử lý dữ liệu nhạy cảm.

## Những chỗ bản quét còn thiếu

Bản quét đọc mã và cấu hình. Chúng phát hiện một cách đáng tin cậy bảng đã tắt RLS. Chúng kém tin cậy hơn với những chính sách có tồn tại nhưng cho phép quá nhiều. Một chính sách viết là `auth.role() = 'authenticated'` giới hạn bảng cho người dùng đã đăng nhập, và vì ai cũng có thể đăng ký, nên khi đó mọi tài khoản đều đọc được mọi hàng. Một số trình quét gắn cờ mẫu này, một số thì không. Đăng nhập bằng người dùng thứ hai và yêu cầu các hàng của người dùng thứ nhất sẽ cho câu trả lời dứt khoát.

Thời điểm là khoảng trống còn lại. Bản quét nhanh chạy lúc xuất bản và bản quét sâu chạy khi có người bắt đầu nó, trong khi agent của Lovable có thể thay đổi quyền truy cập dữ liệu nhiều lần ở giữa hai thời điểm đó.

## Bài kiểm tra trong mười phút

1. Trong trình soạn thảo SQL của Supabase, liệt kê các bảng không có RLS:

   ```sql
   select tablename from pg_tables
   where schemaname = 'public' and rowsecurity = false;
   ```

2. Khi chưa đăng nhập, gửi yêu cầu lấy một bảng chỉ với publishable key:

   ```bash
   curl "https://YOUR-PROJECT.supabase.co/rest/v1/users?select=*" \
     -H "apikey: YOUR_PUBLISHABLE_KEY"
   ```

   Danh sách rỗng hoặc lỗi về quyền nghĩa là bảng được bảo vệ. Có hàng trả về nghĩa là bảng bị lộ.
3. Đăng nhập bằng tài khoản thử thứ hai và thử đọc, thay đổi các hàng của tài khoản thứ nhất.
4. Gọi từng hàm trong `/rest/v1/rpc/` mà không đăng nhập và kiểm tra kết quả trả về.
5. Chạy bản quét sâu của Lovable và xử lý lần lượt các phát hiện.

Các bản sửa cho từng mục này có trong [danh sách kiểm tra trước khi ra mắt cho ứng dụng Lovable](/blog/how-to-secure-a-lovable-app) của Cyfendo.

## Cyfendo kiểm tra ứng dụng Lovable như thế nào

Cyfendo kết nối với Lovable dưới dạng MCP connector. Khi một tác vụ thay đổi đăng nhập, truy cập dữ liệu, chính sách Supabase, thanh toán, tải lên hoặc thông tin bí mật, agent của Lovable gửi các tệp đã thay đổi đến Cyfendo. Cyfendo khởi chạy một Supabase thay thế từ các tệp migration của dự án, tạo hai người dùng thử, rồi chạy các bước 2 và 3 ở trên: yêu cầu các hàng chỉ với khóa công khai, và yêu cầu các hàng của một người dùng trong khi đăng nhập bằng người dùng kia. Những vấn đề Cyfendo tái hiện được sẽ trả về khung chat kèm các bước sửa. Những chính sách Cyfendo không phân tích được sẽ được coi là từ chối truy cập, nghĩa là Cyfendo có thể bỏ sót một điểm rò rỉ ẩn trong một chính sách phức tạp, nhưng sẽ không báo cáo điểm rò rỉ nào chưa tái hiện được.

Việc thiết lập mất khoảng hai phút: xem [hướng dẫn thiết lập Lovable](/docs/integration/lovable).

Source: https://cyfendo.com/vi/blog/is-lovable-safe-for-production