Website Vibe Coding có an toàn không? 7 rủi ro cần kiểm tra

Hung Pham
21 thg 7
12 phút đọc

Website được tạo bằng AI có thể hoàn thành trong vài giờ thay vì nhiều tuần. Giao diện hoạt động, người dùng đăng nhập được, dữ liệu được lưu và sản phẩm có thể nhanh chóng được đưa lên Internet.

Nhưng website chạy đúng chức năng chưa đồng nghĩa với website an toàn.

Một ứng dụng có thể hoạt động bình thường với người dùng hợp lệ nhưng vẫn để lộ API key, cho phép tài khoản này đọc dữ liệu của tài khoản khác hoặc để một endpoint quan trọng hoạt động mà không cần xác thực.

Vì vậy, câu trả lời cho câu hỏi website vibe coding có an toàn không là:

Website vibe coding có thể an toàn, nhưng không nên được mặc định là an toàn nếu code, API, quyền truy cập và cấu hình triển khai chưa được kiểm tra độc lập.

Các nghiên cứu gần đây về ứng dụng vibe-coded ghi nhận những nhóm lỗi lặp lại như secret exposure, dữ liệu đầu vào không được lọc, logic placeholder và các hạn chế mang tính hệ thống trong quá trình AI tạo code. Prompt tốt hơn có thể giảm lỗi nhưng chưa thể loại bỏ hoàn toàn rủi ro.

vibe-coding-co-thuc-su-an-toan — *Các rủi ro bảo mật thường gặp khi vibe code*

Dưới đây là 7 rủi ro cần kiểm tra trước khi đưa website do AI tạo lên production.

1. API key và thông tin bí mật bị lộ

Để kết nối nhanh với cơ sở dữ liệu, cổng thanh toán, dịch vụ gửi email hoặc nền tảng AI, coding assistant có thể đưa thông tin xác thực trực tiếp vào code hoặc file cấu hình.

Những dữ liệu có thể bị lộ gồm:

API key;
mật khẩu cơ sở dữ liệu;
JWT signing secret;
OAuth client secret;
webhook secret;
cloud access key;
private key;
service account credential.

Secret không chỉ bị lộ khi xuất hiện trực tiếp trong mã nguồn. Nó còn có thể nằm trong:

file .env bị commit;
lịch sử Git;
frontend JavaScript bundle;
log ứng dụng;
source map;
Docker image;
file cấu hình CI/CD;
thông báo lỗi;
prompt gửi cho AI;
ảnh chụp màn hình.

OWASP khuyến nghị doanh nghiệp quản lý tập trung việc lưu trữ, cấp phát, kiểm toán và xoay vòng secret thay vì để credential phân tán trong code và file cấu hình.

Tình huống thường gặp

Người xây dựng website yêu cầu AI kết nối một API bên thứ ba. API key được đặt trong biến môi trường và chức năng hoạt động bình thường.

Tuy nhiên, biến đó lại được sử dụng trong code frontend. Sau khi ứng dụng được build, giá trị bí mật xuất hiện trong JavaScript mà trình duyệt tải xuống.

Bất kỳ ai mở Developer Tools cũng có thể đọc và sử dụng API key này.

Việc lưu giá trị trong .env không còn ý nghĩa nếu secret cuối cùng vẫn được gửi xuống trình duyệt.

Hậu quả

Kẻ tấn công có thể:

sử dụng dịch vụ bằng tài khoản của doanh nghiệp;
phát sinh chi phí API;
đọc hoặc sửa dữ liệu;
gửi email giả mạo;
tạo token trái phép;
truy cập tài nguyên cloud;
sử dụng credential làm điểm xâm nhập sâu hơn.

Nếu secret từng được đẩy lên repository công khai, cần xem secret đó đã bị lộ, kể cả khi dòng code sau đó được xóa.

Doanh nghiệp có thể tham khảo thêm báo cáo IPSIP về tình trạng secrets sprawl và rủi ro khi thông tin bí mật phân tán trong hệ thống.

2. Có trang đăng nhập nhưng xác thực chưa an toàn

Một giao diện đăng nhập hoàn chỉnh không chứng minh backend đã được bảo vệ đúng cách.

