Trang Chủ › Tin Tức › Bài Viết

Bảo Mật Code Website Do AI Sinh Ra | Mahaton

Loc Tan Huynh
Website dùng mã do AI sinh ra dễ mang lỗ hổng nào? Cách chủ doanh nghiệp tự phát hiện và 7 điều cần xác nhận bằng văn bản trước khi nghiệm thu.
September 7, 2026

Mahaton Project là đơn vị chuyên cung cấp giải pháp Digital Marketing toàn diện cho doanh nghiệp tại Việt Nam, trực thuộc hệ thống Công ty TNHH Minh Phát với hơn 30 năm kinh nghiệm trong ngành sản xuất và thương mại.

Chúng tôi giúp khách hàng:

Tăng trưởng lợi nhuận và mở rộng tệp khách hàng

Cắt giảm đến 60% chi phí nhân sự vận hành

Tiết kiệm thời gian quản lý gấp 5 lần

Cung cấp cho ban lãnh đạo bảng điều khiển trực quan để đo lường hiệu quả thời gian thực

Tất cả thông qua ba trụ cột dịch vụ:

Thiết kế website chuyên nghiệp, chuẩn SEO

Quảng cáo Google/YouTube hiệu suất cao

Ứng dụng trí tuệ nhân tạo (AI) trong vận hành kinh doanh

Với kinh nghiệm phục vụ hơn 10 đối tác trong các lĩnh vực đa dạng — từ hãng hàng không quốc tế (American Airlines), chuỗi F&B (Panda Express, China Queen), bán lẻ (Co.op Mart), truyền thông (HTV1), viễn thông (Viettel), đến các doanh nghiệp sản xuất Việt Nam (TAKI Elevator, Minh Phát EPS, Tấn Đại Bao Bì, Nam Phát Tôn) — chúng tôi hiểu rõ nhu cầu thị trường và cam kết mang đến giải pháp tạo tăng trưởng thực sự cho từng khách hàng.

‍

Điểm chính

  • Công cụ AI học từ kho mã nguồn công khai, trong đó có cả mã cũ và mã sai, nên nó tái tạo lại thói quen an toàn lẫn thói quen nguy hiểm của cộng đồng lập trình.
  • Công cụ AI tối ưu cho việc "chạy được", không tối ưu cho việc "an toàn", và nó hoàn toàn không biết dữ liệu nào trong doanh nghiệp của anh chị là quan trọng.
  • Năm nhóm lỗ hổng hay bị bỏ sót: xác thực và phân quyền lỏng, lộ khoá truy cập và thông tin cấu hình, không kiểm tra dữ liệu người dùng nhập, thư viện cũ có lỗ hổng đã công bố, thông báo lỗi lộ thông tin nội bộ.
  • Chủ doanh nghiệp không cần đọc mã nguồn; chỉ cần bảy câu hỏi buộc đơn vị làm web xác nhận bằng văn bản trước khi ký nghiệm thu.

Vì sao mã nguồn do AI sinh ra dễ mang lỗ hổng

Trong hai năm gần đây, gần như mọi đơn vị làm web đều dùng công cụ AI ở một mức độ nào đó. Điều này không xấu. Nó rút ngắn thời gian, giảm chi phí và giúp doanh nghiệp nhỏ có được thứ mà trước đây chỉ công ty lớn mới trả nổi. Nhưng nó thay đổi bản chất của rủi ro, và phần lớn chủ doanh nghiệp chưa được ai giải thích rõ điều đó. Nếu anh chị chưa đọc phần nền, bài AI viết mã cho website và những điều doanh nghiệp cần biết giải thích kỹ hơn cách các đơn vị đang dùng công cụ này trong thực tế.

Lý do thứ nhất: công cụ AI học từ mã nguồn công khai trên mạng. Kho đó chứa rất nhiều mã tốt, nhưng cũng chứa mã viết từ nhiều năm trước, mã viết vội để minh hoạ một ý tưởng, và mã đơn giản là sai. Công cụ không phân biệt được đâu là bài mẫu dạy học đã lỗi thời và đâu là mã đã qua kiểm duyệt an ninh. Nó chỉ thấy rằng cách viết đó xuất hiện nhiều, nên nó lặp lại.

