Danh sách kiểm tra bảo mật cho ứng dụng xây bằng AI: cần kiểm tra gì trước khi ra mắt

Trước khi người thật dùng một ứng dụng bạn xây bằng AI, hãy kiểm tra bảy điều: mọi trang và API đều kiểm tra người dùng là ai và họ được làm gì; khóa bí mật nằm trên máy chủ, không bao giờ nằm trong trình duyệt hay chat; mọi đầu vào được kiểm tra trên máy chủ; mỗi người dùng chỉ truy cập được bản ghi của chính mình; đăng nhập và các endpoint tốn chi phí được giới hạn tần suất; các thư viện phụ thuộc được cập nhật; và bạn có thể khôi phục dữ liệu nếu có sự cố. Danh sách dưới đây biến từng điều đó thành các bài kiểm tra cụ thể mà bạn có thể chạy mà không cần đọc mã.

Các công cụ tạo ứng dụng AI rất giỏi làm cho tính năng chạy được. Chúng không tự động cẩn thận, vì “cẩn thận” hiếm khi có trong câu lệnh. Phần lớn các vấn đề dưới đây đến từ những thứ không ai yêu cầu, nên cách sửa thường là hãy hỏi.

Cách dùng danh sách này

Làm theo thứ tự, và với mỗi mục hãy làm hai việc: hỏi AI để đảm bảo nó được xử lý, và tự kiểm tra. AI có thể viết một kiểm tra quyền; chỉ một bài kiểm tra mới cho bạn biết nó hoạt động. Các mục được đánh dấu:

• Bắt buộc — làm trước khi bất kỳ ai khác dùng ứng dụng.
• Nên làm — làm trước khi bạn có người dùng thật hoặc dữ liệu thật.
• Sau này — đáng làm khi ứng dụng phát triển.

Nếu bạn chỉ có một giờ, hãy làm mọi mục Bắt buộc.

1. Xác thực: ai đây?

Xác thực là xác nhận ai là người đang truy cập — thường là đăng nhập. Xem xác thực là gì để biết kiến thức nền và cách thêm đăng nhập vào ứng dụng để biết các lựa chọn.

• Bắt buộc: Mọi trang hiển thị dữ liệu riêng tư đều yêu cầu đăng nhập. Kiểm tra: đăng xuất, sau đó dán URL của một trang riêng tư trực tiếp vào trình duyệt.
• Bắt buộc: Mọi endpoint API đứng sau các trang đó cũng yêu cầu đăng nhập — không chỉ trang. Kiểm tra: đăng xuất, mở tab mạng của trình duyệt và thử lại một yêu cầu mà ứng dụng đã gửi khi bạn còn đăng nhập.
• Bắt buộc: Mật khẩu được lưu dưới dạng băm bằng thuật toán băm mật khẩu chậm, không bao giờ là văn bản thuần. Hướng dẫn lưu trữ mật khẩu của OWASP khuyến nghị Argon2id trước, với scrypt, bcrypt hoặc PBKDF2 là lựa chọn thay thế. Hỏi: “Mật khẩu được lưu như thế nào?”
• Nên làm: Liên kết đặt lại mật khẩu hết hạn và chỉ dùng được một lần.
• Nên làm: Cookie phiên được đánh dấu Secure, HttpOnly và SameSite, và đăng xuất sẽ kết thúc phiên trên máy chủ.
• Sau này: Cung cấp xác thực hai yếu tố, hoặc đăng nhập qua nhà cung cấp có tính năng này.

Kiểm tra mọi route API và trang trả về dữ liệu người dùng. Mỗi cái phải từ chối yêu cầu từ người chưa đăng nhập, trên máy chủ, không chỉ trong mã của trang. Liệt kê các route bạn đã kiểm tra.

2. Phân quyền: họ được phép làm gì?

Phân quyền là bước sau đăng nhập: quyết định người dùng cụ thể này được xem và thay đổi những gì. Đây là chỗ các ứng dụng xây bằng AI thường có lỗ hổng nghiêm trọng nhất, vì ứng dụng trông đúng — bảng điều khiển của mỗi người chỉ hiện dữ liệu của chính họ — trong khi máy chủ vẫn sẵn sàng trao dữ liệu của bất kỳ ai nếu có người yêu cầu trực tiếp.

