Code do Vibe Coding tạo ra có an toàn không?

• Bùi Tấn Lực
• 103
• 12/10/2026

Vibe Coding đang thay đổi cách xây dựng phần mềm. Thay vì tự viết từng dòng mã, người dùng mô tả chức năng bằng ngôn ngữ tự nhiên, sau đó sử dụng AI để tạo code, sửa lỗi và hoàn thiện ứng dụng. Cách làm này giúp rút ngắn thời gian phát triển website, xây dựng công cụ nội bộ và thử nghiệm ý tưởng mà không cần tự xử lý toàn bộ chi tiết kỹ thuật.

Tuy nhiên, việc một website chạy được không đồng nghĩa với việc code bên trong an toàn. Một ứng dụng có thể hiển thị giao diện đẹp, đăng nhập bình thường, lưu dữ liệu thành công nhưng vẫn tồn tại lỗ hổng cho phép người khác truy cập thông tin trái phép, chiếm quyền tài khoản hoặc thay đổi dữ liệu.

Vì vậy, câu hỏi quan trọng không chỉ là AI có viết được code hay không, mà còn là code đó có xử lý dữ liệu đúng cách, kiểm soát quyền truy cập đầy đủ và chống chịu được những hành vi sử dụng ngoài dự kiến hay không.

Code do Vibe Coding tạo ra có thể an toàn, nhưng không mặc nhiên an toàn chỉ vì được AI tạo ra. Mức độ bảo mật phụ thuộc vào yêu cầu ban đầu, cách AI triển khai, những thành phần được sử dụng, quá trình kiểm thử và việc rà soát trước khi đưa ứng dụng vào thực tế.

Vibe Coding có tạo ra code an toàn không?

Câu trả lời là có thể, nhưng cần đánh giá từng sản phẩm cụ thể. AI có khả năng tạo ra những đoạn code đáp ứng các nguyên tắc bảo mật phổ biến, chẳng hạn như sử dụng truy vấn tham số hóa, kiểm tra dữ liệu đầu vào, mã hóa mật khẩu bằng thuật toán phù hợp và phân quyền truy cập. Dù vậy, kết quả thực tế không phải lúc nào cũng đầy đủ hoặc chính xác.

Vibe Coding thường phát triển phần mềm theo từng vòng lặp: người dùng đưa ra yêu cầu, AI sinh code, ứng dụng được chạy thử, sau đó người dùng tiếp tục yêu cầu bổ sung hoặc sửa đổi. Phương pháp này thuận tiện nhưng có thể tạo ra những thay đổi thiếu nhất quán nếu các yêu cầu về bảo mật không được xác định ngay từ đầu.

Code chạy đúng chức năng chưa chắc đã bảo mật

Hãy hình dung bạn yêu cầu AI tạo một trang quản trị đơn hàng. Giao diện hiển thị danh sách đơn hàng, nút cập nhật trạng thái và chức năng tìm kiếm đều hoạt động bình thường. Tuy nhiên, nếu máy chủ không xác minh quyền của người đang thực hiện yêu cầu, một tài khoản thông thường có thể tìm cách truy cập hoặc sửa đơn hàng của người khác.

Trong trường hợp này, chức năng vẫn hoạt động đúng theo những gì người dùng nhìn thấy, nhưng cơ chế bảo vệ dữ liệu lại không đạt yêu cầu. Đây là lý do không thể đánh giá chất lượng bảo mật chỉ bằng cách nhấn thử các nút trên giao diện.

Một số vấn đề khác cũng có thể xuất hiện:

• Biểu mẫu đăng nhập hoạt động nhưng mật khẩu được lưu dưới dạng văn bản thuần.
• Trang quản trị bị ẩn khỏi menu nhưng địa chỉ truy cập vẫn mở được khi chưa đăng nhập.
• Người dùng chỉ được phép xem một số dữ liệu trên giao diện, nhưng API phía máy chủ lại trả về toàn bộ dữ liệu.
• Chức năng tải tệp hoạt động nhưng không giới hạn loại tệp, dung lượng hoặc quyền truy cập.
• Thông tin kết nối cơ sở dữ liệu hoặc khóa API bị đưa trực tiếp vào mã nguồn phía trình duyệt.

Những lỗi như vậy không nhất thiết xuất phát từ việc AI không biết viết code bảo mật. Chúng có thể xuất hiện vì yêu cầu chưa đề cập đến tình huống cần bảo vệ, quá trình triển khai bỏ sót một bước hoặc những thay đổi sau đó làm suy yếu cơ chế an toàn ban đầu.

AI có thể hỗ trợ bảo mật nhưng không thay thế việc xác minh

Các công cụ AI có thể giúp lập trình viên phát hiện những đoạn code đáng ngờ, giải thích nguy cơ của một hàm xử lý dữ liệu hoặc đề xuất cách khắc phục lỗ hổng. AI cũng có thể hỗ trợ viết kiểm thử tự động để kiểm tra các tình huống như truy cập trái phép, dữ liệu đầu vào không hợp lệ và lỗi xác thực.

Tuy nhiên, việc yêu cầu AI kiểm tra code rồi nhận được câu trả lời rằng mọi thứ đều an toàn không phải bằng chứng cho thấy ứng dụng không có lỗ hổng. Công cụ có thể bỏ sót vấn đề, hiểu sai cấu trúc hệ thống hoặc đề xuất cách sửa chỉ giải quyết triệu chứng mà chưa loại bỏ nguyên nhân.

Đặc biệt, những lỗ hổng liên quan đến nhiều thành phần thường khó phát hiện nếu chỉ xem xét từng đoạn code riêng lẻ. Một API có thể được viết đúng về mặt cú pháp nhưng vẫn không an toàn khi kết hợp với cơ chế phân quyền sai hoặc cấu hình máy chủ không phù hợp.

Những yếu tố quyết định mức độ an toàn của code AI

Không phải mọi dự án Vibe Coding đều có mức độ rủi ro giống nhau. Một công cụ chuyển đổi định dạng văn bản chạy hoàn toàn trên trình duyệt có yêu cầu bảo mật khác với website thương mại điện tử lưu thông tin khách hàng, quản lý thanh toán và xử lý dữ liệu đơn hàng.

Để đánh giá đúng mức độ an toàn, cần xem xét ít nhất những yếu tố sau.

Yêu cầu bảo mật được đưa ra từ đầu

AI thường tập trung giải quyết những gì người dùng mô tả. Nếu yêu cầu chỉ là tạo chức năng đăng nhập, hệ thống có thể được xây dựng với mục tiêu làm cho việc đăng nhập hoạt động, trong khi những vấn đề như giới hạn số lần thử mật khẩu, thời hạn phiên đăng nhập, bảo vệ cookie và quy trình đặt lại mật khẩu chưa được xử lý đầy đủ.

Yêu cầu càng rõ ràng về quyền truy cập, dữ liệu nhạy cảm và những tình huống có thể bị khai thác, khả năng triển khai đúng càng cao. Ngược lại, những yêu cầu chung chung dễ khiến AI lựa chọn cách làm đơn giản nhất để đáp ứng chức năng trước mắt.

Chẳng hạn, thay vì chỉ yêu cầu tạo chức năng quản lý khách hàng, nên xác định rõ mỗi nhân viên chỉ được xem dữ liệu thuộc phạm vi được cấp quyền, máy chủ phải kiểm tra quyền trên mọi yêu cầu và không được trả về thông tin nhạy cảm không cần thiết.

Công nghệ và thư viện được sử dụng

Ứng dụng do Vibe Coding tạo ra có thể sử dụng PHP, JavaScript, Python, các framework giao diện, thư viện xác thực và nhiều thành phần bên ngoài. Mỗi thành phần đều có thể ảnh hưởng đến mức độ bảo mật chung.