AI có thể tạo đầy đủ chức năng:

đăng ký;
đăng nhập;
đăng xuất;
quên mật khẩu;
phân vai trò;
ghi nhớ phiên đăng nhập.

Tuy nhiên, hệ thống vẫn có thể thiếu:

giới hạn số lần đăng nhập sai;
thời hạn token hợp lý;
thu hồi token sau khi đổi mật khẩu;
bảo vệ quy trình đặt lại mật khẩu;
xác minh tài khoản;
xác thực đa yếu tố;
cookie an toàn;
kiểm tra trạng thái tài khoản ở backend.

OWASP yêu cầu các biện pháp xác thực phải được thực thi trên hệ thống đáng tin cậy và khuyến nghị sử dụng cơ chế xác thực tập trung, đã được kiểm chứng.

Rủi ro chỉ bảo vệ giao diện

Một lỗi phổ biến là website chỉ kiểm tra trạng thái đăng nhập bằng JavaScript hoặc ẩn menu quản trị khỏi người dùng thường.

Kẻ tấn công không cần sử dụng giao diện. Họ có thể gọi trực tiếp API bằng script, cURL, Postman hoặc công cụ kiểm thử.

Ví dụ, frontend chuyển người chưa đăng nhập về trang login nhưng endpoint sau vẫn trả dữ liệu:

GET /api/customers

Nếu backend không xác minh session hoặc token, dữ liệu khách hàng có thể bị truy cập trực tiếp.

Dấu hiệu cần kiểm tra

API vẫn phản hồi khi bỏ token.
Token hết hạn vẫn sử dụng được.
Logout nhưng token cũ vẫn hoạt động.
Đổi mật khẩu nhưng session cũ không bị thu hồi.
Link đặt lại mật khẩu có thể dùng nhiều lần.
Không có rate limiting tại endpoint đăng nhập.
Backend tin role được gửi từ frontend.
Trang admin bị ẩn nhưng API admin vẫn truy cập được.

Các ứng dụng sử dụng OAuth cần đặc biệt chú ý đến vòng đời token. IPSIP đã phân tích thêm vấn đề này trong bài OAuth token và “cửa hậu” bảo mật doanh nghiệp thường bỏ sót.

3. Người dùng có thể truy cập dữ liệu không thuộc quyền

Authentication trả lời câu hỏi: “Người dùng là ai?”

Authorization trả lời câu hỏi: “Người dùng được phép làm gì?”

Website có thể xác thực đúng nhưng vẫn mắc lỗi phân quyền nghiêm trọng.

Đây là một trong những nhóm rủi ro quan trọng nhất đối với web vibe coding, đặc biệt khi AI chỉ xử lý từng màn hình hoặc từng endpoint riêng lẻ mà không hiểu đầy đủ quy tắc kinh doanh.

OWASP API Security Top 10 xếp Broken Object Level Authorization, Broken Authentication và Broken Object Property Level Authorization vào nhóm rủi ro hàng đầu của API.

Ví dụ thay đổi ID

Người dùng đăng nhập và xem đơn hàng tại:

/orders/1001

Nếu thay 1001 thành 1002 và xem được đơn hàng của tài khoản khác, hệ thống không kiểm tra quyền sở hữu tài nguyên đúng cách.

Cùng kỹ thuật đó có thể được áp dụng với:

invoice ID;
customer ID;
user ID;
tenant ID;
file ID;
project ID;
ticket ID;
URL tải tài liệu.

Rủi ro trong ứng dụng đa tenant

Đối với SaaS phục vụ nhiều doanh nghiệp, lỗi phân quyền có thể khiến tenant A đọc hoặc chỉnh sửa dữ liệu của tenant B.

Hậu quả không chỉ là lỗi kỹ thuật. Doanh nghiệp có thể đối mặt với:

rò rỉ dữ liệu khách hàng;
vi phạm hợp đồng;
mất uy tín;
sự cố tuân thủ;
gián đoạn hoạt động;
tranh chấp với khách hàng;
chi phí điều tra và khắc phục.

AI không phải lúc nào cũng hiểu được những quy tắc như:

