Những lỗ hổng bảo mật thường gặp khi Vibe Coding

Vibe Coding đang thay đổi cách xây dựng phần mềm khi người dùng có thể mô tả yêu cầu bằng ngôn ngữ tự nhiên và nhờ AI tạo mã nguồn, thiết kế giao diện, kết nối cơ sở dữ liệu hoặc phát triển một ứng dụng gần như hoàn chỉnh. Phương pháp này giúp rút ngắn thời gian triển khai, đặc biệt với những người muốn tạo website, công cụ nội bộ hoặc sản phẩm thử nghiệm mà không cần tự viết toàn bộ mã nguồn.

Tuy nhiên, một ứng dụng chạy được không đồng nghĩa với một ứng dụng an toàn. Mã nguồn do AI tạo ra vẫn có thể chứa lỗi phân quyền, lỗ hổng SQL Injection, nguy cơ rò rỉ dữ liệu, cấu hình máy chủ không an toàn hoặc những cơ chế xác thực chưa đầy đủ. Đáng chú ý, nhiều lỗi không biểu hiện trong quá trình sử dụng thông thường mà chỉ bị phát hiện khi có người cố tình khai thác.

Vấn đề không nằm ở việc AI luôn tạo ra mã nguồn kém chất lượng. Rủi ro xuất hiện khi người phát triển tin tưởng quá mức vào kết quả do AI sinh ra, bỏ qua việc kiểm tra các giả định bảo mật hoặc đưa ứng dụng lên môi trường thật khi chưa đánh giá đầy đủ.

Bài viết này phân tích những lỗ hổng bảo mật thường gặp khi Vibe Coding, cách chúng hình thành, hậu quả có thể xảy ra và những nguyên tắc cần áp dụng để giảm thiểu rủi ro trong quá trình phát triển phần mềm.

Những lỗ hổng bảo mật thường gặp khi Vibe Coding
Những lỗ hổng bảo mật thường gặp khi Vibe Coding

Vì sao Vibe Coding có thể tạo ra lỗ hổng bảo mật?

Trong quy trình phát triển thông thường, lập trình viên cần hiểu yêu cầu, thiết kế hệ thống, viết mã, kiểm thử và xem xét các tình huống bất thường. Với Vibe Coding, một phần lớn công việc được chuyển sang AI thông qua những yêu cầu bằng ngôn ngữ tự nhiên. Điều này giúp tăng tốc độ phát triển nhưng cũng tạo ra những điểm yếu nếu người sử dụng không kiểm soát chặt chẽ kết quả.

AI thường ưu tiên hoàn thành chức năng được yêu cầu

Khi người dùng yêu cầu tạo chức năng đăng nhập, AI có thể tập trung vào việc xây dựng biểu mẫu, kiểm tra thông tin đăng nhập và chuyển người dùng đến trang quản trị. Tuy nhiên, yêu cầu đó chưa chắc đã đề cập đến giới hạn số lần đăng nhập sai, cơ chế chống chiếm đoạt phiên, bảo vệ cookie hoặc kiểm soát quyền truy cập vào dữ liệu.

Nếu yêu cầu không nêu rõ các điều kiện bảo mật, kết quả có thể đáp ứng tốt chức năng chính nhưng thiếu những lớp bảo vệ cần thiết. Điều này đặc biệt nguy hiểm khi người dùng đánh giá sản phẩm chủ yếu dựa trên giao diện và việc các chức năng có hoạt động hay không.

Chẳng hạn, một trang quản trị có thể ẩn nút dành cho quản trị viên đối với tài khoản thông thường. Nhưng nếu máy chủ không kiểm tra quyền khi nhận yêu cầu truy cập trực tiếp, người dùng vẫn có thể tìm cách gọi chức năng quản trị bằng một URL hoặc API tương ứng.

Mã nguồn đúng về cú pháp chưa chắc đúng về bảo mật

AI có thể tạo ra mã nguồn hợp lệ, sử dụng đúng thư viện và không phát sinh lỗi cú pháp nhưng vẫn mắc sai sót trong cách xử lý dữ liệu hoặc xác định quyền truy cập. Đây là khác biệt quan trọng giữa tính đúng đắn về mặt kỹ thuật và tính an toàn của hệ thống.

Ví dụ, một truy vấn cơ sở dữ liệu có thể trả về đúng thông tin cần tìm nhưng lại cho phép người dùng thay đổi tham số để truy cập dữ liệu của tài khoản khác. Tương tự, một chức năng tải tệp có thể hoạt động bình thường nhưng không giới hạn loại tệp, kích thước hoặc vị trí lưu trữ.

Kiểm thử chức năng thông thường thường tập trung vào những tình huống hợp lệ. Trong khi đó, kiểm thử bảo mật còn phải xem xét dữ liệu giả mạo, quyền hạn không phù hợp, yêu cầu bất thường và hành vi cố tình vượt qua các giới hạn đã thiết kế.

Thay đổi liên tục có thể làm mất đi các lớp bảo vệ

Trong quá trình Vibe Coding, người dùng thường yêu cầu AI sửa lỗi, bổ sung tính năng hoặc viết lại một phần mã nguồn. Mỗi thay đổi có thể ảnh hưởng đến những thành phần khác của ứng dụng, kể cả các cơ chế bảo mật trước đó.

Ví dụ, một chức năng cập nhật hồ sơ ban đầu chỉ cho phép thay đổi tên hiển thị. Sau đó, người dùng yêu cầu AI cho phép cập nhật nhiều trường thông tin trong cùng một biểu mẫu. Nếu phần xử lý mới nhận toàn bộ dữ liệu do trình duyệt gửi lên và cập nhật trực tiếp vào cơ sở dữ liệu, người dùng có thể tìm cách thay đổi cả trường phân quyền hoặc trạng thái tài khoản.

Đây là lý do cần kiểm tra lại những thành phần liên quan sau mỗi thay đổi đáng kể, thay vì chỉ xác nhận rằng chức năng mới đã hoạt động.

Những lỗ hổng bảo mật phổ biến khi Vibe Coding

Các lỗ hổng dưới đây có thể xuất hiện trong website, ứng dụng web, hệ thống quản trị và API được phát triển bằng AI. Mức độ rủi ro thực tế phụ thuộc vào kiến trúc, dữ liệu được xử lý, quyền hạn của ứng dụng và khả năng tiếp cận của kẻ tấn công.

1. SQL Injection khi xử lý truy vấn cơ sở dữ liệu

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

Lỗ hổng này có thể xuất hiện khi AI tạo chức năng tìm kiếm, đăng nhập, lọc danh sách hoặc tra cứu thông tin nhưng sử dụng cách nối chuỗi để xây dựng câu lệnh SQL.

Ví dụ không an toàn trong PHP:

<?php
$username = $_POST['username'];

$sql = "SELECT id, username FROM users WHERE username = '$username'";
$result = mysqli_query($conn, $sql);
?>

Vấn đề nằm ở việc dữ liệu do người dùng cung cấp được chèn trực tiếp vào câu truy vấn. Nếu không được xử lý đúng cách, dữ liệu này có thể làm thay đổi cách cơ sở dữ liệu diễn giải câu lệnh.

Giải pháp phù hợp là sử dụng truy vấn tham số hóa hoặc prepared statement, đồng thời giới hạn quyền của tài khoản cơ sở dữ liệu theo đúng nhu cầu của ứng dụng.

Ví dụ an toàn hơn với MySQLi:

<?php
$username = $_POST['username'] ?? '';

$stmt = $conn->prepare(
    'SELECT id, username FROM users WHERE username = ?'
);

$stmt->bind_param('s', $username);
$stmt->execute();

$result = $stmt->get_result();
?>

Trong ví dụ này, giá trị đầu vào được truyền vào vị trí tham số thay vì ghép trực tiếp vào cấu trúc SQL. Tuy nhiên, việc sử dụng prepared statement không thay thế cho các biện pháp bảo vệ khác như kiểm tra dữ liệu, phân quyền truy cập và quản lý lỗi.

Khi rà soát mã nguồn do AI tạo ra, cần đặc biệt chú ý đến các vị trí truy vấn dữ liệu theo từ khóa tìm kiếm, mã sản phẩm, ID người dùng, bộ lọc URL và những tham số được truyền từ biểu mẫu.

2. XSS khi hiển thị dữ liệu người dùng

Cross-Site Scripting (XSS) là 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 vào cách ứng dụng xử lý dữ liệu và bối cảnh thực thi, XSS có thể bị lợi dụng để thực hiện hành động dưới danh nghĩa người dùng, đọc thông tin mà mã độc có thể tiếp cận hoặc thay đổi nội dung trang.