Nếu AI lựa chọn một thư viện đã lỗi thời, sử dụng sai chức năng của framework hoặc tạo ra cách xử lý không phù hợp với môi trường triển khai, ứng dụng có thể phát sinh lỗ hổng dù từng đoạn code riêng lẻ trông hợp lý.

Đối với website PHP, chẳng hạn, sử dụng PDO không tự động bảo đảm mọi truy vấn cơ sở dữ liệu đều an toàn. Lập trình viên vẫn phải sử dụng truy vấn tham số hóa đúng cách, tránh ghép trực tiếp dữ liệu không đáng tin cậy vào câu lệnh SQL và kiểm tra quyền truy cập đối với từng thao tác.

Tương tự, việc sử dụng một framework phổ biến cũng không có nghĩa ứng dụng mặc nhiên an toàn. Cấu hình, phiên bản thư viện và cách triển khai các chức năng vẫn cần được kiểm tra.

Cách xử lý dữ liệu đầu vào và đầu ra

Dữ liệu do người dùng gửi lên là một trong những nguồn rủi ro phổ biến nhất. Nội dung nhập vào biểu mẫu, tham số trên URL, dữ liệu từ API hoặc tệp tải lên đều có thể bị cố tình sửa đổi để thực hiện những hành vi ngoài dự kiến.

Nếu code do AI tạo ra tin tưởng dữ liệu đầu vào mà không kiểm tra, ứng dụng có thể gặp lỗi SQL Injection, Cross-Site Scripting (XSS), truy cập tài nguyên trái phép hoặc các vấn đề liên quan đến xử lý tệp.

Cách bảo vệ cần phù hợp với từng ngữ cảnh. Dữ liệu dùng trong truy vấn SQL cần được xử lý bằng cơ chế truy vấn tham số hóa; dữ liệu đưa vào HTML cần được mã hóa đầu ra phù hợp; những giá trị dùng để xác định tài nguyên hoặc quyền truy cập phải được kiểm tra theo quy tắc nghiệp vụ.

Chỉ kiểm tra xem dữ liệu có bị bỏ trống hay không thường chưa đủ. Một giá trị có thể đúng định dạng nhưng vẫn không hợp lệ về nghiệp vụ hoặc vượt quá quyền của người gửi yêu cầu.

Kiểm soát quyền truy cập ở phía máy chủ

Giao diện chỉ có nhiệm vụ hỗ trợ người dùng thao tác. Những quyết định quan trọng về xác thực, phân quyền và bảo vệ dữ liệu phải được thực hiện ở phía máy chủ hoặc tại một lớp thực thi quyền đáng tin cậy.

Ví dụ, việc ẩn nút xóa người dùng đối với tài khoản nhân viên không thể thay thế việc kiểm tra quyền xóa trên máy chủ. Nếu API vẫn chấp nhận yêu cầu xóa từ người không có quyền, cơ chế bảo vệ đó có thể bị vượt qua bằng cách gửi yêu cầu trực tiếp.

Với website có nhiều vai trò như quản trị viên, nhân viên, khách hàng và cộng tác viên, cần kiểm tra không chỉ vai trò của tài khoản mà còn phạm vi dữ liệu mà tài khoản đó được phép thao tác.

Một tài khoản đã đăng nhập không đồng nghĩa với việc tài khoản đó được phép xem mọi đơn hàng, sửa mọi hồ sơ hoặc sử dụng mọi chức năng quản trị.

Quá trình kiểm thử và rà soát trước khi triển khai

Ngay cả khi yêu cầu ban đầu tốt và code được tạo bằng công cụ AI có chất lượng, ứng dụng vẫn cần được kiểm thử. Những thay đổi liên tục trong quá trình Vibe Coding có thể làm xuất hiện lỗi mới, đặc biệt khi một chức năng được sửa mà không kiểm tra lại các chức năng liên quan.

Quá trình đánh giá nên kết hợp nhiều phương pháp: đọc lại code, kiểm thử chức năng, kiểm tra quyền truy cập, quét lỗ hổng tự động, rà soát thư viện phụ thuộc và kiểm tra cấu hình triển khai.

Đối với hệ thống xử lý dữ liệu quan trọng, kiểm thử bảo mật chuyên sâu còn cần xem xét cách các thành phần tương tác với nhau, khả năng lạm dụng quy trình nghiệp vụ và những tình huống không thể phát hiện chỉ bằng công cụ quét tự động.

Nói cách khác, AI có thể giúp tạo ra sản phẩm nhanh hơn, nhưng độ an toàn cuối cùng vẫn phụ thuộc vào cách sản phẩm được xây dựng, kiểm tra và vận hành.

Những lỗ hổng bảo mật thường gặp trong dự án Vibe Coding

Các rủi ro dưới đây không chỉ xuất hiện trong code do AI tạo ra. Chúng cũng phổ biến trong những dự án được lập trình thủ công. Điểm cần lưu ý là Vibe Coding có thể khiến người phát triển hoàn thiện chức năng nhanh hơn khả năng hiểu và kiểm tra toàn bộ hệ thống, từ đó làm tăng nguy cơ bỏ sót vấn đề.

SQL Injection khi truy vấn cơ sở dữ liệu

SQL Injection xảy ra khi dữ liệu không đáng tin cậy được đưa vào câu lệnh SQL theo cách cho phép thay đổi cấu trúc hoặc ý nghĩa của truy vấn. Lỗ hổng này có thể khiến kẻ tấn công đọc dữ liệu trái phép, sửa thông tin hoặc thực hiện những thao tác vượt quá dự kiến, tùy vào quyền của tài khoản cơ sở dữ liệu và cách ứng dụng được xây dựng.

Với website PHP, một cách làm nguy hiểm là nối trực tiếp dữ liệu nhận được từ URL vào câu truy vấn. Cách an toàn hơn là sử dụng prepared statements với tham số được truyền riêng, đồng thời giới hạn quyền của tài khoản cơ sở dữ liệu theo nhu cầu thực tế.

Điều quan trọng là phải rà soát toàn bộ những vị trí tạo truy vấn, thay vì chỉ sửa một câu lệnh mà công cụ AI đã chỉ ra. Một dự án có thể sử dụng truy vấn tham số hóa ở phần đăng nhập nhưng vẫn tồn tại truy vấn không an toàn trong chức năng tìm kiếm, lọc dữ liệu hoặc báo cáo.

XSS khi hiển thị nội dung do người dùng cung cấp

Cross-Site Scripting là nhóm lỗ hổng cho phép nội dung không đáng tin cậy được trình duyệt diễn giải thành mã thực thi trong ngữ cảnh của website. Tùy trường hợp, lỗ hổng có thể bị lợi dụng để thao túng giao diện, thực hiện hành động dưới danh nghĩa người dùng hoặc lấy thông tin mà mã độc có thể truy cập.

Rủi ro có thể xuất hiện trong chức năng bình luận, hồ sơ cá nhân, nội dung bài viết, thông báo hoặc trang quản trị nếu dữ liệu được hiển thị mà không xử lý đúng cách.

Biện pháp bảo vệ không đơn giản là loại bỏ một vài ký tự đặc biệt. Ứng dụng cần mã hóa đầu ra theo đúng ngữ cảnh HTML, thuộc tính, URL hoặc JavaScript; nếu cho phép nội dung HTML do người dùng tạo, cần sử dụng cơ chế làm sạch HTML phù hợp. Content Security Policy có thể bổ sung một lớp bảo vệ, nhưng không thay thế việc xử lý dữ liệu đúng cách.

Lỗi xác thực và phân quyền