• Bắt buộc: Mọi thao tác đọc, cập nhật và xóa đều kiểm tra trên máy chủ rằng bản ghi thuộc về người dùng hiện tại (hoặc nhóm của họ).
• Bắt buộc: Kiểm tra: tạo hai tài khoản, A và B. Với tài khoản A, mở một bản ghi của A và ghi lại ID trong URL hoặc yêu cầu mạng. Đăng nhập bằng B và yêu cầu cùng ID đó. B phải nhận lỗi, không phải dữ liệu của A.
• Bắt buộc: Các trang quản trị và endpoint API quản trị kiểm tra vai trò người dùng trên máy chủ. Ẩn liên kết quản trị không phải là bảo vệ.
• Bắt buộc: Người dùng không thể thay đổi vai trò, giá, số dư hoặc trường chủ sở hữu của chính mình bằng cách sửa yêu cầu. Kiểm tra: trong tab mạng, xem một lần cập nhật hồ sơ gửi những gì. Nếu có các trường như role hoặc isAdmin, hãy hỏi AI bỏ qua chúng khi nhận từ phía client.
• Nên làm: ID trong URL khó đoán (ID ngẫu nhiên thay vì 1, 2, 3). Điều này không thay thế kiểm tra quyền, nhưng giới hạn thiệt hại khi một kiểm tra bị thiếu.

Với mọi endpoint đọc hoặc thay đổi một bản ghi, kiểm tra trên máy chủ rằng người dùng đã đăng nhập sở hữu hoặc được phép truy cập nó. Trả về 404 nếu không. Sau đó cho tôi xem bạn sẽ kiểm tra điều này với hai tài khoản như thế nào.

3. Truy cập theo hàng trong cơ sở dữ liệu

“Truy cập theo hàng” nghĩa là mỗi hàng của một bảng (một lượt đặt, một hóa đơn) chỉ hiển thị cho những người dùng mà nó thuộc về. Có hai cách phổ biến để thực thi:

Cả hai đều có thể làm tốt. Điều quan trọng là:

• Bắt buộc: Nếu trình duyệt nói chuyện trực tiếp với cơ sở dữ liệu (một số sản phẩm cơ sở dữ liệu lưu trữ cho phép điều này), quy tắc row-level được bật cho mọi bảng. Nếu không, bất kỳ ai có khóa công khai đều có thể đọc toàn bộ bảng.
• Bắt buộc: Truy vấn lọc theo người dùng hoặc nhóm hiện tại, không theo một ID mà trình duyệt gửi lên.
• Nên làm: Dữ liệu chia sẻ (dự án của một nhóm) có quy tắc rõ ràng về ai thuộc nhóm, được thực thi ở một nơi duy nhất.

4. Bí mật và khóa API

Khóa API là mật khẩu của một dịch vụ. Stripe, email và các nhà cung cấp AI đều dùng chúng. Để biết thêm, xem biến môi trường và secret là gì.

• Bắt buộc: Khóa được lưu trong biến môi trường hoặc secret của dự án, không bao giờ được ghi vào mã.
• Bắt buộc: Các khóa có thể tiêu tiền hoặc đọc dữ liệu riêng tư chỉ được dùng trên máy chủ. Kiểm tra: mở website đang chạy, xem mã nguồn trang và các file JavaScript trong devtools, rồi tìm phần đầu của khóa (ví dụ sk_). Nó không được xuất hiện.
• Bắt buộc: Khóa không bao giờ được dán vào chat, kho mã công khai hay ảnh chụp màn hình. Nếu đã từng, hãy thu hồi và tạo khóa mới tại nhà cung cấp (tạo khóa mới, xóa khóa cũ).
• Nên làm: Dùng khóa có giới hạn hoặc phạm vi khi nhà cung cấp hỗ trợ. Ví dụ, Stripe khuyến nghị khóa giới hạn chỉ có các quyền mà tích hợp cần.
• Nên làm: Khóa thử nghiệm và khóa thật tách biệt, và ứng dụng thật chỉ dùng khóa thật khi bạn đã sẵn sàng.