Nguy cơ này thường xuất hiện ở chức năng bình luận, đánh giá sản phẩm, hồ sơ cá nhân, nội dung bài viết, thông báo hoặc trang quản trị hiển thị dữ liệu do người dùng gửi lên.

Ví dụ, nếu ứng dụng đưa nội dung do người dùng nhập trực tiếp vào HTML mà không mã hóa phù hợp, trình duyệt có thể diễn giải một số thành phần trong nội dung đó như mã HTML hoặc JavaScript thay vì văn bản thông thường.

Trong PHP, khi hiển thị một giá trị dưới dạng văn bản HTML, có thể sử dụng htmlspecialchars() với cấu hình phù hợp:

<?php
$comment = $_POST['comment'] ?? '';

echo htmlspecialchars(
    $comment,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);
?>

Biện pháp này giúp mã hóa những ký tự đặc biệt theo ngữ cảnh văn bản HTML. Tuy nhiên, không nên xem đây là giải pháp dùng được cho mọi vị trí. Dữ liệu được đưa vào thuộc tính HTML, URL, JavaScript hoặc CSS cần được xử lý theo đúng ngữ cảnh; nội dung HTML cho phép người dùng định dạng cũng cần có cơ chế lọc HTML an toàn.

Trong Vibe Coding, hãy kiểm tra những đoạn mã sử dụng các phương thức như innerHTML, chèn chuỗi vào mẫu HTML hoặc hiển thị nội dung lấy trực tiếp từ cơ sở dữ liệu. Dữ liệu lưu trong cơ sở dữ liệu không mặc nhiên an toàn, bởi nó có thể bắt nguồn từ người dùng hoặc một hệ thống bên ngoài.

3. Lỗi phân quyền khiến người dùng truy cập dữ liệu trái phép

Lỗi phân quyền là một trong những rủi ro nghiêm trọng nhất khi phát triển ứng dụng bằng AI. Chức năng có thể được xây dựng đầy đủ, nhưng hệ thống không kiểm tra chính xác người đang gửi yêu cầu có được phép thực hiện hành động đó hay không.

Ví dụ, một ứng dụng quản lý đơn hàng có đường dẫn lấy thông tin theo mã đơn hàng. Nếu máy chủ chỉ kiểm tra người dùng đã đăng nhập mà không xác minh đơn hàng có thuộc quyền truy cập của họ hay không, người dùng có thể thay đổi mã đơn để thử truy cập đơn hàng của người khác.

Trường hợp này có thể liên quan đến IDOR (Insecure Direct Object Reference) hoặc nhóm lỗi kiểm soát truy cập bị phá vỡ. Việc sử dụng ID khó đoán có thể làm giảm khả năng dò tìm trong một số tình huống, nhưng không thay thế cho kiểm tra quyền hạn ở phía máy chủ.

Một nguyên tắc quan trọng là mỗi yêu cầu truy cập tài nguyên cần được kiểm tra theo danh tính người dùng, quyền được cấp và tài nguyên cụ thể đang được yêu cầu. Không nên dựa vào việc ẩn nút, ẩn menu hoặc giới hạn giao diện để bảo vệ dữ liệu.

Ví dụ về cách lấy đơn hàng gắn với tài khoản đang đăng nhập trong PHP:

<?php
$userId = $_SESSION['user_id'] ?? null;
$orderId = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);

if (!$userId || !$orderId) {
    http_response_code(400);
    exit('Yêu cầu không hợp lệ');
}

$stmt = $conn->prepare(
    'SELECT id, status, total
     FROM orders
     WHERE id = ? AND user_id = ?'
);

$stmt->bind_param('ii', $orderId, $userId);
$stmt->execute();

$result = $stmt->get_result();
$order = $result->fetch_assoc();

if (!$order) {
    http_response_code(404);
    exit('Không tìm thấy đơn hàng');
}
?>

Đoạn mã trên minh họa việc ràng buộc đơn hàng với tài khoản đang đăng nhập ngay trong truy vấn. Trong ứng dụng thực tế, cần bảo đảm phiên đăng nhập được xác thực an toàn, dữ liệu người dùng được kiểm tra hợp lệ và các thao tác sửa, xóa hoặc hoàn tiền có quy tắc phân quyền riêng phù hợp.

Đặc biệt, khi yêu cầu AI xây dựng hệ thống nhiều vai trò như quản trị viên, nhân viên và khách hàng, cần mô tả rõ quyền của từng vai trò và kiểm tra quyền tại mọi điểm xử lý nghiệp vụ quan trọng.

4. Lộ khóa API, mật khẩu và thông tin bí mật trong mã nguồn

Ứng dụng được tạo bằng Vibe Coding có thể cần kết nối với dịch vụ AI, cổng thanh toán, dịch vụ gửi email, hệ thống lưu trữ hoặc API của bên thứ ba. Các dịch vụ này thường yêu cầu API key, access token hoặc thông tin xác thực.

Nếu AI đưa khóa bí mật trực tiếp vào mã nguồn phía trình duyệt, tệp JavaScript công khai, kho mã nguồn hoặc tệp cấu hình có thể truy cập từ Internet, người khác có thể lấy được thông tin đó. Hậu quả có thể bao gồm sử dụng dịch vụ trái phép, phát sinh chi phí, truy cập dữ liệu hoặc thực hiện hành động bằng quyền của ứng dụng.

Ví dụ về cách khai báo không nên sử dụng:

const API_KEY = "YOUR_SECRET_API_KEY";

Thay giá trị minh họa bằng một khóa thật trong mã nguồn công khai không làm cho cách triển khai này an toàn hơn. Đối với ứng dụng chạy trên trình duyệt, các biến được đóng gói vào JavaScript thường có thể bị người dùng kiểm tra. Vì vậy, khóa bí mật không được đặt ở đó.

Hướng xử lý phù hợp là lưu thông tin bí mật trong biến môi trường hoặc hệ thống quản lý bí mật ở phía máy chủ, sau đó để máy chủ thực hiện những yêu cầu cần sử dụng khóa. Tệp môi trường cũng phải được cấu hình để không thể tải xuống từ Internet và không bị đưa vào kho mã nguồn công khai.

Ví dụ, phía máy chủ PHP có thể đọc khóa từ biến môi trường:

<?php
$apiKey = getenv('EXTERNAL_API_KEY');

if (!$apiKey) {
    error_log('Thiếu cấu hình EXTERNAL_API_KEY');
    http_response_code(500);
    exit('Dịch vụ tạm thời không khả dụng');
}
?>

Không nên trả khóa bí mật hoặc thông tin cấu hình nhạy cảm về trình duyệt chỉ để tiện sử dụng. Nếu một khóa đã bị đưa lên kho mã nguồn công khai hoặc xuất hiện trong bản phát hành công khai, cần thu hồi hoặc thay khóa đó, đồng thời kiểm tra nhật ký để xác định liệu nó có bị sử dụng trái phép hay không.

5. Xác thực đăng nhập yếu và quản lý phiên không an toàn

Một chức năng đăng nhập chỉ kiểm tra đúng tên tài khoản và mật khẩu vẫn chưa đủ để bảo đảm an toàn. Ứng dụng còn cần xử lý việc lưu mật khẩu, giới hạn thử đăng nhập, quản lý phiên, đăng xuất và khôi phục tài khoản.

Các sai sót có thể gặp trong mã nguồn do AI tạo ra bao gồm lưu mật khẩu dưới dạng văn bản thuần, sử dụng thuật toán băm không phù hợp, không giới hạn các lần đăng nhập thất bại, không thay đổi mã phiên sau khi đăng nhập hoặc cấu hình cookie thiếu những thuộc tính bảo vệ cần thiết.

Để lưu mật khẩu trong PHP, nên sử dụng các hàm chuyên dụng như password_hash() và password_verify() thay vì tự thiết kế thuật toán mã hóa hoặc băm mật khẩu.

Ví dụ tạo giá trị băm mật khẩu:

<?php
$password = $_POST['password'] ?? '';

if ($password !== '') {
    $passwordHash = password_hash(
        $password,
        PASSWORD_DEFAULT
    );

    // Lưu $passwordHash vào cơ sở dữ liệu.
}
?>

Khi đăng nhập, mật khẩu người dùng nhập vào cần được kiểm tra với giá trị băm đã lưu bằng password_verify(). Không lưu mật khẩu gốc vào cơ sở dữ liệu, nhật ký hoặc thông báo lỗi.