người tạo yêu cầu không được tự phê duyệt;
nhân viên chỉ được xem dữ liệu thuộc phòng ban;
quản lý được xem nhưng không được xóa;
tenant phải được cô lập tuyệt đối;
tài khoản trial không được sử dụng tính năng trả phí;
nhân viên hỗ trợ không được tự đổi chủ sở hữu tài khoản.

Đây là lý do lỗi authorization và business logic thường cần kiểm thử thủ công thay vì chỉ dựa vào scanner.

Để hiểu thêm về bề mặt tấn công API, có thể tham khảo tài liệu API Security do IPSIP tổng hợp.

4. Dữ liệu chỉ được kiểm tra ở frontend

AI thường thêm validation vào form để bảo đảm:

email đúng định dạng;
trường bắt buộc không để trống;
số điện thoại chỉ chứa số;
giá trị không được âm;
file phải có phần mở rộng phù hợp.

Nhưng validation trên trình duyệt có thể bị bỏ qua hoàn toàn bằng cách gửi request trực tiếp đến API.

OWASP khuyến nghị tất cả dữ liệu đầu vào phải được kiểm tra ở phía server, bất kể ứng dụng đã có validation tại client.

Khi backend tin dữ liệu từ frontend

Kẻ tấn công có thể gửi:

giá trị âm;
giá trị vượt giới hạn;
chuỗi cực dài;
trường không có trên giao diện;
role quản trị;
giá giao dịch đã bị sửa;
nội dung HTML hoặc JavaScript;
câu lệnh truy vấn;
đường dẫn file bất thường;
file có mã thực thi;
payload lớn gây cạn tài nguyên.

Những lỗ hổng có thể phát sinh

SQL Injection;
NoSQL Injection;
Cross-site Scripting;
Command Injection;
Path Traversal;
Server-side Template Injection;
Mass Assignment;
upload file độc hại;
Server-side Request Forgery.

Website có thể không xuất hiện lỗi trong quá trình sử dụng bình thường nhưng vẫn bị khai thác khi request được chỉnh sửa có chủ đích.

5. Dependency do AI đề xuất có thể không an toàn

Khi gặp một chức năng mới, coding assistant thường đề xuất cài thêm package để hoàn thành nhanh hơn.

Package đó có thể:

có lỗ hổng đã được công bố;
không còn được duy trì;
có tên gần giống thư viện phổ biến;
chứa dependency con không cần thiết;
sử dụng license không phù hợp;
có maintainer không rõ ràng;
thực thi script trong quá trình cài đặt;
thậm chí không thực sự tồn tại.

Rủi ro package do AI “tưởng tượng”

AI có thể tạo ra tên package nghe hợp lý nhưng chưa tồn tại trên registry.

Nếu người dùng cài đặt mà không xác minh, kẻ xấu có thể đăng ký package cùng tên và đưa mã độc vào đó.

Khi package được cài, mã độc có thể:

đọc biến môi trường;
đánh cắp token;
sửa mã nguồn;
kết nối máy chủ bên ngoài;
tác động pipeline;
mở điểm truy cập lâu dài.

Vì sao vibe coding làm rủi ro tăng?

Người dùng thường chỉ quan tâm:

“Lệnh cài đặt có chạy thành công và lỗi có biến mất không?”

Nếu câu trả lời là có, package dễ được giữ lại mà không kiểm tra tác giả, CVE, lịch sử phát hành hoặc quyền mà package yêu cầu.

Mỗi dependency mới làm tăng bề mặt tấn công chuỗi cung ứng. IPSIP cũng đã phân tích sâu hơn trong bài chuỗi cung ứng phần mềm bị tấn công như thế nào.

6. API và cấu hình production bị bỏ ngỏ

Code tương đối an toàn không đồng nghĩa môi trường triển khai đã an toàn.

Website vẫn có thể làm lộ dữ liệu vì:

database mở ra Internet;
storage bucket cho phép đọc công khai;
debug mode chưa tắt;
CORS cho phép mọi origin;
source map bị công khai;
dashboard quản trị không có xác thực;
endpoint test còn tồn tại;
backup nằm trong thư mục public;
thông báo lỗi trả về stack trace;
service account có quyền quá lớn;
môi trường demo sử dụng dữ liệu thật.