Đây là nhóm rủi ro đặc biệt đáng chú ý ở các website có tài khoản người dùng, trang quản trị, dữ liệu riêng tư hoặc chức năng thanh toán.

Code có thể cho phép đăng nhập thành công nhưng xử lý phiên đăng nhập không an toàn, không giới hạn việc thử mật khẩu hoặc không thu hồi phiên khi người dùng đăng xuất. Một vấn đề khác là kiểm tra quyền không đồng nhất giữa giao diện và API.

Đối với tài nguyên thuộc về từng người dùng, máy chủ cần xác minh quyền trên từng yêu cầu. Không nên mặc định rằng người gửi yêu cầu được phép truy cập dữ liệu chỉ vì họ đã biết mã đơn hàng, ID tài khoản hoặc đường dẫn của tài nguyên đó.

Rò rỉ khóa API và thông tin bí mật

Trong quá trình tạo ứng dụng, AI có thể đề xuất đặt khóa API, mật khẩu cơ sở dữ liệu hoặc thông tin xác thực trực tiếp trong mã nguồn để việc chạy thử thuận tiện hơn. Nếu những giá trị này được đưa vào JavaScript phía trình duyệt, kho mã nguồn công khai hoặc tệp cấu hình có thể truy cập từ bên ngoài, người khác có khả năng lấy được chúng.

Thông tin bí mật cần được lưu trong biến môi trường hoặc hệ thống quản lý bí mật phù hợp với môi trường triển khai. Những giá trị chỉ dùng ở phía máy chủ không được gửi xuống trình duyệt. Tệp chứa thông tin cấu hình cũng cần được bảo vệ khỏi truy cập công khai.

Nếu một khóa bí mật đã bị lộ, chỉ xóa khóa khỏi đoạn code hiện tại là chưa đủ. Cần thu hồi hoặc thay thế khóa, kiểm tra lịch sử sử dụng và đánh giá xem dữ liệu hay dịch vụ liên quan có bị truy cập trái phép hay không.

Trong trường hợp website sử dụng Git hoặc một hệ thống quản lý phiên bản khác, cần kiểm tra cả lịch sử commit vì thông tin bí mật đã xóa khỏi phiên bản mới vẫn có thể tồn tại trong lịch sử cũ.

Những lỗ hổng trên cho thấy code do Vibe Coding tạo ra cần được đánh giá dựa trên cách hệ thống bảo vệ dữ liệu và kiểm soát hành vi thực tế, không phải chỉ dựa vào việc ứng dụng có chạy ổn định hay không.

Cách kiểm tra code do Vibe Coding tạo ra có an toàn hay không

Muốn đánh giá mức độ an toàn của một dự án Vibe Coding, bạn không nên chỉ yêu cầu AI đọc code rồi trả lời rằng ứng dụng có bảo mật hay không. Cách làm hiệu quả hơn là kiểm tra theo từng lớp, từ mã nguồn, dữ liệu đầu vào, cơ chế phân quyền đến cấu hình máy chủ và những tình huống người dùng có thể cố tình lạm dụng.

Ngay cả khi chưa có nhiều kinh nghiệm lập trình, bạn vẫn có thể thực hiện một số bước kiểm tra ban đầu. Tuy nhiên, với ứng dụng chứa dữ liệu khách hàng, thông tin tài chính hoặc chức năng quan trọng, những bước này chỉ giúp sàng lọc rủi ro, không thay thế được quá trình kiểm thử bảo mật chuyên nghiệp.

Kiểm tra những vị trí có nguy cơ cao trong mã nguồn

Thay vì đọc toàn bộ dự án một cách ngẫu nhiên, hãy ưu tiên các phần có thể ảnh hưởng trực tiếp đến dữ liệu và quyền truy cập:

• Đăng nhập và đăng xuất: Kiểm tra cách xác minh mật khẩu, quản lý phiên đăng nhập, xử lý cookie và thu hồi phiên.
• Truy vấn cơ sở dữ liệu: Tìm những câu lệnh SQL được tạo bằng cách nối chuỗi hoặc sử dụng dữ liệu do người dùng gửi lên mà chưa xử lý đúng cách.
• API và các trang quản trị: Xác minh máy chủ có kiểm tra quyền trên từng yêu cầu hay chỉ ẩn chức năng trên giao diện.
• Tải tệp: Kiểm tra giới hạn dung lượng, loại tệp, tên tệp, vị trí lưu trữ và quyền truy cập tệp đã tải lên.
• Cấu hình và thông tin bí mật: Tìm mật khẩu, khóa API, thông tin kết nối cơ sở dữ liệu hoặc dữ liệu nhạy cảm được đưa trực tiếp vào mã nguồn.
• Thư viện bên ngoài: Xác định các gói phụ thuộc đã lỗi thời, có cảnh báo bảo mật hoặc không còn được duy trì.
• Xử lý lỗi và ghi nhật ký: Kiểm tra xem thông báo lỗi có làm lộ đường dẫn nội bộ, truy vấn, thông tin xác thực hoặc dữ liệu cá nhân hay không.

Nếu dự án có nhiều thư mục, hãy yêu cầu AI lập bản đồ cấu trúc ứng dụng trước khi bắt đầu rà soát. Cần xác định đâu là điểm tiếp nhận dữ liệu, đâu là nơi xử lý nghiệp vụ, đâu là lớp truy cập cơ sở dữ liệu và cơ chế phân quyền được triển khai ở đâu.

Việc hiểu mối liên hệ giữa các thành phần giúp phát hiện những lỗi không thể nhận ra nếu chỉ xem xét một tệp riêng lẻ.

Sử dụng công cụ kiểm tra bảo mật thay vì chỉ dựa vào AI

AI có thể hỗ trợ rà soát code, nhưng bạn nên kết hợp thêm những công cụ phù hợp với công nghệ của dự án. Mỗi công cụ có phạm vi phát hiện khác nhau, vì vậy không nên coi một kết quả quét sạch là bằng chứng tuyệt đối về an toàn.

Phương pháp	Mục đích	Giới hạn cần lưu ý
Rà soát mã nguồn	Phát hiện cách xử lý dữ liệu, xác thực hoặc phân quyền có dấu hiệu không an toàn.	Có thể bỏ sót lỗi phụ thuộc vào luồng xử lý giữa nhiều thành phần.
Phân tích mã nguồn tĩnh (SAST)	Tìm những mẫu code có nguy cơ bảo mật mà không cần thực thi ứng dụng.	Có thể tạo cảnh báo sai hoặc không phát hiện được lỗi nghiệp vụ.
Kiểm tra thư viện phụ thuộc	Phát hiện gói phần mềm có lỗ hổng đã được công bố hoặc phiên bản không an toàn.	Không đánh giá đầy đủ cách ứng dụng sử dụng thư viện.
Kiểm thử ứng dụng đang chạy (DAST)	Gửi các yêu cầu kiểm thử để tìm dấu hiệu lỗ hổng trên ứng dụng.	Phụ thuộc vào phạm vi kiểm thử và khả năng tiếp cận các chức năng.
Kiểm thử phân quyền	Xác minh người dùng không thể thực hiện hành động vượt quá quyền được cấp.	Cần xây dựng tình huống kiểm thử theo vai trò và quy tắc nghiệp vụ thực tế.
Rà soát cấu hình triển khai	Kiểm tra HTTPS, quyền truy cập, cấu hình máy chủ, thông tin bí mật và chế độ gỡ lỗi.	Cần xem xét môi trường triển khai thực tế, không chỉ cấu hình trên máy phát triển.