Sau khi xác thực thành công, ứng dụng nên tái tạo mã phiên để giảm nguy cơ chiếm quyền phiên. Cookie phiên cần được thiết lập phù hợp với HTTPS và có các thuộc tính như Secure, HttpOnly và SameSite theo kiến trúc ứng dụng. Những thao tác nhạy cảm cũng có thể cần xác thực lại hoặc xác minh bổ sung.

Với hệ thống có nhiều tài khoản, cần cân nhắc giới hạn tốc độ đăng nhập, phát hiện hành vi bất thường, cơ chế đặt lại mật khẩu an toàn và xác thực đa yếu tố cho những tài khoản có quyền cao.

Không nên yêu cầu AI chỉ tạo một trang đăng nhập có giao diện đẹp. Hãy yêu cầu thiết kế toàn bộ vòng đời xác thực, bao gồm đăng nhập, đăng xuất, hết hạn phiên, đổi mật khẩu và khôi phục tài khoản, sau đó kiểm thử từng trường hợp.

Những lỗ hổng phát sinh khi xử lý dữ liệu và yêu cầu từ người dùng

Ngoài các lỗi SQL Injection, XSS và phân quyền, ứng dụng được phát triển bằng Vibe Coding còn có thể gặp những lỗ hổng liên quan đến cách máy chủ tiếp nhận yêu cầu, xử lý tệp tải lên và giao tiếp với các hệ thống khác. Đây là nhóm rủi ro đáng chú ý vì nhiều chức năng tưởng như đơn giản lại có thể trở thành điểm xâm nhập nếu thiếu các điều kiện kiểm soát cần thiết.

6. CSRF khiến người dùng vô tình thực hiện hành động ngoài ý muốn

Cross-Site Request Forgery (CSRF) là lỗ hổng cho phép kẻ tấn công tìm cách khiến trình duyệt của người dùng đã đăng nhập gửi một yêu cầu không mong muốn đến website. Rủi ro thường xuất hiện khi ứng dụng dựa vào cookie phiên để xác thực nhưng không có biện pháp phù hợp nhằm xác minh tính hợp lệ của yêu cầu.

Ví dụ, một website quản trị có chức năng đổi địa chỉ email hoặc cập nhật thông tin tài khoản. Nếu máy chủ chỉ kiểm tra phiên đăng nhập mà không xác minh nguồn gốc của yêu cầu theo cơ chế phù hợp, người dùng có thể bị dụ truy cập một trang bên ngoài khiến trình duyệt gửi yêu cầu đến website đó.

Nếu yêu cầu được chấp nhận và trình duyệt tự động gửi cookie xác thực, hành động có thể được thực hiện dưới danh nghĩa người dùng đang đăng nhập.

Để giảm thiểu CSRF, cần sử dụng token chống CSRF cho những thao tác thay đổi trạng thái, kiểm tra token ở phía máy chủ và cấu hình cookie SameSite phù hợp. Việc kiểm tra Origin hoặc Referer có thể bổ sung một lớp bảo vệ trong những trường hợp thích hợp, nhưng không nên mặc định xem đây là giải pháp thay thế hoàn toàn cho token chống CSRF.

Các thao tác thay đổi dữ liệu như tạo tài khoản, cập nhật thông tin, thay đổi quyền hoặc xóa bản ghi không nên được thực hiện bằng yêu cầu GET. Tuy nhiên, chỉ chuyển sang POST cũng không đủ để ngăn CSRF.

Khi dùng AI tạo biểu mẫu quản trị, hãy yêu cầu công cụ thiết kế cả cơ chế bảo vệ ở phía máy chủ. Việc thêm một trường token vào giao diện nhưng không xác minh token khi nhận yêu cầu không tạo ra sự bảo vệ thực sự.

7. SSRF cho phép máy chủ truy cập tài nguyên không được phép

Server-Side Request Forgery (SSRF) là lỗ hổng xảy ra khi ứng dụng cho phép người dùng tác động đến những yêu cầu mạng do máy chủ thực hiện mà không kiểm soát đầy đủ đích truy cập.

Trong Vibe Coding, rủi ro này có thể xuất hiện khi xây dựng chức năng nhập dữ liệu từ URL, lấy ảnh từ một đường dẫn bên ngoài, kiểm tra tình trạng website, tạo bản xem trước liên kết hoặc tải nội dung từ một dịch vụ khác.

Nếu máy chủ chấp nhận URL tùy ý, kẻ tấn công có thể tìm cách khiến ứng dụng truy cập vào các địa chỉ nội bộ, dịch vụ quản trị hoặc những tài nguyên vốn không được phép truy cập từ Internet. Trong một số môi trường triển khai, nguy cơ còn liên quan đến các dịch vụ siêu dữ liệu của nền tảng đám mây.

Để phòng tránh SSRF, không nên cho phép máy chủ tự do gửi yêu cầu đến mọi URL do người dùng cung cấp. Những biện pháp quan trọng bao gồm:

  • Chỉ cho phép các giao thức cần thiết, thường là HTTPS và trong một số trường hợp có thể là HTTP.
  • Sử dụng danh sách cho phép đối với tên miền hoặc máy chủ đích nếu nghiệp vụ cho phép.
  • Kiểm tra địa chỉ IP sau khi phân giải DNS, bao gồm cả địa chỉ IPv4 và IPv6, để ngăn truy cập đến các vùng mạng không được phép.
  • Kiểm soát chuyển hướng để tránh trường hợp URL ban đầu hợp lệ nhưng chuyển sang đích không an toàn.
  • Giới hạn thời gian kết nối, kích thước phản hồi và số lượng yêu cầu.
  • Sử dụng tường lửa hoặc chính sách mạng để ngăn ứng dụng truy cập những dịch vụ nội bộ không cần thiết.

Không nên chỉ kiểm tra URL bằng một biểu thức chính quy đơn giản rồi xem đó là biện pháp bảo vệ đầy đủ. Việc xử lý URL, DNS, địa chỉ IP và chuyển hướng có nhiều trường hợp đặc biệt cần được xem xét đồng bộ.

8. Tải tệp lên nhưng không kiểm soát loại tệp và vị trí lưu trữ

Chức năng tải ảnh đại diện, tài liệu, hóa đơn hoặc tệp đính kèm thường được AI tạo khá nhanh. Tuy nhiên, nếu ứng dụng chỉ kiểm tra phần mở rộng của tên tệp hoặc tin tưởng loại nội dung do trình duyệt gửi lên, kẻ tấn công có thể tìm cách tải lên dữ liệu không phù hợp với mục đích sử dụng.

Ví dụ, một website chỉ cho phép tải ảnh nhưng lại dựa hoàn toàn vào tên tệp để xác định tệp đó có phải ảnh hay không. Người dùng có thể sửa tên tệp hoặc giả mạo thông tin loại nội dung gửi kèm yêu cầu. Nếu tệp được lưu ở vị trí có thể thực thi mã hoặc được máy chủ xử lý không an toàn, hậu quả có thể nghiêm trọng hơn việc lưu một tệp không hợp lệ.

Trong một số trường hợp, tệp được tải lên còn có thể chứa nội dung độc hại, dữ liệu quá lớn hoặc cấu trúc được thiết kế để khai thác lỗi của phần mềm xử lý tệp.

Để bảo vệ chức năng tải tệp, cần áp dụng nhiều lớp kiểm tra:

  • Chỉ cho phép những định dạng thực sự cần thiết đối với nghiệp vụ.
  • Kiểm tra nội dung tệp bằng phương pháp phù hợp thay vì chỉ dựa vào phần mở rộng hoặc Content-Type do người dùng cung cấp.
  • Giới hạn kích thước, số lượng tệp và tổng dung lượng tải lên.
  • Đổi tên tệp bằng giá trị do hệ thống tạo ra, tránh sử dụng trực tiếp tên tệp do người dùng cung cấp làm đường dẫn lưu trữ.
  • Lưu tệp ngoài thư mục có khả năng thực thi mã hoặc ngoài vùng công khai nếu nghiệp vụ cho phép.
  • Kiểm tra quyền khi tải lên, xem, tải xuống và xóa tệp.
  • Cân nhắc quét mã độc hoặc xử lý tệp trong môi trường cách ly đối với những hệ thống có mức độ rủi ro cao.