Một số khóa được thiết kế để công khai — khóa publishable của Stripe (pk_…) hoặc khóa bản đồ bị giới hạn theo tên miền của bạn. Quy tắc áp dụng cho các khóa có quyền lực, không phải mọi chuỗi trông giống khóa.

5. Kiểm tra đầu vào

Bất cứ thứ gì người dùng gửi — trường biểu mẫu, tệp tải lên, tham số URL — đều có thể là bất cứ thứ gì, không chỉ những gì biểu mẫu của bạn cho phép.

• Bắt buộc: Việc kiểm tra diễn ra trên máy chủ, không chỉ trong trình duyệt. Kiểm tra trên trình duyệt chỉ để tiện lợi; ai cũng có thể bỏ qua.
• Bắt buộc: Truy vấn cơ sở dữ liệu dùng tham số, không dùng văn bản ghép từ đầu vào của người dùng (điều này ngăn SQL injection). Yêu cầu AI xác nhận.
• Bắt buộc: Văn bản người dùng nhập được hiển thị như văn bản, không được chạy như HTML. Kiểm tra: nhập <b>hello</b> làm tên của bạn. Bạn phải thấy các thẻ, không phải chữ in đậm.
• Nên làm: Tệp tải lên được kiểm tra loại và kích thước, và các tệp đã tải lên không được phục vụ từ tên miền chính của ứng dụng như các trang có thể chạy.
• Nên làm: Lỗi hiển thị cho người dùng phải đơn giản (“Đã xảy ra lỗi”); chi tiết lỗi chỉ ghi vào nhật ký máy chủ.
• Nên làm: Webhook từ các dịch vụ như Stripe xác minh chữ ký của nhà cung cấp trước khi hành động. Xem webhook là gì.

Thêm kiểm tra đầu vào phía máy chủ cho mọi biểu mẫu và endpoint API: trường bắt buộc, độ dài, định dạng và giá trị cho phép. Từ chối mọi thứ khác bằng thông báo rõ ràng. Đừng hiển thị chi tiết lỗi nội bộ cho người dùng.

6. Giới hạn tần suất và lạm dụng

Giới hạn tần suất giới hạn số yêu cầu một người có thể gửi trong một khoảng thời gian. Không có nó, bất kỳ ai cũng có thể đoán mật khẩu cả ngày, làm ngập form đăng ký hoặc đẩy hóa đơn API trả phí của bạn lên cao.

• Bắt buộc: Đăng nhập, đăng ký và đặt lại mật khẩu được giới hạn tần suất theo địa chỉ IP và theo tài khoản.
• Bắt buộc: Bất cứ thứ gì tốn tiền của bạn cho mỗi lần gọi — yêu cầu tới mô hình AI, SMS, email — có giới hạn theo người dùng và yêu cầu đăng nhập.
• Nên làm: Các biểu mẫu công khai (liên hệ, danh sách chờ) có chống spam: giới hạn tần suất, trường ẩn honeypot hoặc CAPTCHA.
• Nên làm: Đặt giới hạn chi tiêu hoặc cảnh báo tại các nhà cung cấp trả phí, để một lỗi hay kẻ tấn công không thể tạo ra hóa đơn không giới hạn.

7. Thư viện phụ thuộc

Ứng dụng được xây từ các gói mã nguồn mở, và các gói này đôi khi có lỗ hổng đã biết.

• Nên làm: Yêu cầu AI kiểm tra các lỗ hổng đã biết (với dự án JavaScript, npm audit hoặc công cụ tương đương của trình quản lý gói) và cập nhật những gói bị ảnh hưởng.
• Nên làm: Xóa các gói mà ứng dụng không dùng nữa.
• Nên làm: Cẩn thận với các gói có rất ít người dùng hoặc có tên giống lỗi chính tả của những gói phổ biến.
• Sau này: Kiểm tra lại mỗi một hoặc hai tháng, hoặc bật cảnh báo tự động nếu mã của bạn nằm trên GitHub.