Với dự án PHP, có thể sử dụng các công cụ phân tích mã nguồn và kiểm tra thư viện phù hợp với phiên bản PHP cùng hệ sinh thái đang triển khai. Đối với website sử dụng JavaScript hoặc Node.js, cần kiểm tra cả mã nguồn ứng dụng lẫn các gói phụ thuộc trong tệp quản lý package.

Khi thực hiện kiểm thử động, hãy sử dụng môi trường thử nghiệm được phép kiểm tra, dữ liệu giả lập và tài khoản thử nghiệm. Không nên tự ý quét những hệ thống không thuộc quyền quản lý của bạn hoặc thử nghiệm các thao tác có thể làm thay đổi dữ liệu thật.

Ví dụ thực tế về lỗi bảo mật trong code do AI tạo ra

Những ví dụ dưới đây minh họa các tình huống có thể xuất hiện trong quá trình Vibe Coding. Chúng không có nghĩa mọi công cụ AI đều tạo ra những lỗi này. Mục tiêu là giúp bạn hiểu cách một chức năng tưởng như bình thường có thể trở thành điểm yếu nếu thiếu cơ chế bảo vệ phù hợp.

Ví dụ về truy vấn SQL không an toàn trong PHP

Giả sử AI tạo chức năng tìm kiếm khách hàng bằng cách nhận từ khóa qua tham số URL rồi đưa trực tiếp vào câu lệnh SQL. Nếu dữ liệu được nối vào truy vấn mà không có cơ chế xử lý phù hợp, ứng dụng có thể gặp nguy cơ SQL Injection.

Đoạn code minh họa dưới đây thể hiện cách làm không an toàn. Đây là ví dụ phục vụ nhận diện lỗi, không nên sử dụng trong website thực tế.

<?php
$keyword = $_GET['keyword'] ?? '';

$sql = "SELECT id, name FROM customers WHERE name = '$keyword'";

$result = $pdo->query($sql);
?>

Vấn đề nằm ở việc dữ liệu lấy từ URL được ghép trực tiếp vào câu truy vấn. Việc chỉ kiểm tra xem từ khóa có rỗng hay không không giải quyết được nguy cơ này.

Cách phù hợp hơn là sử dụng truy vấn tham số hóa:

<?php
$keyword = $_GET['keyword'] ?? '';

$stmt = $pdo->prepare(
    'SELECT id, name FROM customers WHERE name = :name'
);

$stmt->execute([
    'name' => $keyword
]);

$customers = $stmt->fetchAll(PDO::FETCH_ASSOC);
?>

Trong ví dụ này, dữ liệu được truyền thông qua tham số thay vì ghép trực tiếp vào cấu trúc câu lệnh SQL. Đây là biện pháp quan trọng để giảm nguy cơ SQL Injection.

Tuy nhiên, truy vấn tham số hóa không thay thế các yêu cầu bảo mật khác. Nếu dữ liệu khách hàng cần được giới hạn theo tài khoản đang đăng nhập, ứng dụng vẫn phải kiểm tra quyền truy cập và phạm vi dữ liệu ở phía máy chủ.

Ví dụ về chức năng quản trị chỉ được ẩn trên giao diện

Hãy tưởng tượng AI tạo một trang quản lý người dùng. Trên giao diện, nút xóa tài khoản chỉ xuất hiện khi người dùng có vai trò quản trị viên. Nhìn bằng mắt thường, chức năng có vẻ đã được bảo vệ.

Nhưng nếu API phía máy chủ không xác minh quyền trước khi xóa, người dùng không có quyền vẫn có thể tìm cách gửi yêu cầu trực tiếp đến API đó.

Đây là lỗi phân quyền, không phải lỗi giao diện. Việc ẩn nút hoặc chuyển hướng người dùng khỏi trang quản trị chỉ giúp cải thiện trải nghiệm, không thể thay thế cơ chế kiểm soát quyền ở phía máy chủ.

Để khắc phục, cần bảo đảm mọi yêu cầu xóa tài khoản đều được kiểm tra theo các điều kiện phù hợp:

• Người gửi yêu cầu đã được xác thực.
• Tài khoản có quyền thực hiện hành động xóa.
• Đối tượng cần xóa thuộc phạm vi quản lý hợp lệ.
• Hệ thống xử lý đúng các ràng buộc nghiệp vụ, chẳng hạn như tài khoản đang được sử dụng để quản lý dữ liệu quan trọng.
• Thao tác nhạy cảm được ghi nhật ký phù hợp để phục vụ truy vết khi cần thiết.

Đặc biệt, không nên chỉ kiểm tra quyền khi người dùng mở trang quản trị. Kiểm tra quyền phải được thực hiện ở điểm xử lý yêu cầu, bởi các API có thể được gọi từ nhiều giao diện hoặc công cụ khác nhau.

Ví dụ về lộ khóa API trong mã JavaScript

Một ứng dụng do AI tạo ra có thể cần gọi dịch vụ AI, gửi email hoặc truy xuất dữ liệu từ một nền tảng bên ngoài. Nếu khóa bí mật được đặt trực tiếp trong mã JavaScript gửi xuống trình duyệt, người dùng có thể xem mã nguồn hoặc dữ liệu mạng để tìm khóa.

Với các khóa bí mật chỉ dành cho máy chủ, cách triển khai phù hợp là chuyển thao tác gọi dịch vụ sang backend. Trình duyệt gửi yêu cầu đến backend, backend kiểm tra quyền và điều kiện sử dụng rồi mới gọi dịch vụ bên ngoài bằng thông tin xác thực được lưu ở phía máy chủ.

Quy trình có thể được hình dung như sau:

1. Người dùng thao tác trên giao diện website.
2. Trình duyệt gửi yêu cầu đến API của ứng dụng.
3. Máy chủ xác thực người dùng, kiểm tra quyền và giới hạn sử dụng nếu cần.
4. Máy chủ đọc khóa API từ nơi lưu trữ bí mật phù hợp và gọi dịch vụ bên ngoài.
5. Máy chủ chỉ trả về dữ liệu cần thiết cho trình duyệt, không gửi khóa bí mật xuống phía người dùng.

Cần phân biệt khóa bí mật phía máy chủ với những khóa công khai được thiết kế để sử dụng trong trình duyệt. Không phải mọi chuỗi có tên API key đều có cùng mức độ nhạy cảm. Cách bảo vệ phải dựa trên chức năng và quyền mà khóa thực sự được cấp.

Ví dụ về chức năng tải tệp thiếu kiểm soát

AI có thể tạo một biểu mẫu tải ảnh đại diện hoặc tài liệu lên website. Nếu ứng dụng chỉ kiểm tra phần mở rộng tệp do người dùng gửi lên mà không xác minh nội dung thực tế, giới hạn dung lượng hoặc kiểm soát vị trí lưu trữ, chức năng này có thể tạo ra rủi ro bảo mật.

Với website cho phép tải tệp, cần xây dựng cơ chế bảo vệ phù hợp với loại dữ liệu được chấp nhận. Một số yêu cầu quan trọng gồm:

• Giới hạn dung lượng và số lượng tệp theo nhu cầu thực tế.
• Kiểm tra loại tệp bằng nhiều tín hiệu phù hợp, không chỉ dựa vào tên hoặc phần mở rộng.
• Tạo tên tệp lưu trữ do hệ thống quản lý thay vì tin tưởng hoàn toàn tên do người dùng cung cấp.
• Ngăn tệp tải lên được thực thi như mã chương trình.
• Kiểm tra quyền khi người dùng tải lên, xem, thay thế hoặc xóa tệp.
• Cân nhắc lưu tệp ngoài thư mục công khai và sử dụng cơ chế phân phối tệp có kiểm soát.
• Quét mã độc khi phù hợp với loại tệp và mức độ rủi ro của ứng dụng.