Đối với ảnh, việc giải mã rồi tạo lại ảnh bằng thư viện xử lý hình ảnh đáng tin cậy có thể giúp giảm một số nguy cơ, nhưng vẫn phải giới hạn kích thước và kiểm tra tài nguyên sử dụng. Với tài liệu PDF, tệp nén hoặc định dạng phức tạp, cần có cơ chế bảo vệ phù hợp với loại nội dung đó.

Khi yêu cầu AI tạo chức năng tải tệp, hãy xác định rõ loại tệp được phép, vị trí lưu trữ, cách đặt tên, quyền truy cập và giới hạn dung lượng. Đây là những yêu cầu bảo mật cần được thiết kế ngay từ đầu, không nên để đến khi ứng dụng phát sinh sự cố mới bổ sung.

9. Path Traversal cho phép truy cập tệp ngoài phạm vi dự kiến

Path Traversal là lỗ hổng xảy ra khi dữ liệu đầu vào được sử dụng để xây dựng đường dẫn tệp mà không được kiểm soát đúng cách. Kẻ tấn công có thể tìm cách khiến ứng dụng truy cập tệp nằm ngoài thư mục dự kiến, tùy thuộc vào cách xử lý đường dẫn và quyền của tiến trình máy chủ.

Rủi ro thường xuất hiện ở chức năng tải tài liệu, xem tệp theo tên, tải bản sao lưu hoặc đọc nội dung theo tham số URL.

Ví dụ, nếu AI tạo một chức năng nhận tên tệp từ người dùng rồi nối trực tiếp vào đường dẫn hệ thống, ứng dụng có thể không giới hạn được phạm vi tệp mà người dùng yêu cầu.

Để hạn chế nguy cơ này, nên sử dụng mã định danh nội bộ để ánh xạ đến tệp thay vì nhận đường dẫn tùy ý. Nếu bắt buộc phải xử lý đường dẫn, cần chuẩn hóa đường dẫn, xác minh đường dẫn cuối cùng vẫn nằm trong thư mục cho phép và không dựa vào việc loại bỏ một vài chuỗi ký tự đơn giản.

Quyền đọc tệp của tiến trình ứng dụng cũng cần được giới hạn ở mức tối thiểu. Ngay cả khi một lỗi kiểm tra đường dẫn xảy ra, việc không cấp quyền truy cập vào tệp cấu hình, thông tin xác thực hoặc dữ liệu nhạy cảm sẽ giúp giảm mức độ thiệt hại.

Lỗ hổng cấu hình và quản lý môi trường triển khai

Một ứng dụng có thể được viết tương đối tốt nhưng vẫn không an toàn do cách cấu hình máy chủ, cơ sở dữ liệu, dịch vụ lưu trữ hoặc môi trường triển khai. Đây là nhóm lỗi dễ bị bỏ qua khi Vibe Coding vì người dùng thường tập trung vào mã nguồn và giao diện nhiều hơn hạ tầng vận hành.

10. Cấu hình máy chủ sai làm lộ dữ liệu và tệp nội bộ

Các cấu hình mặc định thuận tiện cho quá trình phát triển không phải lúc nào cũng phù hợp khi đưa ứng dụng lên môi trường thật. Nếu giữ nguyên những thiết lập thiếu an toàn, website có thể vô tình công khai các tệp không dành cho người dùng bên ngoài.

Những trường hợp thường gặp bao gồm bật liệt kê thư mục, để lộ thông báo lỗi chi tiết, công khai tệp sao lưu, cho phép truy cập tệp cấu hình hoặc để dịch vụ quản trị mở ra Internet mà không có biện pháp bảo vệ phù hợp.

Ví dụ, một dự án PHP có thể chứa tệp sao lưu cơ sở dữ liệu hoặc tệp cấu hình trong thư mục mà máy chủ web có thể phục vụ trực tiếp. Nếu cấu hình không chặn truy cập, người khác có thể tải xuống tệp và tìm thấy dữ liệu nhạy cảm.

Để giảm thiểu rủi ro, cần rà soát cấu trúc thư mục và cấu hình máy chủ trước khi phát hành. Những tệp không cần thiết cho hoạt động công khai nên được đặt ngoài thư mục gốc có thể truy cập từ web. Tính năng liệt kê thư mục cần được tắt khi không có nhu cầu rõ ràng, đồng thời phải bảo vệ các đường dẫn quản trị và tệp cấu hình.

Đối với máy chủ Apache, có thể cân nhắc cấu hình tắt liệt kê thư mục trong phạm vi phù hợp:

Options -Indexes

Đây chỉ là một biện pháp cấu hình đơn lẻ, không thay thế cho việc kiểm tra quyền truy cập và thiết lập máy chủ tổng thể. Hiệu lực thực tế còn phụ thuộc vào cấu hình Apache, phạm vi áp dụng và các quy tắc ghi đè hiện có.

Không nên sao chép một tệp cấu hình do AI đề xuất rồi áp dụng trực tiếp lên máy chủ đang vận hành mà chưa hiểu tác động. Cần kiểm tra cấu hình hiện tại, thử nghiệm trong môi trường phù hợp và có phương án khôi phục khi thay đổi gây lỗi.

11. Phân quyền cơ sở dữ liệu quá rộng

Ứng dụng thường cần tài khoản cơ sở dữ liệu để đọc, thêm, sửa hoặc xóa dữ liệu. Nếu tài khoản này được cấp mọi quyền trên toàn bộ máy chủ cơ sở dữ liệu trong khi ứng dụng chỉ cần thao tác trên một số bảng, sự cố bảo mật có thể gây hậu quả lớn hơn mức cần thiết.

Chẳng hạn, khi một điểm yếu SQL Injection bị khai thác, mức độ ảnh hưởng sẽ phụ thuộc một phần vào quyền mà tài khoản kết nối cơ sở dữ liệu đang sở hữu. Tài khoản chỉ có quyền thực hiện những thao tác cần thiết sẽ giúp giới hạn phạm vi thiệt hại so với tài khoản có quyền quản trị toàn hệ thống.

Vì vậy, nên áp dụng nguyên tắc đặc quyền tối thiểu. Tài khoản dùng cho ứng dụng vận hành chỉ nên có các quyền thực sự cần thiết trên cơ sở dữ liệu hoặc bảng liên quan. Những thao tác quản trị, tạo cấu trúc hoặc cập nhật hệ thống nên được tách khỏi tài khoản vận hành thông thường khi phù hợp.

Cũng cần tránh sử dụng chung một tài khoản có toàn quyền cho môi trường phát triển, thử nghiệm và sản xuất. Việc phân tách môi trường giúp giảm nguy cơ một lỗi trong quá trình thử nghiệm ảnh hưởng đến dữ liệu thực tế.

12. Bỏ qua xác minh TLS khi kết nối dịch vụ

Khi ứng dụng giao tiếp với API hoặc dịch vụ bên ngoài qua HTTPS, việc xác minh chứng chỉ TLS giúp máy khách kiểm tra danh tính của máy chủ và bảo vệ kết nối trước những hình thức giả mạo hoặc can thiệp phù hợp với mô hình đe dọa.

Nếu AI đề xuất tắt xác minh chứng chỉ chỉ để khắc phục lỗi kết nối trong quá trình phát triển, giải pháp tạm thời đó có thể vô tình được đưa lên môi trường thật. Khi xác minh chứng chỉ bị vô hiệu hóa, ứng dụng có thể chấp nhận kết nối đến máy chủ không đáng tin cậy.

Không nên khắc phục lỗi chứng chỉ bằng cách tắt xác minh TLS trên môi trường sản xuất. Cần kiểm tra cấu hình chứng chỉ, chuỗi chứng chỉ, tên miền, thời hạn và kho chứng chỉ tin cậy của hệ thống.

Nếu ứng dụng cần kết nối đến máy chủ nội bộ sử dụng chứng chỉ riêng, hãy cấu hình cơ chế tin cậy phù hợp thay vì vô hiệu hóa hoàn toàn việc xác minh. Mọi thay đổi liên quan đến TLS cần được kiểm thử trong môi trường triển khai thực tế.

Rủi ro khi kết nối AI với API và dịch vụ bên thứ ba

Vibe Coding thường được sử dụng để kết nối nhanh nhiều dịch vụ: mô hình AI, cổng thanh toán, hệ thống gửi email, kho lưu trữ và nền tảng phân tích dữ liệu. Mỗi kết nối mới tạo thêm một ranh giới tin cậy mà ứng dụng phải kiểm soát.

13. Tin tưởng phản hồi từ API bên ngoài mà không xác minh