Lý do thứ hai: mục tiêu của công cụ là làm cho thứ anh chị yêu cầu chạy được. Khi được giao "làm trang đăng nhập cho nhân viên", nó sẽ tạo ra một trang đăng nhập hoạt động. Nó không tự hỏi điều gì xảy ra nếu ai đó thử một triệu mật khẩu trong một giờ, hay nếu một nhân viên cũ vẫn còn tài khoản. Chạy được và an toàn là hai bài toán khác nhau, và chỉ bài thứ nhất được đặt ra.

Lý do thứ ba, và là lý do quan trọng nhất với anh chị: công cụ không biết bối cảnh rủi ro của doanh nghiệp mình. Nó không biết bảng giá theo từng khách của anh chị là tài sản cạnh tranh. Nó không biết danh sách khách hàng lấy từ biểu mẫu liên hệ có giá trị hơn toàn bộ phần còn lại của website. Nó xử lý mọi dữ liệu như nhau. Đây cũng là điểm khác biệt lớn giữa việc tự dựng bằng công cụ và thuê một đơn vị chịu trách nhiệm, đã bàn trong bài so sánh công cụ AI tự tạo website và thuê đơn vị triển khai.

Năm nhóm lỗ hổng hay bị bỏ sót

Dưới đây là năm nhóm vấn đề gặp thường xuyên nhất, diễn giải bằng ngôn ngữ đời thường. Mục đích là để anh chị biết mình đang mua cái gì và cần hỏi gì, không phải để biết cách tấn công ai.

Xác thực và phân quyền lỏng

Xác thực là câu hỏi "anh là ai". Phân quyền là câu hỏi "anh được xem những gì". Lỗi phổ biến là chỉ làm phần đầu mà quên phần sau. Trang quản trị có yêu cầu đăng nhập, nhưng một đường dẫn cụ thể bên trong lại không kiểm tra lại quyền, nên bất kỳ ai biết đường dẫn đó đều mở được. Một dạng khác là giao diện chỉ ẩn nút bấm đối với người không có quyền, trong khi chức năng phía sau vẫn hoạt động bình thường. Ẩn không phải là khoá.

Lộ khoá truy cập và thông tin cấu hình

Website hiện đại nào cũng phải kết nối với dịch vụ khác: gửi thư, nhắn tin, thanh toán, đồng bộ dữ liệu khách hàng. Mỗi kết nối cần một chuỗi ký tự đóng vai trò chìa khoá. Công cụ AI, khi được yêu cầu làm cho phần kết nối chạy được, rất hay đặt thẳng chìa khoá đó vào trong mã nguồn, thậm chí vào phần mã mà trình duyệt của khách tải về được. Ai mở phần đó ra cũng thấy. Rủi ro này còn lớn hơn khi website có gắn thêm các luồng tự động, như đã phân tích trong bài rủi ro bảo mật dữ liệu khi triển khai AI và cách bảo vệ.

Không kiểm tra dữ liệu người dùng nhập

Mọi ô mà khách gõ được đều là một cánh cửa: biểu mẫu liên hệ, ô tìm kiếm, phần tải tệp lên, ô bình luận. Nguyên tắc nghề là không tin bất cứ thứ gì người dùng gửi lên, phải kiểm tra và làm sạch ở phía máy chủ trước khi dùng. Mã do AI sinh ra thường chỉ kiểm tra ở phía trình duyệt, vì như vậy là đủ để bản trình diễn chạy đẹp. Kiểm tra ở trình duyệt chỉ giúp khách gõ đúng, nó không ngăn được người cố tình gửi dữ liệu bằng cách khác.

Thư viện cũ có lỗ hổng đã công bố

Một website điển hình dùng hàng chục thành phần do bên thứ ba viết sẵn. Khi một thành phần bị phát hiện có lỗ hổng, thông tin đó được công bố công khai để mọi người cập nhật. Nhưng công bố công khai cũng có nghĩa là bất kỳ ai cũng biết. Công cụ AI có xu hướng đề xuất phiên bản mà nó gặp nhiều trong quá trình học, thường là phiên bản cũ. Sau ngày bàn giao, nếu không ai cập nhật, khoảng cách giữa website của anh chị và bản vá cứ rộng dần. Đây là một phần chi phí thật, cần được tính vào ngân sách như trong bài chi phí duy trì website hằng năm cho doanh nghiệp vừa và nhỏ.