Những ví dụ trên cho thấy vấn đề bảo mật thường không nằm ở việc code có được AI viết hay không, mà ở những điều kiện kiểm tra bị thiếu trong quá trình triển khai. Một chức năng chỉ thực sự hoàn thiện khi đáp ứng cả yêu cầu sử dụng bình thường lẫn những tình huống có thể bị lạm dụng.

Cách viết prompt để AI tạo code an toàn hơn

Chất lượng yêu cầu đầu vào ảnh hưởng đáng kể đến kết quả Vibe Coding. Nếu chỉ mô tả giao diện và chức năng mong muốn, AI có thể ưu tiên tạo ra sản phẩm chạy được mà chưa xem xét đầy đủ các rủi ro liên quan đến dữ liệu, quyền truy cập và cấu hình vận hành.

Để cải thiện kết quả, bạn nên đưa yêu cầu bảo mật vào quá trình phát triển ngay từ đầu, thay vì đợi ứng dụng hoàn thành mới yêu cầu AI kiểm tra.

Yêu cầu AI xác định rủi ro trước khi viết code

Trước khi triển khai một chức năng quan trọng, hãy yêu cầu AI phân tích dữ liệu đầu vào, quyền cần thiết, các thành phần liên quan và những trường hợp có thể bị lạm dụng. Bước này giúp phát hiện yêu cầu còn thiếu trước khi chúng trở thành vấn đề trong mã nguồn.

Ví dụ, khi xây dựng chức năng quản lý đơn hàng, bạn nên xác định ai được xem đơn hàng, ai được cập nhật trạng thái, những trạng thái nào được phép chuyển đổi và cách xử lý khi người dùng gửi yêu cầu không hợp lệ.

Không nên chỉ yêu cầu AI viết code ngay khi yêu cầu còn mơ hồ. Với những chức năng ảnh hưởng đến dữ liệu quan trọng, việc làm rõ quy tắc nghiệp vụ thường có giá trị hơn việc tạo ra một đoạn code nhanh chóng nhưng thiếu điều kiện kiểm soát.

Mẫu prompt yêu cầu tạo code có chú trọng bảo mật

Bạn có thể điều chỉnh mẫu prompt sau cho phù hợp với dự án PHP, JavaScript hoặc ứng dụng sử dụng framework khác:

Hãy triển khai chức năng theo yêu cầu sau: [mô tả chức năng].

Trước khi viết code:
1. Xác định dữ liệu đầu vào, dữ liệu nhạy cảm và quyền truy cập liên quan.
2. Liệt kê các rủi ro bảo mật có thể phát sinh.
3. Làm rõ những yêu cầu còn thiếu có ảnh hưởng đến bảo mật.
4. Đề xuất phương án triển khai phù hợp với cấu trúc hiện tại của dự án.

Yêu cầu khi triển khai:
- Kiểm tra dữ liệu đầu vào theo quy tắc nghiệp vụ.
- Sử dụng truy vấn tham số hóa khi truy cập cơ sở dữ liệu.
- Xác thực người dùng và kiểm tra quyền ở phía máy chủ.
- Mã hóa đầu ra phù hợp với ngữ cảnh hiển thị.
- Không để lộ mật khẩu, khóa API hoặc thông tin bí mật.
- Xử lý lỗi an toàn, không trả về thông tin nội bộ nhạy cảm.
- Giữ nguyên các chức năng hiện có không liên quan.
- Không tự ý thay đổi cấu trúc cơ sở dữ liệu hoặc thư viện nếu chưa giải thích lý do.

Sau khi hoàn thành:
1. Giải thích những thay đổi đã thực hiện.
2. Chỉ ra các biện pháp bảo mật đã áp dụng.
3. Nêu những rủi ro chưa được giải quyết hoặc cần cấu hình thêm.
4. Đề xuất các trường hợp kiểm thử thành công, thất bại và truy cập trái phép.
5. Không khẳng định code hoàn toàn an toàn nếu chưa có đủ bằng chứng kiểm chứng.

Mẫu prompt này không bảo đảm AI sẽ tạo ra code không có lỗ hổng. Giá trị của nó nằm ở việc buộc quá trình phát triển phải xem xét các vấn đề bảo mật một cách có hệ thống, đồng thời yêu cầu AI giải thích những gì đã làm và những gì còn chưa được xác minh.

Yêu cầu AI rà soát lại code sau mỗi thay đổi quan trọng

Trong Vibe Coding, ứng dụng thường được sửa đổi nhiều lần. Một thay đổi nhỏ ở chức năng đăng nhập có thể ảnh hưởng đến phiên làm việc; việc thêm trường dữ liệu có thể làm lộ thông tin trên API; thay đổi thư viện cũng có thể tác động đến những chức năng đã hoạt động trước đó.

Vì vậy, sau mỗi thay đổi quan trọng, hãy yêu cầu AI kiểm tra phần code vừa sửa cùng những thành phần liên quan. Có thể sử dụng yêu cầu ngắn gọn như sau:

Hãy rà soát thay đổi vừa thực hiện theo hướng bảo mật.

Kiểm tra:
- Dữ liệu đầu vào có được xử lý an toàn không.
- Quyền truy cập có được kiểm tra ở phía máy chủ không.
- Có nguy cơ SQL Injection, XSS hoặc lộ thông tin nhạy cảm không.
- Thay đổi có làm hỏng cơ chế xác thực hoặc phân quyền hiện tại không.
- Các trường hợp lỗi và truy cập trái phép đã được kiểm thử chưa.

Với mỗi vấn đề phát hiện được, hãy nêu vị trí liên quan,
nguyên nhân, mức độ ảnh hưởng và phương án khắc phục.

Không tự ý sửa những phần không liên quan.
Sau khi sửa, hãy chạy hoặc đề xuất kiểm thử phù hợp
và nêu rõ những gì chưa được xác minh.

Nếu có hệ thống quản lý phiên bản như Git, hãy xem lại phần thay đổi trước khi chấp nhận code. Điều này giúp bạn xác định AI đã sửa những tệp nào, có vô tình xóa cơ chế bảo vệ hoặc thay đổi hành vi ngoài phạm vi yêu cầu hay không.

Đối với chức năng nhạy cảm, không nên để AI tự động sửa liên tục rồi đưa toàn bộ thay đổi vào môi trường thật mà không có bước xem xét và kiểm thử. Tốc độ tạo code chỉ có lợi khi đi cùng khả năng kiểm soát những thay đổi đó.

Quy trình bảo mật website trước khi đưa code Vibe Coding vào hoạt động

Một dự án Vibe Coding chỉ nên được đưa vào sử dụng khi các chức năng quan trọng đã được kiểm tra và những rủi ro phù hợp với mức độ ảnh hưởng của ứng dụng đã được xử lý. Không nhất thiết mọi website đều cần quy trình kiểm định phức tạp như hệ thống ngân hàng, nhưng bất kỳ ứng dụng nào có tài khoản, dữ liệu cá nhân hoặc chức năng quản trị cũng cần những bước bảo vệ cơ bản.

Đối với website được xây dựng bằng AI, bạn có thể áp dụng quy trình gồm sáu bước dưới đây để giảm nguy cơ đưa code chưa được kiểm chứng lên môi trường thật.

Bước 1: Xác định dữ liệu cần bảo vệ và mức độ rủi ro

Trước khi kiểm tra code, hãy xác định website lưu trữ những loại dữ liệu nào, ai được phép truy cập và thiệt hại có thể xảy ra nếu dữ liệu bị lộ hoặc bị sửa đổi trái phép.