Dữ liệu trả về từ một API không nên mặc nhiên được xem là hợp lệ chỉ vì nó đến từ một dịch vụ có vẻ đáng tin cậy. Phản hồi có thể bị thiếu trường, sai kiểu dữ liệu, vượt giới hạn kích thước hoặc chứa nội dung không phù hợp với cách ứng dụng sử dụng.

Ví dụ, một ứng dụng bán hàng nhận giá sản phẩm từ một dịch vụ bên ngoài. Nếu hệ thống lấy trực tiếp giá trị trả về rồi sử dụng để tính tiền mà không kiểm tra kiểu dữ liệu, phạm vi hợp lệ và quy tắc nghiệp vụ, dữ liệu sai có thể dẫn đến tính toán không chính xác hoặc làm gián đoạn chức năng.

Tương tự, nếu ứng dụng nhận một URL ảnh từ API rồi đưa thẳng vào giao diện hoặc chuyển cho máy chủ tải xuống, rủi ro có thể liên quan đến XSS, SSRF hoặc các vấn đề xử lý nội dung khác.

Để phòng tránh, cần kiểm tra cấu trúc phản hồi, kiểu dữ liệu, giá trị bắt buộc và giới hạn độ dài. Những dữ liệu liên quan đến tiền, quyền truy cập hoặc trạng thái giao dịch cần được xác minh theo quy tắc nghiệp vụ và nguồn dữ liệu có thẩm quyền.

Ứng dụng cũng cần xử lý an toàn các trường hợp API trả về lỗi, hết thời gian chờ hoặc phản hồi không đúng định dạng. Không nên mặc định rằng mọi yêu cầu đều thành công hoặc tự động chuyển dữ liệu chưa xác minh vào những thao tác nhạy cảm.

14. Webhook không được xác minh tính xác thực

Webhook cho phép một dịch vụ gửi thông báo đến ứng dụng khi có sự kiện xảy ra. Chẳng hạn, cổng thanh toán có thể gửi thông báo về trạng thái giao dịch, hoặc nền tảng bán hàng gửi sự kiện khi đơn hàng được cập nhật.

Nếu ứng dụng chỉ nhận một yêu cầu HTTP và tin ngay vào nội dung được gửi đến, người khác có thể tìm cách giả mạo sự kiện để kích hoạt những hành động trái phép. Trong hệ thống thương mại điện tử, việc xử lý sai thông báo thanh toán có thể khiến đơn hàng được đánh dấu đã thanh toán dù giao dịch chưa hoàn tất.

Biện pháp bảo vệ phụ thuộc vào nhà cung cấp webhook. Thông thường, ứng dụng cần xác minh chữ ký theo đúng tài liệu của nhà cung cấp, bảo vệ bí mật dùng để xác minh và kiểm tra những thông tin liên quan đến sự kiện.

Đối với giao dịch thanh toán, không nên chỉ dựa vào một trường trạng thái do yêu cầu gửi đến cung cấp. Cần xác minh tính xác thực của thông báo, đối chiếu mã giao dịch, số tiền, đơn vị tiền tệ và đơn hàng tương ứng. Khi cần, có thể truy vấn lại trạng thái giao dịch qua API chính thức của nhà cung cấp.

Hệ thống cũng nên xử lý sự kiện lặp lại một cách an toàn. Một webhook có thể được gửi lại do lỗi mạng hoặc cơ chế thử lại của nhà cung cấp. Nếu mỗi lần nhận sự kiện đều làm thay đổi số dư hoặc ghi nhận thanh toán mới, ứng dụng có thể xử lý một giao dịch nhiều lần.

15. Lạm dụng API do thiếu giới hạn tài nguyên

Một ứng dụng do AI tạo ra có thể hoạt động tốt khi chỉ có vài người sử dụng nhưng gặp vấn đề khi lượng yêu cầu tăng cao. Nếu không có giới hạn phù hợp, người dùng hoặc hệ thống tự động có thể gửi quá nhiều yêu cầu, làm cạn tài nguyên hoặc khiến dịch vụ bên ngoài phát sinh chi phí lớn.

Rủi ro này đặc biệt đáng chú ý đối với những chức năng gọi mô hình AI, xử lý tài liệu, chuyển đổi hình ảnh, tạo báo cáo hoặc thực hiện truy vấn tốn nhiều tài nguyên.

Các biện pháp cần cân nhắc bao gồm:

  • Giới hạn tần suất yêu cầu theo tài khoản, địa chỉ IP hoặc các tiêu chí phù hợp với hệ thống.
  • Đặt giới hạn kích thước dữ liệu đầu vào và kích thước phản hồi.
  • Giới hạn thời gian xử lý, số tác vụ đồng thời và lượng tài nguyên sử dụng.
  • Áp dụng hạn mức cho những chức năng sử dụng dịch vụ tính phí.
  • Đưa các tác vụ dài vào hàng đợi khi cần thiết, thay vì giữ kết nối trong thời gian quá lâu.
  • Theo dõi mức sử dụng và cảnh báo khi có dấu hiệu bất thường.

Giới hạn không nên được áp dụng một cách máy móc cho mọi người dùng. Những tài khoản có quyền khác nhau có thể cần hạn mức khác nhau, nhưng mọi trường hợp ngoại lệ phải được kiểm soát rõ ràng.

Rủi ro riêng khi sử dụng AI để viết và sửa mã nguồn

Ngoài các lỗ hổng nằm trong ứng dụng, quy trình làm việc với AI cũng có thể tạo ra rủi ro nếu người phát triển không kiểm soát thay đổi hoặc không đánh giá độ tin cậy của mã nguồn và dữ liệu đầu vào.

16. Cài thư viện không đáng tin cậy hoặc có lỗ hổng đã biết

AI có thể đề xuất một thư viện để xử lý xác thực, tải tệp, mã hóa dữ liệu hoặc kết nối API. Tuy nhiên, tên thư viện có vẻ hợp lý không đồng nghĩa với việc gói đó chính thức, còn được duy trì hoặc an toàn để sử dụng.

Nếu cài đặt nhầm gói giả mạo, sử dụng phiên bản có lỗ hổng hoặc kéo theo những phụ thuộc không an toàn, ứng dụng có thể gặp rủi ro ngay cả khi mã nguồn do người phát triển viết không có lỗi rõ ràng.

Trước khi cài thư viện, nên kiểm tra tên gói, nguồn phát hành, tài liệu chính thức, lịch sử bảo trì và các cảnh báo bảo mật liên quan. Không nên sao chép lệnh cài đặt do AI đưa ra mà chưa xác minh gói đó thực sự tồn tại và phù hợp.

Đối với dự án sử dụng nhiều thư viện, cần duy trì tệp khóa phụ thuộc khi hệ sinh thái hỗ trợ, kiểm tra các cảnh báo bảo mật và cập nhật theo quy trình có kiểm thử. Việc cập nhật tự động mà không xem xét khả năng tương thích cũng có thể làm phát sinh lỗi mới.

17. Chấp nhận mã do AI tạo mà không kiểm tra các thay đổi liên quan

Một đoạn mã có thể giải quyết lỗi trước mắt nhưng đồng thời làm suy yếu một cơ chế bảo vệ khác. Ví dụ, AI có thể đề xuất bỏ qua kiểm tra quyền để khắc phục lỗi người dùng không xem được dữ liệu, hoặc tắt xác minh chứng chỉ để sửa lỗi kết nối API.

Những thay đổi này có thể khiến chức năng hoạt động trở lại nhưng tạo ra lỗ hổng nghiêm trọng hơn. Nếu người phát triển chỉ kiểm tra kết quả hiển thị mà không xem xét nguyên nhân và tác động của thay đổi, rủi ro có thể bị bỏ qua.

Mỗi thay đổi quan trọng cần được xem xét theo ít nhất ba khía cạnh: vấn đề ban đầu đã được giải quyết hay chưa, những chức năng liên quan có bị ảnh hưởng không và các điều kiện bảo mật có còn được duy trì hay không.

Nên sử dụng hệ thống quản lý phiên bản để theo dõi thay đổi, xem phần mã được thêm hoặc sửa và có khả năng quay lại phiên bản ổn định khi cần. Những thay đổi liên quan đến xác thực, phân quyền, truy vấn cơ sở dữ liệu và xử lý tệp cần được xem xét cẩn thận hơn.

18. Đưa dữ liệu nhạy cảm vào công cụ AI không đúng cách

