Tóm tắt nhanh
- Apiiro, hãng an ninh ứng dụng, khảo sát các nhóm kỹ sư ở doanh nghiệp Fortune 50 và ghi nhận năng suất tăng gấp 4 lần nhưng số lỗi bảo mật tăng gấp 10 lần khi dùng AI viết mã.
- Năm việc nên làm trước khi bắt đầu: ghi yêu cầu bảo mật vào file quy tắc, giữ khoá API ngoài khung chat và ngoài mã nguồn, dặn AI bảo vệ truy vấn dữ liệu, đặt giới hạn tần suất truy cập, rồi kiểm thử kết quả bằng người hoặc công cụ rà quét.
- Khoá API và mật khẩu bị lộ là rủi ro cụ thể nhất: số bí mật viết cứng trong các commit công khai trên GitHub tăng 34% trong năm 2025, theo GitGuardian.
- AI có thể gợi ý thư viện không tồn tại, và kẻ tấn công đăng ký sẵn đúng tên đó để cài mã độc, nên mọi gói lạ cần được kiểm tra trước khi cài.
Thuật ngữ vibe coding bắt nguồn từ bài đăng của Andrej Karpathy, đồng sáng lập OpenAI, kể lại việc ông tạo mã chỉ bằng cách nói chuyện với mô hình AI mà gần như không nhìn vào mã. Karpathy mô tả đó là cách làm vui cho những dự án cuối tuần dùng xong bỏ, nhưng giờ nó đã vào cả môi trường doanh nghiệp, kể cả phần mềm xử lý dữ liệu nhạy cảm, và rủi ro đi kèm cũng đổi tính chất so với lập trình truyền thống.
Các hướng dẫn an toàn mới nhất về vibe coding cùng chỉ về một hướng: vấn đề không nằm ở việc dùng AI, mà ở chỗ không ai đọc lại những gì AI viết. IBM tách vibe coding, tức dựa hoàn toàn vào prompt bằng ngôn ngữ tự nhiên và quên luôn mã, khỏi agentic engineering, nơi lập trình viên có kinh nghiệm dùng công cụ AI một cách có chủ đích. Năm việc dưới đây thực chất là cách kéo người làm vibe coding lại gần cách thứ hai: vẫn để AI gõ mã, nhưng quyền duyệt cuối thuộc về con người.
Con số khiến chuyện này đáng bận tâm là khảo sát của Apiiro trên các nhóm kỹ sư ở doanh nghiệp Fortune 50: năng suất tăng gấp 4 lần, số vấn đề bảo mật tăng gấp 10 lần. IBM dẫn thêm rằng số pull request của các nhóm dùng AI giảm gần một phần ba, nghĩa là ít bản gộp mã hơn nhưng mỗi bản chứa nhiều lỗi hơn. Đây là số liệu của một hãng bán giải pháp an ninh ứng dụng, đo ở quy mô tập đoàn, nên nên đọc như chỉ báo về xu hướng hơn là một hằng số áp được cho dự án cá nhân.
Viết yêu cầu bảo mật thành file quy tắc để AI đọc ở mọi lượt
Mô hình AI hay đi đường tắt: nó giao đúng thứ bạn yêu cầu theo nghĩa đen mà bỏ qua biện pháp an toàn hoặc không kiểm tra lại công việc của mình. Có thể hình dung nó như một vị thần lười, nên đừng mặc định AI sẽ giữ kín thông tin quan trọng, áp dụng thực hành bảo mật tốt hay tự soát mã tìm chỗ khai thác được. Phần yêu cầu cần ghi rõ quyền riêng tư, ai được truy cập phần nào của sản phẩm, có mã hoá hay không, và có thể bảo AI đối chiếu danh sách lỗ hổng phổ biến OWASP ngay từ lúc viết, trước khi dòng mã đầu tiên ra đời.
Để khỏi nhắc lại mỗi lần ngồi vào làm, hầu hết công cụ cho phép tạo quy tắc hoặc ngữ cảnh cố định. Có thể tạo một file markdown (đuôi .md) với bất kỳ mô hình nào, hoặc điền vào mục Knowledge của agent Lovable, mục Memory của Replit; AI sẽ cân nhắc nội dung file ở mỗi prompt và mỗi tác vụ. Nên chọn công cụ có audit log ngay từ đầu để lần lại từng thay đổi trong dự án.
File quy tắc cũng là một bề mặt tấn công. IBM mô tả kiểu rules file backdoor: kẻ tấn công sửa các file quy tắc mã nguồn mở đang phổ biến, nhét chỉ dẫn độc bằng ký tự Unicode ẩn gần như không nhìn thấy được, và chỉ dẫn đó kích hoạt ở mọi phiên viết mã sau khi file bị nhiễm được chấp nhận. Mã sinh ra trông sạch khi review nên khó phát hiện. Vì vậy file quy tắc của người khác chia sẻ trên mạng cần được đọc kỹ như đọc mã, không nên dán nguyên vào dự án.
Giữ khoá API và mật khẩu ngoài khung chat và ngoài mã nguồn
Không bao giờ nên đưa khoá API hay mật khẩu thẳng vào prompt, và cũng không để chúng nằm trong mã, vì khi đẩy mã lên GitHub thì mọi thông tin quan trọng đó ai cũng đọc được. Hạn chế quyền truy cập của công cụ AI cũng giúp giảm nguy cơ bị tấn công prompt injection. Cách làm dễ nhất cho người mới là lưu dữ liệu nhạy cảm trong trình quản lý mật khẩu rồi dùng tab biến môi trường hoặc Secrets có sẵn trên Replit, Lovable hay Vercel.
Công cụ không có tính năng đó thì phải tự tạo file .env ở phía backend, thêm nó vào .gitignore và bảo đảm nó không bao giờ hiện ra ở giao diện người dùng. Để kiểm tra đã làm đúng chưa, có thể chạy TruffleHog, công cụ quét mã để phát hiện thông tin nhạy cảm vô tình bị lộ.
Số liệu GitGuardian do IBM trích cho thấy vì sao bước này không nên làm qua loa: số bí mật như mật khẩu và khoá API bị viết cứng trong các commit công khai trên GitHub tăng 34% trong năm 2025, mức tăng một năm lớn nhất từng ghi nhận, và các commit có Claude Code hỗ trợ lộ bí mật nhiều gấp hơn hai lần commit hoàn toàn do người viết. Phần đáng ngại hơn là chuyện xử lý sau đó: 64% thông tin xác thực hợp lệ được ghi nhận từ năm 2022 vẫn chưa bị thu hồi vào tháng 1/2026, và Football Australia để lộ khoá truy cập AWS trong mã nguồn website suốt hơn 700 ngày. Từ đó có thể rút ra rằng khoá đã lộ thì phải thu hồi và cấp khoá mới, chứ xoá dòng mã chứa nó chưa đủ.
Dặn AI bảo vệ dữ liệu và kiểm tra từng thư viện nó đề xuất
Ứng dụng xử lý nhiều dữ liệu thường dùng SQL, và cơ sở dữ liệu SQL có lỗ hổng sẽ dẫn đến tấn công SQL injection, cho phép kẻ xấu lấy cắp hoặc xoá dữ liệu rồi thay bằng nội dung tuỳ ý. Nên yêu cầu AI tham số hoá truy vấn, làm sạch dữ liệu người dùng nhập, dùng Server Actions cho các thao tác quan trọng, bật row-level security (RLS) và tạo chính sách RLS khi phù hợp. Mỗi biện pháp làm mã khó bị khai thác hơn, và AI cũng nên được dặn dùng phiên bản mới nhất của các thư viện hiện có.
Điểm dễ bị bỏ sót là chính thư viện. AI từng bịa ra những gói không tồn tại, hoặc vô tình dùng gói độc hại. IBM gọi kiểu tấn công khai thác điều này là slopsquatting: tên gói ảo thường lặp lại giữa các tình huống và cả giữa các mô hình, kẻ tấn công theo dõi những tên đó rồi đăng ký trước trên kho công khai. Người làm vibe coding thường chưa quen thư viện phổ biến nên khó nhận ra gói giả, và khi commit mã chứa tên đó họ cài mã độc mà không biết. Trước khi cài một gói lạ, nên mở trang gói trên kho chính thức, xem ngày tạo, lượt tải và liên kết tới mã nguồn, thay vì cứ chạy lệnh cài AI đưa ra.
Giới hạn số lần gọi để chặn tấn công và giữ hoá đơn token
Rate limiting giới hạn số lần một người, hoặc một con bot, được thực hiện một thao tác cụ thể. Nó là một cách giảm nguy cơ rơi vào tấn công DDoS, và nếu áp cho việc thử mật khẩu thì cản được brute-force lẫn credential stuffing. Mức giới hạn phụ thuộc ứng dụng làm gì: với app miễn phí như chatbot hỗ trợ, trần token mỗi người dùng mỗi ngày có thể bảo vệ tài khoản ngân hàng của chủ app, vì chi phí gọi mô hình do chủ app trả.
Nên giới hạn theo ID tài khoản trước rồi mới đến địa chỉ IP, để kẻ xấu không spam dễ dàng và để giới hạn không bị lách bằng VPN. Luồng xác thực qua email hoặc số điện thoại và CAPTCHA là hai lớp nữa có thể thêm để chặn hành vi không mong muốn.
Kiểm thử bằng người, bằng mô hình khác và bằng công cụ rà quét
Nếu không thuê được kỹ sư phần mềm chuyên nghiệp xem lại dự án, cách tối thiểu là yêu cầu chính AI đánh giá mã của nó để tìm chỗ bị khai thác, kể cả đối chiếu với OWASP Top 10 dù trước đó đã nhắc, sau đó dùng một mô hình khác tìm lỗi tiếp. Các công cụ đánh giá dự án vibe coding gồm Claude Code Security, Codex Security, Wingman của Stackhawk, CheckVibe, SafeToShip và Vibe App Scanner. Việc dọn lỗi cũng không dừng khi ứng dụng lên mạng, vì sản phẩm cần được theo dõi liên tục sau đó.
Quy mô mỗi lần thay đổi quyết định việc rà soát có hiệu quả hay không. Báo cáo Developer Habits mùa xuân 2026 của Cursor ghi số dòng mã trung bình trên mỗi pull request tăng khoảng 250% so với năm trước, còn các pull request lớn từ 1.000 dòng trở lên tăng từ 8% tổng số vào tháng 1/2025 lên 13,9% vào tháng 5/2026. Lỗi nằm trong một bản gộp rộng sẽ khó thấy hơn nhiều so với bản nhỏ nhắm vào một phần, nên IBM khuyến nghị đặt quy định về kích cỡ pull request và coi mã do AI sinh ra như nguồn chưa đáng tin, phải qua kiểm tra mã tĩnh (SAST) trước khi vào kho chính.
Người làm một mình hay nhóm nhỏ nên ưu tiên khoá API và giới hạn truy cập trước
Phần lớn khảo sát nói trên đo ở quy mô doanh nghiệp, còn người dựng ứng dụng bằng vibe coding ở Việt Nam nhiều khả năng là cá nhân hoặc nhóm vài người, không có ai chuyên trách bảo mật. Với hoàn cảnh đó, hai việc về khoá API và giới hạn truy cập nên làm trước, vì thiệt hại của chúng đến bằng tiền và đến nhanh: khoá dịch vụ AI bị lộ hoặc một chatbot miễn phí bị gọi không giới hạn sẽ làm hoá đơn tăng trước khi bạn kịp nhận ra có sự cố. Lỗi truy vấn dữ liệu nguy hiểm không kém, nhưng nó có thể nằm im đến khi có người cố tình khai thác, nên được xếp ngay sau.
Trước khi đưa bất kỳ ứng dụng nào lên mạng, danh sách tối thiểu có thể gói trong sáu dòng:
- File quy tắc đã ghi yêu cầu bảo mật và tham chiếu OWASP.
- File .env nằm trong .gitignore, TruffleHog đã quét sạch.
- Mọi thư viện lạ đã được kiểm tra trên kho chính thức.
- Truy vấn đã tham số hoá, RLS đã bật nếu dùng cơ sở dữ liệu có hỗ trợ.
- Giới hạn tần suất đặt theo tài khoản trước, theo IP sau.
- Đã chạy ít nhất một công cụ rà quét và có cách theo dõi sau khi chạy thật.
Việc còn bỏ ngỏ nằm ở khâu kiểm tra thư viện: IBM lưu ý mỗi phiên bản mô hình mới có thể sinh ra kiểu ảo giác gói khác, nên bước này phải được làm lại ở từng dự án và sau mỗi lần đổi mô hình, chứ không phải xong một lần là yên tâm.