Một website giới thiệu doanh nghiệp có thể chủ yếu cần bảo vệ biểu mẫu liên hệ, tài khoản quản trị và thông tin cấu hình. Trong khi đó, website bán hàng còn phải kiểm soát dữ liệu khách hàng, đơn hàng, lịch sử thanh toán và các thao tác liên quan đến tài chính.

Việc phân loại này giúp bạn ưu tiên đúng vị trí cần kiểm tra. Những thành phần có thể ảnh hưởng đến nhiều người dùng, làm lộ thông tin nhạy cảm hoặc gây thiệt hại lớn cần được đánh giá kỹ hơn so với các chức năng ít rủi ro.

Bước 2: Kiểm tra mã nguồn và thư viện phụ thuộc

Sau khi xác định phạm vi cần bảo vệ, hãy rà soát mã nguồn do AI tạo ra và những thư viện mà dự án sử dụng. Mục tiêu là phát hiện các lỗi có thể nhận diện từ code, đồng thời xác định thành phần nào cần kiểm tra sâu hơn.

Ở bước này, cần chú ý đến những vấn đề như:

• Truy vấn cơ sở dữ liệu sử dụng dữ liệu đầu vào không an toàn.
• Chức năng xác thực hoặc phân quyền thiếu kiểm tra cần thiết.
• Thông tin bí mật xuất hiện trong mã nguồn hoặc lịch sử quản lý phiên bản.
• Thư viện có lỗ hổng đã được công bố hoặc phiên bản không còn phù hợp.
• Cơ chế xử lý lỗi có thể làm lộ thông tin nội bộ.
• Những đoạn code không rõ mục đích hoặc được AI thêm vào nhưng chưa được giải thích.

Nếu dự án có sử dụng thư viện bên ngoài, đừng chỉ kiểm tra mã nguồn do AI trực tiếp viết. Một ứng dụng có thể chứa lỗ hổng thông qua thư viện phụ thuộc, công cụ xây dựng hoặc thành phần tích hợp ngay cả khi phần code nghiệp vụ không có lỗi rõ ràng.

Bước 3: Kiểm thử chức năng và quyền truy cập

Hãy xây dựng các tình huống kiểm thử cho cả hành vi hợp lệ lẫn hành vi không được phép. Ví dụ, tài khoản khách hàng chỉ được xem đơn hàng của chính mình; nhân viên chỉ được thực hiện những thao tác phù hợp với vai trò; quản trị viên phải trải qua bước xác thực trước khi sử dụng chức năng quản lý.

Ngoài việc kiểm tra từng chức năng, cần thử những tình huống như gửi dữ liệu thiếu trường, nhập giá trị sai định dạng, sử dụng tài khoản hết phiên hoặc yêu cầu truy cập tài nguyên không thuộc quyền quản lý.

Đối với những ứng dụng có quy trình nghiệp vụ phức tạp, cần kiểm tra cả khả năng thực hiện các thao tác không đúng trình tự. Chẳng hạn, người dùng không nên có khả năng tự chuyển trạng thái đơn hàng sang trạng thái chỉ được phép thiết lập sau khi một bước xác minh đã hoàn tất.

Kiểm thử phải được thực hiện trên môi trường được phép sử dụng, tốt nhất với dữ liệu giả lập. Những thao tác có thể xóa dữ liệu, gửi giao dịch thật hoặc ảnh hưởng đến người dùng cần được kiểm soát riêng.

Bước 4: Kiểm tra cấu hình máy chủ và môi trường triển khai

Code an toàn vẫn có thể trở thành điểm yếu nếu được triển khai với cấu hình không phù hợp. Vì vậy, trước khi công khai website, hãy kiểm tra những thành phần nằm ngoài mã nguồn ứng dụng.

• HTTPS: Bảo đảm website sử dụng HTTPS hợp lệ để bảo vệ dữ liệu truyền giữa trình duyệt và máy chủ.
• Chế độ gỡ lỗi: Tắt chế độ debug dành cho môi trường phát triển và tránh hiển thị lỗi chi tiết cho khách truy cập.
• Thông tin bí mật: Đặt mật khẩu, khóa API và thông tin kết nối ở nơi lưu trữ phù hợp, không để lộ qua các tệp công khai.
• Quyền truy cập: Hạn chế quyền của tài khoản hệ thống, tài khoản cơ sở dữ liệu và các thư mục chứa dữ liệu nhạy cảm.
• Phiên đăng nhập: Cấu hình cookie bảo mật phù hợp, thời hạn phiên hợp lý và cơ chế thu hồi phiên khi cần.
• Sao lưu: Thiết lập quy trình sao lưu và kiểm tra khả năng khôi phục dữ liệu khi xảy ra sự cố.
• Nhật ký hệ thống: Ghi nhận những sự kiện cần thiết để điều tra sự cố nhưng không lưu mật khẩu, khóa bí mật hoặc dữ liệu nhạy cảm không cần thiết.

Đối với website PHP, cần kiểm tra cả cấu hình PHP, máy chủ web, quyền truy cập tệp và kết nối cơ sở dữ liệu. Không nên cho rằng chỉ cần sửa code theo đề xuất của AI là đã xử lý được mọi rủi ro phát sinh từ môi trường vận hành.

Bước 5: Kiểm tra lại sau khi sửa lỗi

Mỗi lần khắc phục một lỗ hổng đều có khả năng tạo ra lỗi mới hoặc ảnh hưởng đến chức năng khác. Vì vậy, sau khi sửa code, cần chạy lại những bài kiểm thử liên quan và xác minh vấn đề ban đầu đã được giải quyết thực sự.

Ví dụ, khi sửa lỗi phân quyền API, cần kiểm tra cả tài khoản có quyền và tài khoản không có quyền. Khi thay đổi cách truy vấn cơ sở dữ liệu, cần xác minh chức năng vẫn hoạt động đúng với dữ liệu hợp lệ và xử lý an toàn các giá trị không hợp lệ.

Nếu phát hiện lỗi nghiêm trọng, không nên chỉ dựa vào lời giải thích của AI để kết luận rằng vấn đề đã được khắc phục. Cần có bằng chứng từ việc kiểm tra mã nguồn, chạy thử hoặc sử dụng phương pháp kiểm thử phù hợp.

Bước 6: Theo dõi và cập nhật sau khi website hoạt động

Bảo mật không kết thúc khi website được triển khai. Các thư viện có thể xuất hiện lỗ hổng mới, cấu hình có thể thay đổi và chức năng mới có thể tạo ra những điểm yếu chưa từng tồn tại.

Do đó, cần duy trì việc cập nhật phần mềm, theo dõi cảnh báo bảo mật, kiểm tra nhật ký và rà soát những thay đổi quan trọng. Với website có dữ liệu quan trọng, nên có kế hoạch ứng phó sự cố, bao gồm cách cô lập thành phần bị ảnh hưởng, thu hồi thông tin xác thực bị lộ và khôi phục hệ thống khi cần thiết.

Quy trình này giúp chuyển Vibe Coding từ cách tạo ứng dụng nhanh chóng thành một phương pháp phát triển có kiểm soát, trong đó tốc độ không thay thế trách nhiệm kiểm tra và vận hành an toàn.

Khi nào nên nhờ lập trình viên kiểm tra code do AI tạo ra?

Không phải dự án Vibe Coding nào cũng cần thuê chuyên gia bảo mật ngay từ đầu. Với một công cụ thử nghiệm đơn giản, không lưu dữ liệu nhạy cảm và không được công khai, việc tự kiểm tra các chức năng cơ bản có thể là bước khởi đầu hợp lý.