Trong quá trình yêu cầu AI phân tích hoặc sửa mã nguồn, người dùng có thể vô tình gửi kèm khóa API, mật khẩu, dữ liệu khách hàng, nội dung hợp đồng hoặc bản sao cơ sở dữ liệu. Điều này tạo ra rủi ro riêng về bảo mật thông tin, tách biệt với lỗ hổng kỹ thuật trong ứng dụng.

Mức độ rủi ro phụ thuộc vào công cụ AI, loại tài khoản, thiết lập dữ liệu, chính sách lưu trữ và quyền truy cập được áp dụng. Không nên mặc định rằng mọi dữ liệu được gửi vào công cụ đều tự động được bảo vệ theo cùng một cách.

Trước khi cung cấp mã nguồn hoặc dữ liệu cho AI, hãy loại bỏ thông tin bí mật không cần thiết, thay khóa thật bằng giá trị giả và sử dụng dữ liệu thử nghiệm đã được làm sạch. Nếu cần phân tích sự cố, chỉ nên cung cấp phần thông tin cần thiết để xác định nguyên nhân.

Nếu một thông tin xác thực đã bị chia sẻ ngoài phạm vi được phép, cần đánh giá khả năng bị lộ và thay hoặc thu hồi thông tin đó khi cần thiết. Xóa nội dung khỏi cuộc trò chuyện không nên được xem là biện pháp duy nhất để xử lý một khóa bí mật đã bị lộ.

Cách kiểm tra bảo mật cho ứng dụng được phát triển bằng Vibe Coding

Nhận diện được các loại lỗ hổng mới chỉ là bước đầu. Để giảm thiểu rủi ro, người phát triển cần có quy trình kiểm tra mã nguồn, xác minh hành vi thực tế và đánh giá mức độ an toàn trước khi đưa ứng dụng vào sử dụng.

Không nhất thiết phải có một đội ngũ bảo mật chuyên nghiệp mới có thể thực hiện những bước kiểm tra cơ bản. Ngay cả khi sử dụng AI để phát triển phần mềm, bạn vẫn có thể áp dụng các biện pháp có hệ thống nhằm phát hiện sớm nhiều lỗi phổ biến.

1. Yêu cầu AI tự rà soát mã nguồn theo từng nhóm rủi ro

AI có thể hỗ trợ tìm những đoạn mã đáng ngờ, giải thích cơ chế hoạt động của chúng và đề xuất hướng khắc phục. Tuy nhiên, kết quả rà soát của AI không phải bằng chứng chứng minh ứng dụng an toàn. AI có thể bỏ sót lỗ hổng, nhận định sai về mức độ nguy hiểm hoặc đề xuất biện pháp sửa lỗi chưa đầy đủ.

Thay vì chỉ hỏi chung chung rằng mã nguồn có an toàn hay không, hãy yêu cầu AI kiểm tra từng nhóm vấn đề cụ thể, chẳng hạn:

  • Kiểm tra các truy vấn cơ sở dữ liệu để tìm nguy cơ SQL Injection.
  • Rà soát những vị trí hiển thị dữ liệu người dùng để phát hiện nguy cơ XSS.
  • Kiểm tra quyền truy cập ở từng API và chức năng xử lý dữ liệu.
  • Tìm thông tin xác thực, khóa API hoặc dữ liệu nhạy cảm bị đưa vào mã nguồn.
  • Rà soát cơ chế đăng nhập, quản lý phiên và khôi phục tài khoản.
  • Kiểm tra chức năng tải tệp, đọc tệp, xử lý URL và gọi dịch vụ bên ngoài.
  • Phát hiện cấu hình mặc định không an toàn và thư viện có nguy cơ lỗi thời.

Một prompt hữu ích cần yêu cầu AI chỉ rõ vị trí mã nguồn liên quan, giải thích điều kiện khiến lỗ hổng có thể xảy ra, đánh giá tác động và đề xuất cách kiểm chứng. Nếu không tìm thấy lỗi, AI nên nêu rõ phạm vi đã kiểm tra và những phần chưa đủ thông tin để kết luận.

Không nên yêu cầu AI sửa toàn bộ dự án cùng lúc mà không có kế hoạch. Hãy ưu tiên các lỗi có mức độ ảnh hưởng cao, sửa từng nhóm, xem lại phần mã thay đổi và chạy lại các bài kiểm thử liên quan.

2. Sử dụng công cụ phân tích mã nguồn tự động

Công cụ kiểm tra tự động giúp phát hiện một số vấn đề mà quá trình đọc mã thủ công có thể bỏ qua. Trong phát triển phần mềm, có nhiều nhóm công cụ khác nhau, mỗi nhóm đảm nhận một phần của quy trình kiểm tra bảo mật.

Nhóm công cụ Mục đích Thời điểm sử dụng
Static Application Security Testing (SAST) Phân tích mã nguồn để tìm các mẫu lỗi bảo mật tiềm ẩn. Trong quá trình phát triển và trước khi phát hành.
Software Composition Analysis (SCA) Kiểm tra thư viện và các thành phần phụ thuộc để phát hiện phiên bản có lỗ hổng đã biết. Khi cài đặt, cập nhật hoặc xây dựng phiên bản mới.
Dynamic Application Security Testing (DAST) Kiểm tra ứng dụng đang chạy bằng cách gửi yêu cầu và quan sát phản hồi. Trong môi trường thử nghiệm được cho phép.
Secret scanning Tìm khóa API, token và thông tin xác thực có thể bị lộ trong mã nguồn hoặc lịch sử phiên bản. Khi commit mã và trong quy trình tích hợp liên tục.
Kiểm tra cấu hình Phát hiện những thiết lập triển khai có nguy cơ không an toàn. Trước khi đưa ứng dụng lên môi trường thật và khi thay đổi hạ tầng.

Các nhóm công cụ này bổ sung cho nhau chứ không thay thế lẫn nhau. Chẳng hạn, SAST có thể phát hiện một đoạn mã đáng ngờ nhưng không nhất thiết xác định được toàn bộ tác động của lỗi phân quyền trong môi trường thực tế. DAST có thể phát hiện hành vi bất thường khi ứng dụng đang chạy nhưng không bảo đảm đã kiểm tra hết mọi nhánh xử lý.

Vì vậy, cần kết hợp công cụ tự động với việc xem xét mã nguồn, kiểm thử chức năng và đánh giá kiến trúc. Những cảnh báo cần được xác minh để phân biệt lỗi thực sự, cảnh báo sai và các vấn đề chưa đủ dữ liệu để kết luận.

3. Kiểm thử những tình huống vượt ngoài luồng sử dụng bình thường

Một ứng dụng có thể vượt qua các bài kiểm thử thông thường nhưng vẫn tồn tại lỗ hổng khi người dùng gửi dữ liệu không hợp lệ hoặc cố truy cập tài nguyên ngoài quyền hạn. Vì vậy, kiểm thử bảo mật cần xem xét cả trường hợp hợp lệ và trường hợp bất thường.

Đối với chức năng đăng nhập, cần kiểm tra việc xử lý mật khẩu sai, tài khoản không tồn tại, đăng nhập lặp lại nhiều lần và phiên đăng nhập hết hạn. Với chức năng quản lý dữ liệu, cần xác minh người dùng không thể xem hoặc sửa tài nguyên thuộc tài khoản khác chỉ bằng cách thay đổi mã định danh.

Với biểu mẫu và API, cần thử dữ liệu thiếu trường, sai kiểu dữ liệu, chuỗi quá dài và các giá trị nằm ngoài giới hạn nghiệp vụ. Đối với chức năng tải tệp, cần kiểm tra định dạng không được phép, tệp quá lớn và những trường hợp không có quyền truy cập.

Những kiểm thử này nên được thực hiện trong môi trường do bạn sở hữu hoặc được phép đánh giá. Không nên thử nghiệm khai thác trên hệ thống của bên thứ ba khi chưa có sự cho phép.

4. Kiểm tra cả luồng nghiệp vụ thay vì chỉ từng chức năng riêng lẻ

Một số lỗ hổng chỉ xuất hiện khi nhiều chức năng được kết hợp. Chẳng hạn, chức năng cập nhật hồ sơ có thể kiểm tra quyền đúng cách, nhưng một API nhập dữ liệu hàng loạt lại cho phép thay đổi những trường nhạy cảm. Nếu chỉ kiểm tra riêng từng màn hình, người phát triển có thể bỏ qua đường đi khác dẫn đến cùng một dữ liệu.

