Vibe coding có thể tạo ứng dụng nhanh, nhưng mã sinh ra vẫn cần được kiểm tra như mọi thay đổi phần mềm. Trước khi triển khai, rà secret, xác thực, phân quyền, input, dependency, cấu hình và log; thử trên môi trường riêng bằng dữ liệu giả. Nhờ người hiểu mã review luồng nhạy cảm trước khi phát hành.
Vì sao mã từ AI cần được kiểm tra?
Công cụ sinh mã tối ưu để tạo đoạn code có vẻ phù hợp với yêu cầu, nhưng không tự biết mọi chính sách nội bộ, cấu hình triển khai hay quyền truy cập mà ứng dụng cần. Một demo có thể chạy được nhưng chứa khóa API trong JavaScript, kiểm tra quyền chỉ ở frontend, dùng phiên bản dependency dễ tổn thương hoặc ghi cả token vào log.
Rủi ro thường nằm ở chỗ kết nối giữa các file: frontend gửi request nào, backend kiểm tra gì, database có giới hạn quyền ra sao, lỗi được hiển thị thế nào và secret lấy từ đâu. Vì vậy, không chỉ đọc component vừa tạo; cần lần theo một luồng hoàn chỉnh từ đầu vào tới dữ liệu lưu và phản hồi. OWASP Top 10 hiện hành liệt kê các nhóm như broken access control, security misconfiguration, supply-chain failures và injection; đây là gợi ý để rà soát, không phải danh sách thay thế kiểm thử ứng dụng cụ thể.
9 rủi ro cần kiểm tra trong sản phẩm vibe coding
| Rủi ro | Dấu hiệu thường gặp | Kiểm tra trước triển khai |
|---|---|---|
| 1. Secret bị lộ | API key, token hoặc mật khẩu nằm trong source, file cấu hình công khai hoặc lịch sử Git | Tìm secret trong code và lịch sử; chuyển khóa sang secret store/server env; thu hồi khóa đã lộ |
| 2. Xác thực thiếu | API nhạy cảm vẫn trả dữ liệu khi không có session hợp lệ | Gửi request khi chưa đăng nhập, session hết hạn và token không hợp lệ |
| 3. Phân quyền sai | Đổi ID trong URL/request để xem hoặc sửa dữ liệu của tài khoản khác | Kiểm tra quyền ở server cho từng tài nguyên; thử nhiều vai trò/tài khoản |
| 4. Input không được giới hạn | Trường tìm kiếm, upload hoặc truy vấn nối trực tiếp từ dữ liệu người dùng | Kiểm tra kiểu, độ dài, encoding; dùng parameterized query và validation phía server |
| 5. Output xử lý không an toàn | Render HTML do người dùng/model tạo như nội dung đáng tin | Escape/sanitize theo ngữ cảnh, kiểm tra URL/Markdown và quyền gọi tool |
| 6. Dependency đáng ngờ | Package lạ được thêm chỉ để sửa lỗi; phiên bản không khóa | Xác nhận tên, nguồn, giấy phép, trạng thái bảo trì và cảnh báo lỗ hổng |
| 7. Cấu hình triển khai yếu | Debug mode bật, CORS mở rộng, database/console lộ ra internet | Rà env production, firewall, HTTPS, quyền tối thiểu và cổng công khai |
| 8. Dữ liệu cá nhân dùng trong thử nghiệm | Prompt, screenshot, log hoặc dataset chứa thông tin khách hàng thật | Dùng dữ liệu giả/ẩn danh; kiểm tra chính sách công cụ AI và thời hạn log |
| 9. Thiếu log và phương án khôi phục | Không biết request nào sửa dữ liệu hoặc không thể quay lại bản ổn định | Ghi log tối thiểu cần thiết, backup, alert và thử rollback trong môi trường staging |
Review theo luồng thay vì chỉ nhìn giao diện
Luồng đăng nhập: kiểm tra cách tạo session/token, hết hạn, đăng xuất và đổi mật khẩu. Xem server có thật sự từ chối API khi người dùng chưa xác thực hay chỉ ẩn nút trên giao diện. Thử request trực tiếp bằng công cụ developer hoặc test tự động.
Luồng đọc/sửa dữ liệu: xác định record thuộc về ai. Nếu endpoint nhận user_id hoặc order_id từ browser, backend cần so quyền truy cập với người dùng hiện tại, không tin giá trị gửi lên. Thử thay ID bằng dữ liệu của tài khoản khác ở staging; kỳ vọng là từ chối mà không tiết lộ nội dung.
Luồng nhập dữ liệu: theo dõi input từ form qua API tới database, file hoặc shell. Kiểm tra độ dài, kiểu dữ liệu, ký tự đặc biệt và file upload. Tham số hóa truy vấn thay vì ghép chuỗi SQL. Nếu ứng dụng dùng model để tạo truy vấn hay lệnh, không thực thi đầu ra mà không giới hạn quyền và xác minh.
Luồng deploy: tìm nơi cấu hình secret, domain, CORS, quyền database, storage và log. Tách development, staging, production; không dùng credential production trong local. Kiểm tra build không đóng gói file .env hoặc dữ liệu test. README tạo bởi AI cũng cần review để tránh vô tình ghi thông tin nhạy cảm.
Ví dụ: rà soát ứng dụng đặt lịch do AI tạo
Giả sử một prompt tạo ra ứng dụng đặt lịch tư vấn. Người dùng đăng nhập, chọn thời gian, nhập ghi chú và xem lịch sử đặt. Giao diện hoạt động với tài khoản thử nên người phát triển định public. Trong review, cần kiểm tra API GET /appointments/{id}: nếu backend chỉ tra theo ID nhận từ URL mà không xác nhận lịch đó thuộc người dùng hiện tại, ai đoán được ID có thể xem lịch của người khác. Ẩn nút “sửa” trên giao diện không giải quyết lỗi này.
Tiếp theo, xem ghi chú và trường tìm kiếm. Nếu nội dung người dùng được render thẳng thành HTML, có thể tạo nguy cơ script chạy trong trình duyệt. Nếu truy vấn database nối chuỗi, ký tự đặc biệt có thể làm thay đổi truy vấn. Dùng validation, parameterized query và encoding phù hợp với ngữ cảnh; thêm test với ký tự thường, ký tự đặc biệt, trường rỗng và độ dài lớn. Với upload biên lai, kiểm tra loại file, dung lượng, nơi lưu, quyền đọc và cách xóa; không tin đuôi file do browser gửi.
Trong môi trường staging, thử account A tạo lịch rồi dùng account B gọi thẳng API với ID của A. Kết quả mong đợi là server từ chối mà không tiết lộ tên, thời gian hay ghi chú. Thử request chưa đăng nhập, session hết hạn và thao tác liên tiếp. Ghi lại bằng chứng test, sửa backend và chạy lại sau mỗi thay đổi. Nếu ứng dụng dùng API key để gửi thông báo, xác nhận khóa chỉ có ở server và khóa cũ không còn trong bundle hoặc Git history.
Cuối cùng kiểm tra chức năng xóa và sửa lịch: ai được phép, có audit trail phù hợp và backup không. Chạy trên dữ liệu giả; chưa kết nối calendar, email hay database thật tới khi kiểm tra quyền. Trường hợp sau review vẫn chưa rõ ai được xem ghi chú, chưa public cho tới khi người phụ trách xác định chính sách truy cập. Ví dụ cho thấy một app nhỏ vẫn có thể chứa nhiều luồng nhạy cảm dù giao diện chỉ có vài màn hình.
Checklist trước khi public
- Tạo bản sao hoặc branch và kiểm tra diff để thấy chính xác mã AI đã thêm/sửa.
- Xác định chức năng, loại dữ liệu và hành động có hậu quả; đánh dấu endpoint và bảng nhạy cảm.
- Chạy formatter, test hiện có, dependency audit và công cụ scan secret phù hợp.
- Kiểm thử không đăng nhập, quyền thấp, ID không thuộc người dùng, input rỗng/lớn/sai kiểu.
- Kiểm tra upload, output HTML, lỗi trả về, rate limit và tác vụ tốn tài nguyên.
- Rà cấu hình production, CORS, HTTPS, database permission, backup và log.
- Nhờ người có kinh nghiệm review các luồng xác thực, thanh toán, dữ liệu cá nhân hoặc quản trị.
- Triển khai staging với dữ liệu giả, theo dõi, xác nhận rollback rồi mới mở cho người dùng.
Các công cụ quét hỗ trợ phát hiện một số vấn đề, nhưng không chứng minh ứng dụng an toàn. Secret scanning có thể phát hiện credential đã commit trong repository; developer vẫn phải thu hồi khóa, kiểm tra nơi đã bị sử dụng và thay bằng credential mới. Dependency scanner cũng cần người xem xét liệu lỗ hổng có ảnh hưởng tới cách package được dùng.
Nếu phát hiện khóa API hoặc dữ liệu bị lộ
Nếu khóa bí mật xuất hiện trong repo hoặc log, coi khóa có thể đã bị người khác đọc. Thu hồi hoặc rotate khóa tại dịch vụ cấp credential, kiểm tra hoạt động bất thường, xóa khỏi phiên bản đang chạy và lưu dấu vết xử lý. Xóa dòng trong commit mới không xóa khóa khỏi lịch sử Git; xử lý lịch sử cần cẩn thận và không thay thế việc vô hiệu hóa credential.
Nếu ứng dụng đã public nhưng phát hiện lỗi phân quyền, cân nhắc tắt chức năng hoặc giới hạn truy cập trước khi sửa; bảo toàn log cần thiết theo chính sách, báo người phụ trách và đánh giá dữ liệu nào có thể bị truy cập. Không chạy lệnh phá hủy hoặc xóa database trong lúc điều tra nếu chưa có backup xác minh.
Với lỗi chưa hiểu, tái hiện trên môi trường riêng bằng dữ liệu giả, xác định request và quyền cần thiết để xảy ra lỗi, sau đó sửa một thay đổi nhỏ và thêm test ngăn tái diễn. AI có thể gợi ý cách điều tra nhưng người chịu trách nhiệm phải kiểm tra tác động và xác nhận bản sửa.
Thành phần bảo mật cần hiểu trong ứng dụng
- Secret: credential dùng để truy cập API, database hoặc dịch vụ.
- Authentication: xác minh người đang gửi yêu cầu là ai.
- Authorization: xác định người đó được phép đọc hoặc làm gì.
- Input validation: kiểm tra dữ liệu có đúng kiểu và giới hạn đã đặt.
- Dependency: thư viện ngoài mà ứng dụng gọi để thực hiện chức năng.
- Staging: môi trường thử gần production nhưng dùng dữ liệu kiểm soát.
- Rollback: quay về phiên bản ổn định khi phát hành mới gây sự cố.
Bài liên quan trên FUNiX
Câu hỏi thường gặp
AI tạo mã có mặc định an toàn không?
Không. Mã có thể phù hợp với demo nhưng thiếu kiểm tra quyền, xử lý input hoặc cấu hình production. Review theo luồng và kiểm thử với vai trò khác nhau trước khi phát hành.
Xóa API key khỏi file là đủ khi đã commit lên Git?
Chưa đủ. Rotate hoặc thu hồi key trước, vì key có thể còn trong lịch sử commit, bản build, log hay bản sao. Sau đó kiểm tra hoạt động và chuyển credential sang nơi lưu an toàn.
Có thể dùng dữ liệu khách hàng để debug không?
Chỉ khi được phép và theo chính sách của tổ chức. Ưu tiên dữ liệu giả hoặc đã ẩn danh; không đưa dữ liệu nhạy cảm vào công cụ AI hay hệ thống log chưa được phê duyệt.
Một lần quét dependency thành công có chứng minh an toàn?
Không. Scan phát hiện nhóm vấn đề đã biết trong phạm vi công cụ; vẫn cần review code, cấu hình, quyền, luồng dữ liệu và test theo cách người dùng có thể lạm dụng ứng dụng.
Dự án cá nhân nhỏ có cần checklist dài không?
Phạm vi kiểm tra có thể theo rủi ro, nhưng tối thiểu nên rà secret, xác thực/phân quyền, input, dependency và backup. Khi xử lý tài khoản, thanh toán hoặc dữ liệu người khác, tăng mức review.
Kết luận
Sản phẩm tạo bằng vibe coding chỉ nên public sau khi người chịu trách nhiệm hiểu luồng dữ liệu và quyền. Kiểm tra chín nhóm rủi ro, dùng staging, quét secret/dependency và có đường rollback. Với chức năng nhạy cảm, cần review chuyên môn trước khi đưa người dùng thật vào hệ thống.
Bình luận (0
)