Tuy nhiên, khi ứng dụng bắt đầu phục vụ khách hàng thật, lưu trữ dữ liệu quan trọng hoặc thực hiện những thao tác có ảnh hưởng lớn, việc nhờ người có chuyên môn rà soát sẽ giúp giảm những rủi ro mà người không có nền tảng kỹ thuật khó nhận ra.

Website có tài khoản và dữ liệu cá nhân

Nếu website cho phép người dùng đăng ký, đăng nhập, cập nhật hồ sơ hoặc trao đổi thông tin riêng tư, bạn cần bảo đảm dữ liệu được bảo vệ đúng cách. Những lỗi liên quan đến phân quyền, quản lý phiên và kiểm soát truy cập có thể ảnh hưởng đến nhiều tài khoản cùng lúc.

Trong trường hợp này, lập trình viên nên kiểm tra cơ chế xác thực, cách phân quyền theo từng tài nguyên, việc lưu trữ mật khẩu và những API có thể trả về dữ liệu cá nhân.

Website có thanh toán hoặc xử lý giao dịch

Ứng dụng xử lý đơn hàng, thanh toán, hoàn tiền hoặc số dư tài khoản có mức độ rủi ro cao hơn website thông tin thông thường. Một lỗi trong logic nghiệp vụ có thể dẫn đến giao dịch sai, thay đổi dữ liệu tài chính hoặc gây thiệt hại trực tiếp.

Những hệ thống này cần được kiểm tra kỹ về quyền thực hiện giao dịch, tính nhất quán của dữ liệu, xử lý yêu cầu lặp lại và việc xác minh kết quả từ cổng thanh toán. Không nên chỉ dựa vào trạng thái hiển thị trên trình duyệt để xác nhận giao dịch thành công.

Nếu sử dụng dịch vụ thanh toán bên ngoài, cần tuân thủ tài liệu tích hợp và yêu cầu bảo mật của nhà cung cấp. Các thao tác nhạy cảm phải được xác minh ở phía máy chủ theo cơ chế phù hợp.

Website có chức năng quản trị hoặc tích hợp nhiều hệ thống

Những dự án có nhiều vai trò người dùng, nhiều API, hệ thống quản trị nội bộ hoặc kết nối với dịch vụ bên ngoài thường khó đánh giá đầy đủ chỉ bằng cách đọc một vài đoạn code.

Lập trình viên có kinh nghiệm có thể rà soát luồng dữ liệu xuyên suốt ứng dụng, xác định ranh giới tin cậy giữa các thành phần và kiểm tra xem quyền truy cập có được áp dụng nhất quán hay không.

Nếu website lưu trữ dữ liệu nhạy cảm hoặc có nguy cơ gây thiệt hại đáng kể, bạn nên cân nhắc kiểm thử bảo mật chuyên sâu thay vì chỉ nhờ AI tự đánh giá code của chính nó.

Khi bạn không hiểu code đang làm gì

Đây là dấu hiệu quan trọng thường bị bỏ qua trong quá trình Vibe Coding. Nếu AI liên tục thêm thư viện, thay đổi cấu trúc cơ sở dữ liệu hoặc tạo ra những đoạn code mà bạn không thể giải thích mục đích, bạn sẽ khó đánh giá liệu những thay đổi đó có an toàn hay không.

Trong tình huống này, hãy yêu cầu AI giải thích kiến trúc và các thành phần liên quan, nhưng không nên xem lời giải thích đó là bằng chứng xác nhận code đúng. Với những phần liên quan đến xác thực, phân quyền, dữ liệu nhạy cảm hoặc cấu hình máy chủ, nên nhờ lập trình viên kiểm tra trước khi triển khai.

Mục tiêu không phải loại bỏ AI khỏi quá trình phát triển, mà là sử dụng AI đúng vai trò và có cơ chế kiểm soát phù hợp với mức độ rủi ro của sản phẩm.

Những sai lầm cần tránh khi bảo mật dự án Vibe Coding

Ngoài các lỗ hổng trong code, cách làm việc với AI cũng có thể khiến dự án phát sinh rủi ro. Một số sai lầm dưới đây cần được tránh ngay từ giai đoạn thử nghiệm.

Tin rằng AI đã kiểm tra thì code chắc chắn an toàn

AI có thể đưa ra nhận xét hợp lý nhưng vẫn bỏ sót lỗ hổng hoặc hiểu sai ngữ cảnh. Nếu công cụ không xem được toàn bộ dự án, không có quyền truy cập môi trường triển khai hoặc chưa thực hiện kiểm thử thực tế, kết luận bảo mật sẽ bị giới hạn bởi những thông tin mà nó có.

Cách phù hợp là xem kết quả AI như một nguồn hỗ trợ phân tích. Những vấn đề quan trọng cần được xác minh bằng mã nguồn, công cụ kiểm tra hoặc thử nghiệm có kiểm soát.

Chỉ kiểm tra giao diện mà bỏ qua backend

Một website có thể trông hoàn chỉnh nhưng phần xử lý phía máy chủ vẫn thiếu cơ chế bảo vệ. Việc đăng nhập thành công, biểu mẫu gửi được dữ liệu hay trang quản trị hiển thị đúng không chứng minh API và cơ sở dữ liệu được bảo vệ đầy đủ.

Vì vậy, hãy kiểm tra cả những yêu cầu được gửi trực tiếp đến backend, quyền truy cập từng tài nguyên và cách hệ thống xử lý dữ liệu không hợp lệ.

Sửa lỗi bằng cách thêm điều kiện tạm thời

Khi gặp một vấn đề bảo mật, AI đôi khi có thể đề xuất cách xử lý giúp chức năng hoạt động trở lại nhưng chưa loại bỏ nguyên nhân gốc. Chẳng hạn, việc chặn một trường hợp đầu vào cụ thể không thay thế được việc sửa cơ chế truy vấn SQL không an toàn.

Trước khi chấp nhận một bản sửa lỗi, hãy yêu cầu giải thích nguyên nhân, phạm vi ảnh hưởng và lý do phương án được chọn giải quyết được vấn đề. Sau đó, cần kiểm thử để xác nhận lỗ hổng không còn xuất hiện qua những đường xử lý liên quan.

Đưa code chưa kiểm thử lên website thật

Triển khai trực tiếp những thay đổi do AI tạo ra mà không có môi trường thử nghiệm có thể khiến lỗi bảo mật ảnh hưởng ngay đến khách hàng và dữ liệu thật.

Với website đang hoạt động, nên duy trì môi trường phát triển hoặc kiểm thử riêng, sử dụng hệ thống quản lý phiên bản và có phương án khôi phục khi bản cập nhật gây sự cố. Những thay đổi liên quan đến dữ liệu, quyền truy cập hoặc xác thực cần được kiểm tra kỹ trước khi triển khai.

Đưa dữ liệu thật và thông tin bí mật vào prompt

Trong quá trình nhờ AI sửa lỗi, người dùng có thể vô tình gửi mật khẩu, khóa API, dữ liệu khách hàng hoặc bản sao cơ sở dữ liệu. Điều này tạo ra một rủi ro khác, nằm ở cách thông tin được chia sẻ và xử lý bởi công cụ AI.

Trước khi gửi code hoặc dữ liệu cho một dịch vụ AI, hãy xem xét chính sách dữ liệu, quyền truy cập và cài đặt của dịch vụ đó. Nên loại bỏ thông tin xác thực, thay dữ liệu thật bằng dữ liệu giả lập và chỉ cung cấp phần code cần thiết để giải quyết vấn đề.

Nếu thông tin bí mật đã bị chia sẻ ngoài phạm vi được phép, cần đánh giá mức độ ảnh hưởng và thay thế thông tin xác thực khi cần thiết. Không nên mặc định rằng xóa nội dung khỏi cuộc trò chuyện sẽ tự động vô hiệu hóa mọi rủi ro liên quan.