Vì vậy, cần lập danh sách những tài nguyên quan trọng như tài khoản, đơn hàng, hồ sơ khách hàng, tài liệu nội bộ và cấu hình hệ thống. Với mỗi tài nguyên, hãy xác định ai có quyền xem, tạo, sửa, xóa hoặc thực hiện những thao tác đặc biệt.

Sau đó, kiểm tra tất cả các điểm truy cập liên quan, bao gồm giao diện web, API, tác vụ nền và những chức năng được gọi từ dịch vụ bên ngoài. Quyền truy cập phải được thực thi nhất quán ở phía máy chủ, không phụ thuộc vào việc người dùng có nhìn thấy một nút trên giao diện hay không.

Quy trình phát triển Vibe Coding an toàn hơn

Phòng ngừa lỗ hổng sẽ hiệu quả hơn nếu bảo mật được tích hợp ngay từ lúc mô tả yêu cầu. Nếu chỉ kiểm tra khi ứng dụng đã hoàn thiện, việc sửa lỗi có thể tốn nhiều công sức vì phải thay đổi cấu trúc dữ liệu, API hoặc cách xử lý nghiệp vụ.

Bước 1: Xác định dữ liệu và chức năng cần bảo vệ

Trước khi yêu cầu AI viết mã, hãy xác định ứng dụng lưu những loại dữ liệu nào, ai được phép truy cập và hậu quả nếu dữ liệu bị lộ hoặc bị sửa đổi trái phép.

Ví dụ, một website giới thiệu doanh nghiệp có thể chủ yếu cần bảo vệ tài khoản quản trị, biểu mẫu liên hệ và thông tin cấu hình. Trong khi đó, một website thương mại điện tử còn phải bảo vệ thông tin khách hàng, đơn hàng, giao dịch thanh toán và quy trình phân quyền nhân viên.

Việc xác định tài sản cần bảo vệ giúp bạn lựa chọn biện pháp phù hợp thay vì áp dụng những yêu cầu bảo mật chung chung nhưng bỏ sót rủi ro quan trọng nhất.

Bước 2: Đưa yêu cầu bảo mật vào prompt ngay từ đầu

Prompt không chỉ nên mô tả giao diện, chức năng và công nghệ cần sử dụng. Hãy nêu rõ các điều kiện bảo mật mà mã nguồn phải đáp ứng.

Ví dụ, khi xây dựng chức năng quản lý đơn hàng, bạn có thể yêu cầu AI xác thực người dùng ở phía máy chủ, kiểm tra quyền sở hữu từng đơn hàng, sử dụng truy vấn tham số hóa, xác thực dữ liệu đầu vào và không trả về thông tin nhạy cảm không cần thiết.

Đối với những chức năng có rủi ro cao, hãy yêu cầu AI trình bày cách xử lý các trường hợp thất bại và những kiểm thử cần có. Cách tiếp cận này giúp các yêu cầu bảo mật trở thành một phần của đặc tả kỹ thuật, thay vì chỉ là công việc bổ sung sau khi hoàn thành.

Bước 3: Phát triển theo từng phần nhỏ và kiểm tra sau mỗi thay đổi

Việc yêu cầu AI xây dựng toàn bộ ứng dụng trong một lần có thể khiến mã nguồn trở nên khó kiểm tra, khó xác định nguyên nhân khi xảy ra lỗi và khó đánh giá tác động của từng thay đổi.

Nên chia dự án thành những phần có phạm vi rõ ràng, chẳng hạn xác thực, quản lý dữ liệu, API, giao diện và tích hợp dịch vụ bên ngoài. Sau mỗi phần, hãy kiểm tra chức năng, xem lại mã nguồn và chạy những bài kiểm thử liên quan trước khi tiếp tục.

Nếu AI cần sửa một lỗi, hãy yêu cầu giải thích nguyên nhân trước khi áp dụng thay đổi lớn. Không nên chấp nhận giải pháp chỉ vì lỗi hiển thị đã biến mất, đặc biệt khi cách sửa liên quan đến xác thực, phân quyền hoặc xác minh dữ liệu.

Bước 4: Quản lý mã nguồn và bảo vệ môi trường triển khai

Sử dụng hệ thống quản lý phiên bản giúp theo dõi lịch sử thay đổi, so sánh các phiên bản và khôi phục khi một cập nhật gây ra sự cố. Mỗi thay đổi quan trọng nên được xem xét trước khi đưa vào nhánh phát hành.

Đồng thời, cần phân tách môi trường phát triển, thử nghiệm và sản xuất khi phù hợp. Môi trường thử nghiệm nên sử dụng dữ liệu giả lập hoặc dữ liệu đã được làm sạch, tránh đưa thông tin khách hàng thật vào những hệ thống không cần thiết.

Khóa API và thông tin xác thực cần được quản lý riêng, không lưu trực tiếp trong mã nguồn công khai. Quyền truy cập vào kho mã nguồn, máy chủ, cơ sở dữ liệu và hệ thống triển khai cũng cần được giới hạn theo nhiệm vụ.

Bước 5: Kiểm tra bảo mật trước mỗi lần phát hành

Trước khi triển khai phiên bản mới, cần kiểm tra các thay đổi quan trọng, chạy kiểm thử tự động, rà soát thư viện và xác minh cấu hình môi trường. Những lỗi nghiêm trọng liên quan đến xác thực, phân quyền, rò rỉ bí mật hoặc thực thi mã không an toàn cần được xử lý trước khi phát hành.

Không nên xem việc ứng dụng chạy thành công hoặc không xuất hiện lỗi trong giao diện là điều kiện đủ để đưa lên môi trường thật. Một phiên bản chỉ nên được phát hành khi đã đáp ứng những tiêu chí kiểm thử và mức độ rủi ro mà dự án đặt ra.

Đối với ứng dụng xử lý thanh toán, dữ liệu cá nhân hoặc thông tin có giá trị cao, nên cân nhắc đánh giá bảo mật chuyên sâu bởi người có chuyên môn trước khi triển khai chính thức.

Bước 6: Theo dõi và xử lý sự cố sau khi triển khai

Bảo mật không kết thúc khi ứng dụng được đưa lên máy chủ. Những lỗ hổng mới có thể được phát hiện trong các thư viện đang sử dụng, trong khi hành vi của người dùng và mức độ khai thác cũng có thể thay đổi theo thời gian.

Cần theo dõi nhật ký đăng nhập, lỗi ứng dụng, hoạt động bất thường và các cảnh báo liên quan đến bảo mật. Nhật ký không nên ghi lại mật khẩu, khóa API hoặc dữ liệu nhạy cảm không cần thiết. Quyền truy cập và thời gian lưu trữ nhật ký cũng cần được kiểm soát.

Ngoài ra, nên chuẩn bị quy trình xử lý sự cố bao gồm phát hiện, đánh giá mức độ ảnh hưởng, cô lập thành phần bị tác động, thu hồi thông tin xác thực bị lộ, khắc phục nguyên nhân và kiểm tra lại trước khi khôi phục hoạt động.

Prompt mẫu giúp giảm lỗ hổng khi sử dụng Vibe Coding

Để AI tạo mã nguồn có định hướng bảo mật rõ ràng hơn, bạn có thể sử dụng một prompt làm tiêu chuẩn chung cho dự án. Prompt nên yêu cầu công cụ xem xét những rủi ro phù hợp với chức năng đang phát triển, thay vì chỉ yêu cầu tạo mã chạy được.

Hãy phát triển chức năng theo nguyên tắc bảo mật ngay từ đầu. Trước khi viết mã, hãy xác định dữ liệu đầu vào, dữ liệu nhạy cảm, quyền truy cập và những rủi ro bảo mật liên quan đến chức năng.

Sử dụng các biện pháp phù hợp để ngăn SQL Injection, XSS, lỗi phân quyền, CSRF, rò rỉ thông tin xác thực và các lỗ hổng liên quan đến cách xử lý dữ liệu. Chỉ áp dụng những biện pháp phù hợp với kiến trúc và công nghệ của dự án.

Không lưu mật khẩu dưới dạng văn bản thuần, không đưa khóa bí mật vào mã nguồn phía trình duyệt, không tin tưởng dữ liệu do người dùng hoặc dịch vụ bên ngoài cung cấp và không dựa vào giao diện để thực thi quyền truy cập.

Hãy xử lý dữ liệu đầu vào theo đúng ngữ cảnh, kiểm tra quyền ở phía máy chủ, giới hạn tài nguyên và sử dụng cơ chế xác thực phù hợp. Không vô hiệu hóa các biện pháp bảo vệ chỉ để khắc phục lỗi trong quá trình phát triển.

