Code do AI viết có thể chạy đúng mà vẫn không an toàn. Hai chuyện đó khác nhau, và người mới học vibe code thường chỉ kiểm tra chuyện thứ nhất: bấm nút thấy ra kết quả đúng là coi như xong. Với một trang chia tiền ăn nhóm thì vậy là đủ. Với bất cứ thứ gì lưu dữ liệu của người khác, có form, có khóa API hay nối với dịch vụ trả phí, thì chưa.
Đây là bài cho chặng 6, chặng cuối trong lộ trình học vibe code từ đầu. Bài đi qua sáu rủi ro thường gặp, mỗi rủi ro kèm một sự việc hay nghiên cứu có thật, cách tự kiểm tra, và một checklist để đi hết trước khi cho người khác dùng.
Vì sao "chạy được" chưa phải là "an toàn"
Năm 2025, Veracode cho hơn 100 mô hình ngôn ngữ làm 80 bài viết code được thiết kế quanh các lỗi bảo mật phổ biến. Theo báo cáo, code AI tạo ra có lỗ hổng bảo mật ở khoảng 45% số bài; với những lỗi phụ thuộc ngữ cảnh như chèn mã độc vào trang (XSS), tỷ lệ code an toàn còn thấp hơn nhiều (nguồn: Veracode). Báo cáo cũng ghi nhận: các mô hình viết code đúng cú pháp ngày càng tốt, nhưng khả năng viết code an toàn không tiến bộ tương ứng.
Con số này đo trên bài thử, không phải trên mọi dòng code AI viết ra. Nhưng ý chính rõ ràng: AI viết code để chạy được theo yêu cầu, và nếu yêu cầu không nhắc đến an toàn, đừng mặc định là code đã an toàn.
Rủi ro 1: Lộ khóa bí mật
Khi nối với dịch vụ bên ngoài (AI, bản đồ, gửi email, thanh toán), bạn nhận một khóa API. AI thường dán thẳng khóa đó vào code cho nhanh. Nếu đoạn code ấy chạy trên trình duyệt, ai mở trang cũng xem được khóa; nếu nằm trong kho code công khai, ai tìm cũng thấy, kể cả khi bạn đã xóa ở lần lưu sau, vì lịch sử commit vẫn còn.
Cách làm đúng: khóa đặt trong biến môi trường hoặc phần cài đặt bí mật của dịch vụ lưu trữ, chỉ dùng ở phía máy chủ; trình duyệt gọi qua máy chủ của bạn chứ không gọi thẳng dịch vụ có khóa.
Tự kiểm tra: mở trang, bấm F12, tìm trong mã nguồn và tab Network những chuỗi trông giống khóa. Hỏi AI: "Trong dự án này có khóa hay mật khẩu nào lộ ra trình duyệt hoặc nằm trong file sẽ đưa lên kho công khai không?"
Nếu đã lộ: đổi khóa ngay trên trang quản lý của dịch vụ, đừng chỉ xóa khỏi code. Với mật khẩu tài khoản, kiểm tra xem đã từng bị lộ chưa bằng công cụ kiểm tra mật khẩu bị lộ, và đổi sang mật khẩu mạnh tạo bằng công cụ tạo mật khẩu.
Rủi ro 2: Dữ liệu người dùng mở cho mọi người
Năm 2025, lỗ hổng CVE-2025-48757 được công bố với các ứng dụng dựng bằng Lovable: nhiều ứng dụng cho trình duyệt gọi thẳng cơ sở dữ liệu Supabase nhưng không bật quy tắc phân quyền theo từng dòng dữ liệu (Row Level Security). Kết quả là ai có khóa công khai đi kèm trang cũng đọc được dữ liệu. Một nhà nghiên cứu quét 1.645 ứng dụng và tìm thấy 170 ứng dụng để lộ dữ liệu như email, địa chỉ (nguồn: NVD).
Lỗi này không phải của riêng một công cụ. Bất cứ khi nào trình dựng app tự tạo cơ sở dữ liệu cho bạn, câu hỏi phải đặt ra là: ai được đọc, ai được sửa dữ liệu này?
Tự kiểm tra: tạo hai tài khoản thử. Đăng nhập tài khoản thứ hai, xem có thấy được dữ liệu của tài khoản thứ nhất không. Mở trang bằng cửa sổ ẩn danh, chưa đăng nhập, xem thấy được gì.
Hỏi AI: "Liệt kê mọi bảng dữ liệu trong dự án, mỗi bảng ai được đọc, ai được ghi, và quy tắc đó được đặt ở đâu."
Thu thập ít nhất có thể: không cần số điện thoại thì đừng hỏi số điện thoại. Dữ liệu không thu thập thì không thể lộ.
Ở Việt Nam, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP hướng dẫn luật này có hiệu lực từ 1/1/2026 (nguồn: Thị trường Tài chính Tiền tệ). Một trang có form thu thập họ tên, số điện thoại của người khác là đang xử lý dữ liệu cá nhân; ít nhất cần nói rõ thu thập để làm gì và xin sự đồng ý. Phần này chỉ để định hướng, không thay cho tư vấn pháp lý khi bạn làm sản phẩm thật.
Rủi ro 3: Form và dữ liệu nhập không được kiểm tra
Mọi ô nhập liệu là một cánh cửa. Code AI viết thường chỉ kiểm tra dữ liệu trên trình duyệt, trong khi kẻ xấu gửi thẳng đến máy chủ, bỏ qua trình duyệt.
Spam: form liên hệ không chặn sẽ nhận hàng trăm tin rác mỗi ngày, và nếu mỗi tin gửi một email qua dịch vụ trả phí, hóa đơn tăng theo.
Chèn mã: thử nhập một đoạn như
<b>thử</b>vào ô tên. Nếu trang hiện chữ in đậm thay vì nguyên văn, trang đang chạy mã người dùng nhập vào, đúng loại lỗi XSS mà báo cáo Veracode nêu.Yêu cầu AI cụ thể: "Kiểm tra dữ liệu ở phía máy chủ cho mọi form, giới hạn số lần gửi theo địa chỉ IP, và hiển thị dữ liệu người dùng nhập dưới dạng văn bản thuần."
Rủi ro 4: Thư viện không có thật hoặc không rõ nguồn
AI đôi khi gợi ý cài một thư viện không hề tồn tại, vì tên nghe hợp lý. Một nghiên cứu công bố tại hội nghị USENIX Security 2025 cho thấy khoảng một phần năm số mẫu code do các mô hình tạo ra có gợi ý ít nhất một thư viện không tồn tại, và nhiều tên bị "bịa" lặp lại qua các lần hỏi (nguồn: CSO Online). Kẻ xấu có thể đăng ký trước đúng những tên đó và đưa mã độc vào, kiểu tấn công được đặt tên là slopsquatting.
Tự kiểm tra: mỗi lần AI thêm thư viện, tra tên đó trên kho chính thức (npm với JavaScript, PyPI với Python): có trang chính thức không, có nhiều lượt tải không, có được cập nhật gần đây không.
Hỏi lại: "Vì sao cần thư viện này? Có làm được bằng code thuần trong vài dòng không?" Với dự án nhỏ, câu trả lời thường là có.
Rủi ro 5: AI sửa hoặc xóa dữ liệu thật
Tháng 7/2025, nhà sáng lập SaaStr Jason Lemkin kể rằng trong một thử nghiệm vibe code, agent AI của Replit đã xóa cơ sở dữ liệu của dự án dù đang trong thời gian được dặn không thay đổi code. CEO Replit sau đó xin lỗi và cho biết sẽ bổ sung các biện pháp như tách cơ sở dữ liệu phát triển và cơ sở dữ liệu thật (nguồn: Fortune).
Bài học không phải "đừng dùng agent", mà là đừng để agent có quyền làm điều bạn không thể hoàn tác:
Tách môi trường: dữ liệu thử để AI làm việc, dữ liệu thật để người dùng dùng. AI không cần, và không nên có, quyền ghi vào dữ liệu thật.
Sao lưu và thử khôi phục: một bản sao lưu chưa từng khôi phục thử thì chưa chắc dùng được.
Đọc trước khi chấp nhận mọi lệnh có chữ xóa, ghi đè, di chuyển dữ liệu mà agent đề xuất chạy.
Rủi ro 6: Chi phí bất ngờ và không ai bảo trì
Hóa đơn API: một khóa bị lộ hay một form bị spam có thể làm chi phí dịch vụ trả phí tăng vọt trong một đêm. Đặt hạn mức chi tiêu và cảnh báo trên trang quản lý của từng dịch vụ ngay khi tạo khóa.
Bảo trì: sáu tháng sau, thư viện có bản vá bảo mật, trình duyệt đổi cách xử lý, dịch vụ đổi giá. Nếu không ai hiểu code, không ai cập nhật. Giữ file mô tả dự án và ghi lại mọi quyết định quan trọng để người sau, hoặc chính bạn, sửa được.
Kiểm tra cấu hình cơ bản: trang có chứng chỉ SSL hợp lệ không (công cụ kiểm tra SSL), có các header bảo mật cơ bản không (công cụ phân tích security header).
Checklist trước khi cho người khác dùng
Đi hết từng ô. Ô nào bạn không trả lời được, đó là chỗ cần hỏi AI giải thích, hoặc hỏi một người làm nghề xem giúp. Có thể dán nguyên checklist này vào khung chat và yêu cầu: "Rà dự án theo từng mục dưới đây, mục nào chưa đạt thì chỉ ra file và dòng, chưa sửa gì." Sau đó sửa từng mục một, theo cách đã học ở bài cách viết prompt khi vibe code.
Khi nào nên nhờ người làm nghề
Vibe code tự làm được rất nhiều, nhưng có những trường hợp chi phí của một lỗi lớn hơn nhiều so với chi phí nhờ người kiểm tra:
Trang thu thập dữ liệu cá nhân của khách hàng: họ tên, số điện thoại, địa chỉ, thông tin sức khỏe.
Có thanh toán, ví, mã giảm giá hay bất cứ thứ gì đụng đến tiền.
Website là kênh bán hàng chính của doanh nghiệp, cần chạy ổn định, lên Google và được bảo trì nhiều năm.
Bạn đã đi hết checklist mà vẫn còn nhiều ô không trả lời được.
Với website doanh nghiệp, Tấn Phát Digital có dịch vụ thiết kế website và dịch vụ bảo trì website; bản mẫu bạn tự làm bằng AI là tài liệu rất tốt để trao đổi yêu cầu.
Muốn tự làm nhưng có người kèm phần an toàn? Khóa học vibe code cho người mới của Tấn Phát Digital học online qua Zoom hoặc Google Meet trong 3 ngày, học phí 10 triệu đồng. Hết khóa, mỗi học viên có một website giới thiệu nhiều trang chạy trên tên miền riêng, có form liên hệ, đã đưa lên Google, và biết cách tự sửa nội dung, tự thêm tính năng bằng AI. Liên hệ Tấn Phát Digital để hỏi lịch khai giảng.