Code do Vibe Coding tạo ra có phù hợp để xây dựng website chuyên nghiệp không?

Vibe Coding có thể hỗ trợ xây dựng website chuyên nghiệp nếu được sử dụng như một phần của quy trình phát triển phần mềm có kiểm soát. AI có thể giúp tạo giao diện, triển khai chức năng, viết các đoạn code lặp lại, xây dựng bộ kiểm thử và hỗ trợ phát hiện lỗi. Những lợi ích này giúp rút ngắn thời gian phát triển, đặc biệt khi yêu cầu được mô tả rõ ràng.

Tuy nhiên, khả năng tạo code nhanh không đồng nghĩa với khả năng thiết kế một hệ thống an toàn trong mọi tình huống. Những vấn đề như kiến trúc ứng dụng, phân quyền, bảo vệ dữ liệu, tính nhất quán của nghiệp vụ và cấu hình máy chủ vẫn cần được xem xét nghiêm túc.

Để quyết định có thể sử dụng code Vibe Coding cho website chuyên nghiệp hay không, cần phân biệt ba trường hợp.

Loại dự án	Cách tiếp cận phù hợp
Demo, nguyên mẫu hoặc công cụ cá nhân ít rủi ro	Có thể sử dụng AI để xây dựng nhanh, nhưng vẫn cần kiểm tra dữ liệu đầu vào, quyền truy cập và những thông tin không nên công khai.
Website doanh nghiệp, website giới thiệu dịch vụ hoặc hệ thống quản lý nội dung	Cần rà soát mã nguồn, xác thực, phân quyền quản trị, bảo vệ biểu mẫu, cấu hình máy chủ và quy trình sao lưu trước khi triển khai.
Website thương mại điện tử, hệ thống có dữ liệu nhạy cảm hoặc giao dịch quan trọng	Nên có lập trình viên chịu trách nhiệm kỹ thuật, quy trình kiểm thử bảo mật và đánh giá chuyên sâu tương ứng với mức độ rủi ro.

Với doanh nghiệp không có đội ngũ kỹ thuật nội bộ, việc thuê người kiểm tra code hoặc sử dụng dịch vụ phát triển website có quy trình bàn giao rõ ràng là lựa chọn đáng cân nhắc. Điều cần quan tâm không chỉ là ai viết code, mà còn là ai chịu trách nhiệm kiểm tra, bảo trì và xử lý khi phát sinh sự cố.

Đối với các dự án cần phát triển bằng PHP, Web Mới định hướng xây dựng website bằng phương pháp code tay theo yêu cầu. Khi lựa chọn đơn vị phát triển website, bạn nên trao đổi rõ về yêu cầu bảo mật, cách quản lý tài khoản quản trị, quy trình sao lưu, cập nhật và phạm vi hỗ trợ sau bàn giao. Đây là những yếu tố giúp website duy trì hoạt động ổn định, thay vì chỉ tập trung vào việc hoàn thành giao diện ban đầu.

Câu hỏi thường gặp về bảo mật code do Vibe Coding tạo ra

Code do AI tạo ra có dễ bị hack hơn code do lập trình viên viết không?

Không thể kết luận chỉ dựa trên việc code được tạo bởi AI hay con người. Mức độ an toàn phụ thuộc vào chất lượng triển khai, độ phức tạp của ứng dụng, yêu cầu bảo mật và quy trình kiểm thử. Code AI tạo ra có thể mắc những lỗi phổ biến nếu thiếu kiểm tra, nhưng code viết thủ công cũng có thể gặp các lỗ hổng tương tự.

Có nên sử dụng Vibe Coding để tạo website bán hàng không?

Có thể sử dụng AI để hỗ trợ phát triển website bán hàng, nhưng cần kiểm soát chặt chẽ các chức năng liên quan đến tài khoản, đơn hàng, dữ liệu khách hàng và thanh toán. Trước khi đưa website vào hoạt động, nên có quy trình kiểm tra bảo mật và xác minh các luồng nghiệp vụ quan trọng.

Chỉ cần yêu cầu AI viết code bảo mật là đủ chưa?

Chưa đủ. Yêu cầu rõ ràng giúp AI chú ý đến những rủi ro cần xử lý, nhưng không bảo đảm mọi lỗ hổng đều được phát hiện và khắc phục. Bạn vẫn cần rà soát mã nguồn, kiểm thử các tình huống thực tế và kiểm tra cấu hình triển khai.

Người không biết lập trình có thể kiểm tra bảo mật code Vibe Coding không?

Người không có nền tảng lập trình vẫn có thể thực hiện một số bước ban đầu như xác định chức năng nhạy cảm, kiểm tra quyền truy cập bằng các tài khoản thử nghiệm, rà soát thông tin bí mật và sử dụng công cụ quét phù hợp. Tuy nhiên, việc đánh giá đầy đủ những lỗ hổng kỹ thuật và logic nghiệp vụ phức tạp thường cần người có chuyên môn.

Làm thế nào để biết website Vibe Coding đã đủ an toàn để đưa lên mạng?

Không có một phép kiểm tra đơn lẻ nào chứng minh website hoàn toàn không có lỗ hổng. Bạn nên xác định các rủi ro chính, kiểm tra mã nguồn và thư viện, thử nghiệm quyền truy cập, rà soát cấu hình máy chủ, khắc phục những vấn đề được phát hiện và duy trì việc theo dõi sau triển khai. Với ứng dụng có rủi ro cao, cần đánh giá bảo mật chuyên sâu hơn.

Nếu AI phát hiện code có lỗ hổng thì có nên yêu cầu AI tự sửa không?

Có thể yêu cầu AI đề xuất hoặc thực hiện bản sửa lỗi, nhưng cần xem xét thay đổi trước khi chấp nhận. Sau khi sửa, hãy chạy lại các bài kiểm thử liên quan, kiểm tra những thành phần bị ảnh hưởng và xác minh rằng lỗ hổng đã được xử lý. Với lỗi nghiêm trọng hoặc khó hiểu, nên nhờ lập trình viên có kinh nghiệm đánh giá.

Kết luận

Code do Vibe Coding tạo ra có thể được sử dụng để xây dựng website an toàn, nhưng không nên mặc định rằng sản phẩm đã bảo mật chỉ vì AI tạo code nhanh và các chức năng hoạt động bình thường. Những lỗ hổng quan trọng thường liên quan đến cách xử lý dữ liệu, phân quyền, xác thực, quản lý thông tin bí mật và cấu hình môi trường triển khai.

Muốn giảm rủi ro, hãy đưa yêu cầu bảo mật vào ngay từ đầu, kiểm tra những thành phần nhạy cảm, kết hợp AI với các công cụ kiểm thử phù hợp và xác minh mọi bản sửa lỗi quan trọng. Khi website xử lý dữ liệu cá nhân, giao dịch hoặc nghiệp vụ phức tạp, việc có lập trình viên chịu trách nhiệm kỹ thuật và rà soát bảo mật là đặc biệt cần thiết.

Vibe Coding nên được xem là công cụ hỗ trợ phát triển phần mềm, không phải phương pháp thay thế hoàn toàn việc thiết kế, kiểm thử và bảo trì. Khi biết giới hạn của AI và xây dựng được quy trình kiểm soát phù hợp, bạn có thể tận dụng tốc độ phát triển mà vẫn chủ động bảo vệ website, dữ liệu và người dùng.

Bùi Tấn Lực

Đánh giá

Chia sẻ nội dung đánh giá của bạn về Code do Vibe Coding tạo ra có an toàn không?
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Bình luận, Hỏi đáp