Thông báo lỗi lộ thông tin nội bộ

Khi có sự cố, mã do AI sinh ra hay hiển thị nguyên văn thông báo kỹ thuật ra màn hình khách: đường dẫn tệp trên máy chủ, tên bảng dữ liệu, phiên bản phần mềm đang chạy. Với người dùng bình thường thì đó là một mớ chữ khó hiểu. Với người có ý đồ, đó là tấm bản đồ. Khách chỉ cần một câu chung chung và một số hiệu sự cố; chi tiết kỹ thuật để dành cho nhật ký nội bộ.

Cách phát hiện khi anh chị không biết lập trình

Không cần đọc một dòng mã nào, anh chị vẫn kiểm tra được khá nhiều. Thứ nhất, đăng xuất khỏi trang quản trị rồi dán lại một đường dẫn nội bộ vào trình duyệt. Nếu nội dung vẫn hiện ra, phân quyền có vấn đề. Thứ hai, tạo một tài khoản quyền thấp và thử làm những việc mà tài khoản đó không được phép; nếu hệ thống chỉ giấu nút bấm chứ vẫn cho thực hiện, đó là lỗi.

Thứ ba, gửi thử một biểu mẫu liên hệ với ô trống, ô quá dài, ký tự lạ, và gửi liên tiếp nhiều lần. Website tốt sẽ từ chối lịch sự và có giới hạn số lần gửi. Thứ tư, yêu cầu đơn vị thi công cho xem báo cáo rà soát bảo mật và báo cáo kiểm thử tự động chứ không chỉ nghe khẳng định miệng; bài kiểm thử website tự động trước khi lên sóng mô tả các báo cáo này trông như thế nào.

Nói thẳng một điều: nếu đơn vị thi công tỏ ra khó chịu khi anh chị hỏi những câu trên, đó đã là câu trả lời. Một đơn vị làm nghề nghiêm túc sẽ vui vì khách hỏi đúng chỗ, vì nó chứng minh phần việc họ đã bỏ công làm.

Một website chạy đúng và một website an toàn là hai bài kiểm tra khác nhau, và phần lớn dự án chỉ làm bài thứ nhất.

Bảy điều cần xác nhận bằng văn bản trước nghiệm thu

Đây là danh sách anh chị đưa vào biên bản nghiệm thu, yêu cầu người đại diện đơn vị thi công ký xác nhận từng mục. Văn bản không làm website an toàn hơn, nhưng nó buộc người viết phải thật sự kiểm tra trước khi đặt bút, và nó đặt trách nhiệm về đúng chỗ nếu sau này có sự cố.

  1. Nêu rõ phần nào của hệ thống có sử dụng công cụ AI để sinh mã, và ai là người đã đọc lại, chịu trách nhiệm về toàn bộ phần đó.
  2. Cung cấp danh sách đầy đủ các thư viện và thành phần bên thứ ba kèm số phiên bản, kèm cam kết không có thành phần nào đang dùng phiên bản có lỗ hổng đã được công bố tại thời điểm bàn giao.
  3. Xác nhận không có khoá truy cập, mật khẩu hay chuỗi kết nối cơ sở dữ liệu nào nằm trong mã nguồn, và không có thứ nào trong số đó tải về được từ trình duyệt của khách.
  4. Xác nhận mọi trang và mọi đường dẫn nội bộ đều kiểm tra quyền ở phía máy chủ, không chỉ ẩn nút trên giao diện; kèm danh sách các nhóm quyền và những gì mỗi nhóm được làm.
  5. Xác nhận mọi dữ liệu người dùng nhập đều được kiểm tra và làm sạch ở phía máy chủ, gồm cả biểu mẫu liên hệ, ô tìm kiếm và chức năng tải tệp lên; có giới hạn số lần gửi để chống gửi hàng loạt.
  6. Xác nhận trang lỗi hiển thị cho khách chỉ chứa thông báo chung, không lộ đường dẫn tệp, tên bảng dữ liệu hay phiên bản phần mềm; chi tiết kỹ thuật chỉ lưu trong nhật ký nội bộ có kiểm soát truy cập.
  7. Bàn giao đầy đủ quyền quản trị, tài khoản tên miền và lưu trữ, cơ chế sao lưu tự động cùng một bản khôi phục đã thử thành công ít nhất một lần; kèm đầu mối liên hệ và thời gian phản hồi cam kết khi có sự cố.