8. Sao lưu và khôi phục

Bảo mật bao gồm khả năng khôi phục sau sai sót — của bạn, của AI, hoặc của kẻ tấn công.

• Bắt buộc: Biết dữ liệu của bạn nằm ở đâu và có được sao lưu không. Đừng cho là có; hãy kiểm tra tài liệu của nhà cung cấp hosting.
• Nên làm: Giữ bản xuất dữ liệu định kỳ của riêng bạn cho những dữ liệu quan trọng (ví dụ tính năng xuất CSV hoặc bản dump cơ sở dữ liệu), lưu ở nơi tách biệt.
• Nên làm: Giữ mã nguồn trong hệ thống quản lý phiên bản để có thể khôi phục bất kỳ phiên bản nào.
• Nên làm: Các hành động phá hủy (xóa tài khoản, xóa dự án) yêu cầu xác nhận, và cân nhắc “xóa mềm” có thể hoàn tác trong một thời gian.
• Sau này: Thực sự thử khôi phục một lần. Một bản sao lưu chưa bao giờ được khôi phục chỉ là hy vọng, không phải kế hoạch.

9. Trước khi ra mắt

• Bắt buộc: Website đang chạy dùng HTTPS ở mọi nơi.
• Bắt buộc: Dữ liệu mẫu, tài khoản thử nghiệm và trang gỡ lỗi từ giai đoạn phát triển đã được xóa.
• Nên làm: Chính sách quyền riêng tư nêu rõ bạn thu thập dữ liệu gì và vì sao — nhiều nơi yêu cầu điều này nếu bạn thu thập dữ liệu cá nhân. Đừng khẳng định các chứng nhận (SOC 2, HIPAA) mà bạn không có.
• Nên làm: Bạn có cách để được liên hệ về các vấn đề bảo mật, và bạn biết cách thu hồi mọi khóa thật nhanh chóng.

Để có một lượt rà soát rộng hơn trước khi ra mắt, ngoài bảo mật, xem cách đưa prototype AI lên production.

Khi nào nên nhờ chuyên gia rà soát

Danh sách kiểm tra bắt được các lỗi phổ biến; nó không thay thế chuyên gia. Hãy cân nhắc trả tiền để được rà soát nếu bạn tự xử lý số thẻ thay vì qua trang thanh toán được lưu trữ, lưu dữ liệu sức khỏe, tài chính hoặc trẻ em, bán cho các công ty yêu cầu bảng câu hỏi bảo mật, hoặc sẽ bị tổn hại nghiêm trọng nếu có rò rỉ. Việc mã của bạn có thể xuất ra sẽ giúp việc rà soát dễ hơn nhiều.

Bảo mật khi xây dựng trên Mythex

Mythex không có bảng quét bảo mật, nên danh sách trên là quy trình bạn cần làm theo. Một số điều giúp ích:

• Bí mật của dự án. Lưu khóa trong cài đặt dự án → Secrets, hoặc qua thẻ secret mà agent hiển thị trong chat, để chúng nằm ngoài mã và tin nhắn của bạn. Sau khi thay đổi một secret cho ứng dụng đang chạy, hãy xuất bản lại.
• Chế độ Plan và Ask. Yêu cầu agent xem xét quyền mà không chỉnh sửa: “Ở chế độ Ask, liệt kê mọi route API và kiểm tra quyền mà nó thực hiện.”
• /test để agent nhấp qua bản xem trước của bạn như một người dùng — hữu ích cho kiểm tra hai tài khoản ở mục 2.
• Checkpoint cho phép bạn hoàn tác một thay đổi làm hỏng thứ gì đó.

Xem Bảo mật cho ứng dụng bạn xây và Biến môi trường và secret trong tài liệu. Nếu bạn đang thêm tài khoản người dùng tiếp theo, hãy đọc cách thêm đăng nhập vào ứng dụng.

Câu hỏi thường gặp