Nghiên cứu VibeGuard chỉ ra rằng một số lỗi liên quan đến artifact, source map, packaging configuration và chuỗi cung ứng có thể nằm ngoài phạm vi phát hiện của scanner truyền thống.

Tình huống thường gặp

Một nhóm kinh doanh tạo dashboard nội bộ bằng AI để theo dõi khách hàng.

Ban đầu ứng dụng chỉ là prototype. Sau đó, đường dẫn được gửi qua email, chia sẻ với đối tác hoặc vô tình được công cụ tìm kiếm lập chỉ mục.

Do không có xác thực hoặc giới hạn mạng, một công cụ nội bộ trở thành ứng dụng công khai.

Điểm yếu trong trường hợp này không nhất thiết là một lỗi thuật toán. Đó là thiếu quy trình kiểm tra cấu hình trước khi triển khai.

Đối với ứng dụng triển khai trên cloud, doanh nghiệp nên đọc thêm:

7. AI coding agent có quá nhiều quyền

Rủi ro không chỉ nằm trong code được tạo ra. Chính coding agent cũng có thể trở thành một phần của bề mặt tấn công.

Tùy cấu hình, agent có thể được phép:

đọc toàn bộ repository;
sửa hoặc xóa file;
chạy lệnh shell;
cài package;
đọc biến môi trường;
truy cập database;
kết nối cloud;
dùng MCP server;
deploy ứng dụng;
thao tác trực tiếp với production.

Nếu agent đọc nội dung bên ngoài chứa chỉ dẫn độc hại, quyền truy cập rộng có thể làm tăng mức độ ảnh hưởng.

Nguồn chứa chỉ dẫn độc hại có thể là:

repository;
issue;
tài liệu;
website;
email;
API response;
file tải về;
package documentation.

Khi đó, agent có thể bị tác động để:

đọc secret;
gửi dữ liệu ra ngoài;
cài package độc hại;
thay đổi cấu hình;
thực hiện lệnh nguy hiểm;
sửa code theo hướng làm yếu bảo mật.

IPSIP đã có các bài phân tích liên quan:

Website vibe coding nào có mức rủi ro cao?

Không phải mọi dự án đều có mức rủi ro giống nhau.

Landing page không có tài khoản, không lưu dữ liệu và không kết nối hệ thống nội bộ thường ít rủi ro hơn một nền tảng SaaS đa tenant.

Cần ưu tiên đánh giá bảo mật nếu website:

có tài khoản người dùng;
lưu dữ liệu cá nhân;
lưu dữ liệu khách hàng;
có nhiều vai trò;
phục vụ nhiều tenant;
có trang quản trị;
xử lý thanh toán;
cung cấp API;
cho phép upload file;
kết nối hệ thống nội bộ;
sử dụng AI agent;
thực hiện giao dịch tự động;
được sử dụng bởi khách hàng doanh nghiệp.

Câu hỏi quan trọng không phải:

Bao nhiêu phần trăm code được AI tạo?

Câu hỏi nên là:

Nếu chức năng này bị lạm dụng, dữ liệu nào có thể bị lộ và hoạt động kinh doanh nào có thể bị ảnh hưởng?

Dấu hiệu website chưa sẵn sàng lên production

Doanh nghiệp nên dừng việc triển khai và đánh giá lại nếu:

không ai hiểu đầy đủ code do AI tạo;
không có tài liệu về role và quyền;
chưa từng gọi API ngoài giao diện;
chưa kiểm tra truy cập chéo tài khoản;
production dùng chung credential với development;
AI agent truy cập được dữ liệu thật;
chưa chạy secret scanning;
package được cài chỉ vì AI đề xuất;
không có log cho hành động quản trị;
không có người chịu trách nhiệm phê duyệt bảo mật;
prototype được public ngay khi chạy được.

NIST khuyến nghị tích hợp các thực hành phát triển phần mềm an toàn vào toàn bộ vòng đời phát triển thay vì coi bảo mật là hoạt động riêng ở cuối dự án.

Quét lỗ hổng có đủ để kết luận website an toàn không?

Không.

Quét lỗ hổng có thể phát hiện nhanh:

thành phần lỗi thời;
một số cấu hình sai;
endpoint bị lộ;
security header thiếu;
một số mẫu injection;
lỗ hổng đã biết.

