Dữ liệu và backend: khi nào cần, dùng Supabase an toàn

Vấn đề thật

Bạn muốn khách để lại đơn, muốn người học lưu tiến độ, muốn có trang quản trị. AI nói “dùng Supabase nhé”, tạo bảng, viết code, chạy được. Vài tuần sau bạn phát hiện bất kỳ ai mở Console của trình duyệt cũng đọc được toàn bộ danh sách khách hàng.

Đây là lỗi phổ biến nhất khi vibe code app có dữ liệu. Bài này giúp bạn tránh nó.

Bước 0: có thật sự cần backend?

Bạn cần	Cách không cần backend
Khách liên hệ, đặt hàng	Nút Zalo, Messenger, email
Nhận đăng ký, khảo sát	Nhúng Google Form, dữ liệu về Google Sheet
Hiển thị danh sách sản phẩm	Viết thẳng trong file nội dung, sửa rồi deploy lại
Nhớ tiến độ của một người trên một máy	Lưu trong trình duyệt (localStorage)

Chỉ cần backend khi: nhiều người tạo ra dữ liệu và cần thấy dữ liệu của nhau hoặc của mình trên nhiều máy, có đăng nhập, có phân quyền.

Lưu trong trình duyệt: localStorage

Với app một người dùng trên một máy (sổ chi tiêu cá nhân, danh sách việc, ghi chú), localStorage là đủ: dữ liệu nằm trong trình duyệt, tải lại trang vẫn còn, không cần máy chủ, không tốn tiền. Bụi Code lưu tiến độ học của bạn đúng bằng cách này.

Giao việc cho AI:

Làm danh sách việc cần làm, lưu bằng localStorage.
Mỗi việc: id, nội dung, đã xong (đúng/sai), ngày tạo.
Chức năng: thêm, đánh dấu xong, sửa nội dung, xóa (hỏi xác nhận trước khi xóa).
Nghiệm thu:
- Thêm 3 việc, tải lại trang, vẫn còn đủ 3 việc.
- Dữ liệu hỏng hoặc trống thì trang vẫn mở được, không trắng màn hình.
- Có nút "Xuất dữ liệu" ra file JSON để tôi sao lưu.

Biết giới hạn trước khi dùng: dữ liệu chỉ có trên trình duyệt đó. Đổi máy, đổi trình duyệt, xóa dữ liệu duyệt web hoặc dùng cửa sổ ẩn danh là mất. Không lưu thông tin nhạy cảm vào đây vì mọi đoạn code chạy trên trang đều đọc được.

Supabase là gì, nói ngắn

Supabase là dịch vụ cho bạn một cơ sở dữ liệu Postgres cùng đăng nhập (Auth), lưu file (Storage) và API tự sinh, quản lý qua giao diện web. Nó hợp với vibe coding vì AI biết nó khá rõ và bạn không phải tự dựng máy chủ.

Hai thứ bạn phải hiểu trước khi cho AI đụng vào:

Hai loại khóa

Khóa	Ở đâu	Quyền
anon / publishable	Được phép nằm trong code trình duyệt	Chỉ làm được những gì RLS cho phép
service_role / secret	Chỉ ở phía máy chủ, biến môi trường	Bỏ qua mọi RLS, toàn quyền

Tên khóa có thể khác tùy thời điểm; đọc trang API keys trong tài liệu Supabase (nguồn cuối bài).

RLS: Row Level Security

RLS là luật ở cấp cơ sở dữ liệu quyết định ai được đọc, ghi dòng nào. Khi bật RLS cho một bảng mà chưa có luật (policy) nào, mọi truy cập bằng khóa anon bị chặn. Bạn mở dần bằng policy, ví dụ: “người dùng chỉ đọc được tiến độ của chính mình”.

Quy tắc: Bảng nào có dữ liệu mà trang web đọc bằng khóa anon thì bắt buộc bật RLS. Không có ngoại lệ “tạm thời”.

Mô tả dữ liệu cho AI bằng ngôn ngữ đời thường

Bạn không cần biết SQL. Bạn cần mô tả rõ thứ gì, ai sở hữu, ai được làm gì:

Tôi cần lưu tiến độ học của người dùng trên Supabase.

Dữ liệu:
- Mỗi người dùng (đăng nhập bằng email) có nhiều bản ghi tiến độ.
- Mỗi bản ghi: bài học nào (mã bài dạng chữ), hoàn thành lúc nào.
- Một người chỉ có một bản ghi cho mỗi bài.

Quyền:
- Người dùng chỉ ĐỌC và THÊM tiến độ của chính mình.
- Không ai xem được tiến độ của người khác.
- Không ai xóa được qua trang web.

Yêu cầu:
1. Viết SQL tạo bảng, bật RLS, và các policy đúng quyền trên.
2. Giải thích từng policy bằng tiếng Việt đơn giản.
3. Cho tôi cách tự kiểm: đăng nhập 2 tài khoản, tài khoản B không thấy dữ liệu của A.
4. Chỉ dùng khóa anon ở trình duyệt. Không dùng service_role trong code client.
Chưa chạy gì, chờ tôi duyệt.

Kiểm tra bảo mật dữ liệu (bắt buộc trước khi công khai)

1. Trong trang quản lý Supabase, mở mục bảng: mọi bảng có dấu hiệu RLS enabled.
2. Tìm trong mã nguồn chữ service_role, secret: không được xuất hiện trong code chạy ở trình duyệt.
3. Thử bằng hai tài khoản: đăng nhập A tạo dữ liệu; đăng nhập B, xem có thấy dữ liệu A không. Thấy là lỗi nghiêm trọng.
4. Thử khi chưa đăng nhập: mở cửa sổ ẩn danh, thử gọi trang có dữ liệu.
5. Dùng tính năng cảnh báo bảo mật trong trang quản lý Supabase (nếu có) và xử lý cảnh báo mức cao.

Lỗi hay gặp

• AI tắt RLS “cho chạy được”. Khi gặp lỗi quyền, AI hay đề xuất tắt RLS. Không chấp nhận. Bảo nó viết policy đúng.
• Dùng service_role ở trình duyệt vì “anon bị lỗi quyền”. Đây là cách lộ toàn bộ dữ liệu.
• Thu thập dữ liệu thừa. Không cần số điện thoại thì đừng lưu. Dữ liệu càng ít, rủi ro càng ít.
• Không sao lưu. Biết cách xuất dữ liệu và đã thử khôi phục ít nhất một lần.

Việc làm ngay

1. Với ý tưởng của bạn, đi qua bảng “Bước 0”. Ghi vào brief: cần hay không cần backend, vì sao.
2. Nếu cần: viết mô tả dữ liệu theo mẫu (thứ gì, ai sở hữu, ai làm gì), chưa cần chạy.
3. Chép 5 bước kiểm tra bảo mật dữ liệu vào NOTES.md.

Tóm tắt

• Chỉ thêm backend khi nhiều người tạo dữ liệu và cần đăng nhập, phân quyền.
• Khóa anon ở trình duyệt được, nhưng chỉ an toàn khi có RLS.
• Khóa service_role chỉ ở máy chủ.
• Thử bằng hai tài khoản trước khi công khai.

Prompt dùng ngay cho bài này

• Tạo dữ liệu mẫu: Có 2-3 dòng dữ liệu thật hoặc giống thật trước khi làm giao diện để AI không tự đặt tên trường rồi bắt bạn sửa cả trang.