Bảy điều này nên nằm cùng chỗ với các điều khoản bàn giao khác, được liệt kê trong bài hợp đồng bàn giao website cần có những gì. Đưa vào hợp đồng từ đầu dễ hơn nhiều so với đàm phán lúc đã thanh toán xong.

Không phải website nào cũng rủi ro như nhau

Cần nói thẳng để anh chị không tiêu tiền sai chỗ. Một website giới thiệu công ty gồm vài trang tĩnh, không có đăng nhập, không lưu dữ liệu khách, thì rủi ro thực tế thấp. Với loại này, chỉ cần kết nối được mã hoá và bản sao lưu chạy đều là đã đủ cho phần lớn tình huống; bài bảo mật website và kết nối mã hoá cho doanh nghiệp vừa và nhỏ nói kỹ phần nền này.

Mức rủi ro tăng lên rõ rệt khi website bắt đầu giữ thứ gì đó có giá trị: cổng đăng nhập cho đại lý, bảng giá riêng theo từng khách, lịch sử đơn hàng, hoặc kết nối hai chiều với hệ thống quản lý khách hàng như mô tả trong bài tích hợp quản lý khách hàng và tự động hoá vào website. Ở nhóm này, bảy điều xác nhận phía trên là mức tối thiểu, không phải mức lý tưởng. Hãy dồn ngân sách kiểm tra vào đúng những phần giữ dữ liệu, thay vì rải đều cho toàn bộ website.

Bảo mật không kết thúc ở ngày bàn giao

Website an toàn ngày bàn giao vẫn có thể mất an toàn sau sáu tháng, vì thế giới bên ngoài thay đổi chứ không phải vì mã nguồn tự hỏng. Lỗ hổng mới được công bố, thư viện cũ đi, nhân sự nghỉ việc mà tài khoản còn nguyên. Vì vậy cần một nếp làm việc tối thiểu: rà soát và cập nhật thư viện theo quý, đối chiếu danh sách tài khoản quản trị mỗi khi có người rời công ty, kiểm tra bản sao lưu bằng cách khôi phục thử ít nhất một lần mỗi năm, và giữ quyền sở hữu tài khoản tên miền lẫn nơi lưu trữ đứng tên doanh nghiệp mình.

Điểm cuối cùng quan trọng hơn vẻ ngoài của nó. Nếu tài khoản tên miền đứng tên đơn vị thi công, thì mọi cam kết bảo mật đều vô nghĩa vào ngày hai bên không còn hợp tác. Bài chọn đơn vị làm website và các dấu hiệu cảnh báo liệt kê những tín hiệu nên nhận ra sớm, trước khi ký chứ không phải sau khi ký.

Bước tiếp theo

Nếu website của anh chị được bàn giao trong hai năm gần đây và có bất kỳ chức năng nào cần đăng nhập, hãy in bảy điều ở mục trên rồi gửi cho đơn vị đang phụ trách, đề nghị họ trả lời từng mục bằng văn bản. Cách làm này không tốn chi phí và thường cho anh chị biết khá rõ mình đang đứng ở đâu chỉ sau một vòng thư từ.

Mahaton Project rà soát bảo mật cho website doanh nghiệp theo đúng danh sách này, đọc lại phần mã do công cụ AI sinh ra và bàn giao báo cáo bằng tiếng Việt để anh chị dùng làm căn cứ yêu cầu khắc phục. Nếu cần một người ngoài đọc giúp trước khi ký nghiệm thu, anh chị nhắn qua Zalo hoặc lochuynh@mahatonproject.com.

Về tác giả

Lộc Tấn Huynh là người sáng lập Mahaton Project — agency digital B2B đã triển khai hàng trăm dự án website, Google Ads và AI cho doanh nghiệp Việt, trong đó có Minh Phát EPS, TAKI Elevator và Viettel. Nguyên tắc làm việc của Mahaton không đổi qua từng dự án: mọi đồng ngân sách marketing đều phải truy ngược được về một kết quả kinh doanh đo đếm được.