Nhưng công cụ tự động thường khó xác định:

người dùng có đang truy cập đúng dữ liệu không;
tenant có được cô lập không;
quy trình phê duyệt có thể bị bỏ qua không;
giá trị giao dịch có thể bị thay đổi không;
chức năng có thể bị thực hiện hai lần không;
agent có thể bị lạm dụng để thực hiện hành động ngoài phạm vi không.

Xem thêm bài phân biệt kiểm thử xâm nhập và quét lỗ hổng bảo mật để lựa chọn phương pháp phù hợp.

Khi nào website vibe coding cần pentest?

Nên thực hiện pentest trước production khi website:

lưu dữ liệu nhạy cảm;
có thanh toán;
có nhiều nhóm quyền;
có API;
hoạt động theo mô hình SaaS đa tenant;
kết nối hệ thống nội bộ;
có trang quản trị;
cho phép upload file;
sử dụng AI agent;
chuẩn bị phục vụ khách hàng doanh nghiệp.

Pentest không chỉ tìm xem code có lỗi hay không. Mục tiêu là xác định lỗi có thể bị khai thác như thế nào và tác động thực tế đến dữ liệu hoặc hoạt động kinh doanh.

Doanh nghiệp có thể tham khảo:

Kết luận: Website vibe coding không nên được “tin mặc định”

Vibe coding không mặc nhiên tạo ra website không an toàn.

AI có thể giúp doanh nghiệp:

tạo prototype nhanh;
giảm công việc lặp lại;
kiểm chứng ý tưởng;
rút ngắn thời gian phát triển;
hỗ trợ đội ngũ nhỏ xây dựng sản phẩm.

Rủi ro xuất hiện khi tốc độ tạo code vượt quá khả năng review, kiểm thử và quản trị.

Website do AI tạo chỉ nên được đưa lên production khi đội ngũ có thể trả lời rõ:

dữ liệu nào đang được xử lý;
ai được phép truy cập dữ liệu đó;
API nào được công khai;
secret được lưu ở đâu;
dependency nào đang được sử dụng;
agent được phép làm gì;
lỗi nào có thể ảnh hưởng đến doanh nghiệp;
ai chịu trách nhiệm xử lý sự cố.

Prompt yêu cầu AI “viết code an toàn” có thể hỗ trợ giảm lỗi, nhưng không thay thế được code review, kiểm thử API, kiểm tra phân quyền và pentest.

Đối với website có dữ liệu hoặc logic kinh doanh quan trọng, bước tiếp theo nên là áp dụng một quy trình bảo mật có thể kiểm chứng thay vì tiếp tục yêu cầu AI tự đánh giá code của chính nó.

Đọc tiếp: 10 giải pháp bảo mật cho website Vibe Coding trước production.

-------------------------

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

Website tạo bằng AI có chắc chắn chứa lỗ hổng không?

Không. Website tạo bằng AI không mặc nhiên có lỗ hổng. Tuy nhiên, code do AI tạo vẫn cần được review và kiểm thử như code do con người viết.

AI có thể tự kiểm tra bảo mật cho code do AI tạo không?

AI có thể hỗ trợ tìm lỗi, giải thích code và đề xuất test case. Tuy nhiên, không nên dùng AI làm lớp kiểm soát duy nhất vì công cụ có thể bỏ sót lỗi phân quyền, business logic và cấu hình môi trường.

Chỉ cần dùng công cụ quét website là đủ không?

Không. Scanner phù hợp để tìm nhanh một số lỗ hổng kỹ thuật, nhưng thường không hiểu đầy đủ quyền truy cập và logic kinh doanh.

Website nhỏ có cần pentest không?

Landing page tĩnh thường không cần cùng mức kiểm thử như hệ thống SaaS. Pentest nên được ưu tiên khi website lưu dữ liệu, có tài khoản, API, thanh toán hoặc trang quản trị.

Website vibe coding cần kiểm tra lại khi nào?

Nên kiểm tra lại sau thay đổi lớn liên quan đến đăng nhập, phân quyền, thanh toán, API, upload file, dependency, hạ tầng cloud hoặc AI agent.

---------------

Nguồn tham khảo