Sau khi hoàn thành, hãy giải thích những phần đã triển khai, các giả định bảo mật, những trường hợp chưa được xử lý và các bài kiểm thử cần thực hiện. Nếu chưa đủ thông tin để bảo đảm một yêu cầu an toàn, hãy nêu rõ điểm còn thiếu thay vì khẳng định mã nguồn hoàn toàn an toàn.

Prompt trên giúp AI hiểu rõ hơn những tiêu chí cần đáp ứng, nhưng không thể tự bảo đảm ứng dụng không có lỗ hổng. Bạn vẫn cần xem xét mã nguồn, kiểm thử và xác minh các biện pháp bảo vệ trong môi trường thực tế.

Checklist bảo mật trước khi đưa sản phẩm Vibe Coding vào hoạt động

Trước khi công khai website hoặc ứng dụng, hãy rà soát những hạng mục quan trọng dưới đây. Checklist này phù hợp để kiểm tra ban đầu, nhưng không thay thế cho quy trình đánh giá bảo mật chuyên sâu đối với hệ thống có rủi ro cao.

Kiểm tra mã nguồn và dữ liệu

  • Các truy vấn cơ sở dữ liệu sử dụng cơ chế tham số hóa phù hợp.
  • Dữ liệu người dùng được kiểm tra và mã hóa theo đúng ngữ cảnh khi hiển thị.
  • Không có khóa API, mật khẩu hoặc thông tin xác thực bị lộ trong mã nguồn công khai.
  • Các thao tác đọc, sửa và xóa dữ liệu đều có kiểm tra quyền ở phía máy chủ.
  • Chức năng tải tệp có giới hạn định dạng, dung lượng và vị trí lưu trữ.
  • Những chức năng đọc tệp hoặc lấy dữ liệu từ URL có cơ chế giới hạn phạm vi truy cập.

Kiểm tra xác thực và phân quyền

  • Mật khẩu được lưu bằng cơ chế băm mật khẩu phù hợp.
  • Phiên đăng nhập được quản lý an toàn và có cơ chế hết hạn phù hợp.
  • Cookie xác thực có các thuộc tính bảo vệ cần thiết.
  • Các thao tác thay đổi dữ liệu có biện pháp chống CSRF khi cần thiết.
  • Người dùng không thể truy cập dữ liệu của tài khoản khác bằng cách thay đổi ID hoặc tham số yêu cầu.
  • Các tài khoản quản trị được bảo vệ bằng biện pháp xác thực phù hợp với mức độ rủi ro.

Kiểm tra máy chủ và dịch vụ bên ngoài

  • HTTPS và xác minh chứng chỉ TLS được cấu hình phù hợp.
  • Thông báo lỗi không làm lộ đường dẫn nội bộ, thông tin kết nối hoặc dữ liệu nhạy cảm.
  • Không công khai tệp sao lưu, tệp cấu hình hoặc thư mục không dành cho người dùng bên ngoài.
  • Tài khoản cơ sở dữ liệu và tài khoản dịch vụ chỉ có những quyền cần thiết.
  • Webhook được xác minh theo cơ chế phù hợp của nhà cung cấp.
  • API có giới hạn tần suất, thời gian xử lý và tài nguyên phù hợp.
  • Thư viện và thành phần phụ thuộc được kiểm tra các cảnh báo bảo mật đã biết.

Kiểm tra trước khi phát hành

  • Đã xem xét những thay đổi quan trọng do AI tạo ra.
  • Đã chạy các bài kiểm thử chức năng và kiểm thử bảo mật phù hợp.
  • Đã xử lý những lỗi nghiêm trọng chưa được chấp nhận trong tiêu chí phát hành.
  • Đã sao lưu dữ liệu cần thiết và có phương án khôi phục khi xảy ra sự cố.
  • Đã kiểm tra nhật ký, cảnh báo và quy trình xử lý sự cố.
  • Đã xác minh cấu hình môi trường sản xuất thay vì chỉ dựa vào kết quả trong môi trường phát triển.

Khi nào cần chuyên gia bảo mật kiểm tra mã nguồn do AI tạo?

Không phải mọi website được tạo bằng Vibe Coding đều cần một cuộc kiểm thử xâm nhập quy mô lớn. Tuy nhiên, khi ứng dụng xử lý dữ liệu cá nhân, giao dịch tài chính, thông tin nội bộ hoặc các chức năng có thể gây thiệt hại đáng kể nếu bị khai thác, việc đánh giá chuyên sâu trở nên quan trọng hơn.

Bạn nên cân nhắc nhờ chuyên gia kiểm tra khi ứng dụng có một hoặc nhiều đặc điểm sau:

  • Lưu trữ hoặc xử lý dữ liệu cá nhân nhạy cảm.
  • Có chức năng thanh toán, quản lý số dư hoặc thực hiện giao dịch.
  • Cho phép người dùng tải lên và xử lý nhiều loại tệp.
  • Có nhiều vai trò người dùng với quyền hạn khác nhau.
  • Kết nối nhiều API bên ngoài hoặc có quyền truy cập vào hệ thống nội bộ.
  • Được triển khai cho nhiều khách hàng hoặc phục vụ số lượng người dùng lớn.
  • Đã phát hiện sự cố, dấu hiệu truy cập trái phép hoặc lỗ hổng nghiêm trọng.

Việc đánh giá nên dựa trên kiến trúc và mô hình đe dọa của ứng dụng, không chỉ dựa vào việc mã nguồn được viết bởi AI hay lập trình viên. Một dự án nhỏ vẫn có thể chứa lỗ hổng nghiêm trọng nếu xử lý sai thông tin xác thực hoặc dữ liệu nhạy cảm.

Đối với các hệ thống quan trọng, có thể kết hợp rà soát mã nguồn, phân tích phụ thuộc, kiểm thử xâm nhập trong phạm vi được cho phép và đánh giá quy trình triển khai. Những kết quả này giúp xác định rủi ro còn tồn tại và ưu tiên nguồn lực khắc phục.

Kết luận: Vibe Coding nhanh hơn nhưng vẫn cần quy trình bảo mật

Vibe Coding giúp rút ngắn thời gian phát triển phần mềm và mở rộng khả năng xây dựng ứng dụng cho nhiều đối tượng. Tuy nhiên, tốc độ tạo mã nguồn không đồng nghĩa với tốc độ đạt được mức độ an toàn cần thiết.

Những lỗ hổng như SQL Injection, XSS, lỗi phân quyền, CSRF, SSRF, tải tệp không an toàn và rò rỉ khóa API có thể xuất hiện khi AI không được cung cấp đầy đủ yêu cầu hoặc khi người phát triển bỏ qua bước kiểm tra. Ngoài ra, cấu hình máy chủ, thư viện bên thứ ba và quy trình xử lý dữ liệu cũng có thể tạo ra những rủi ro nằm ngoài phần mã nguồn trực tiếp do AI viết.

Cách tiếp cận hiệu quả là xem AI như một công cụ hỗ trợ phát triển, không phải người chịu trách nhiệm cuối cùng về bảo mật. Hãy mô tả yêu cầu rõ ràng, phát triển theo từng phần, kiểm tra quyền truy cập ở phía máy chủ, sử dụng công cụ phân tích tự động và kiểm thử những tình huống bất thường trước khi triển khai.

Quan trọng hơn, cần duy trì việc rà soát và cập nhật sau khi ứng dụng đi vào hoạt động. Khi bảo mật được tích hợp xuyên suốt vòng đời phát triển, Vibe Coding có thể trở thành một phương pháp hữu ích để xây dựng sản phẩm nhanh hơn mà vẫn kiểm soát được những rủi ro quan trọng.

  • ★★★★★ ★★★★★
  • 0 Bình luận
CEO Bùi Tấn Lực | Founder Web Mới
Bùi Tấn Lực
Tìm hiểu về CEO Bùi Tấn Lực, Founder Web Mới với nhiều năm kinh nghiệm trong lĩnh vực phát triển website, SEO và chia sẻ kiến thức công nghệ
Đánh giá
Chia sẻ nội dung đánh giá của bạn về Những lỗ hổng bảo mật thường gặp khi Vibe Coding
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 *
Đánh giá của bạn
Tên *
Email
Số điện thoại *
Bình luận, Hỏi đáp
Yêu Cầu Báo Giá
Gửi trang web mẫu cần làm theo, chúng tôi sẽ báo giá đến bạn từ Email (tanlucit09@gmail.com - Bùi Tấn Lực) hoặc Zalo (Lực IT - 0398259259) !