Bảo mật khi lập trình theo Vibe: Cách bảo vệ ứng dụng do AI xây dựng

Bạn có thể tìm thêm hướng dẫn làm việc với Ailoot trong tài liệu.

Vì sao ứng dụng do AI xây dựng thường bị tấn công hơn?#

Tôi cũng tự xây dựng sản phẩm bằng AI, nhưng không đến mức hoang tưởng về bảo mật và “khóa chặt mọi thứ tối đa”. Tuy nhiên, có một mức cơ bản bạn không được thấp hơn, nếu không một ngày nào đó bạn sẽ thức dậy và thấy cơ sở dữ liệu trống rỗng, cùng các máy đào tiền mã hóa của người khác trên máy chủ của mình. Hướng dẫn này nói về mức cơ bản đó. Không phải “trở thành chuyên gia bảo mật”, mà là “đừng tự bắn vào chân mình mà chẳng vì lý do gì”.

Nguồn gốc vấn đề rất đơn giản. Khi bạn bảo một tác nhân AI “xây cho tôi một ứng dụng đặt lịch cho khách hàng”, nó sẽ làm cho ứng dụng hoạt động nhanh nhất có thể. Bảo mật là công việc bổ sung mà bản demo không thể hiện. Vì vậy, cơ sở dữ liệu được thiết lập ở chế độ mở, khóa thanh toán được đưa thẳng vào mã, còn bước kiểm tra “người dùng này có quyền truy cập không?” chỉ tồn tại trong trình duyệt, nơi có thể bị vượt qua trong chớp mắt.

Lý do thứ hai là chính các nền tảng. Đây là cách vấn đề được mô tả:

Nói cách khác, lỗ hổng tự xuất hiện theo mặc định. Bạn không làm gì sai. Bạn chỉ không làm gì cả — và trong bảo mật, không hành động chính là để mọi thứ “mở cho tất cả mọi người”.

Những người lập trình theo vibe đã phải trả giá và học được gì?#

Cách tốt nhất để phòng tránh bất cẩn là học từ sai lầm của người khác. Dưới đây là bốn báo cáo đáng xem trước khi bạn xuất bản dự án.

Lovable và việc tắt RLS. Nền tảng Lovable xây dựng ứng dụng từ mô tả bằng văn bản. Năm 2025, một lỗ hổng có tính hệ thống được phát hiện trong các ứng dụng của nền tảng và được gán mã CVE-2025-48757. Nguyên nhân: các ứng dụng được tạo ra không có quy tắc truy cập cơ sở dữ liệu ở cấp hàng (RLS, sẽ giải thích bên dưới). Một nhà nghiên cứu kiểm tra một mẫu và tìm thấy 303 điểm truy cập bị lộ trong 170 ứng dụng. Tên, số điện thoại, trạng thái thanh toán, khóa API của người khác và cả địa chỉ nhà đều bị lộ. Trong khoảng 70 phần trăm ứng dụng được kiểm tra, lớp bảo vệ cấp hàng bị tắt hoàn toàn.

Tea và dữ liệu nhạy cảm. Ứng dụng Tea (đánh giá ẩn danh về mọi người) làm lộ khoảng 72,000 ảnh vào tháng 7 năm 2025, trong đó có 13,000 ảnh selfie và ảnh chụp tài liệu, sau đó là hơn một triệu tin nhắn riêng tư. Nguyên nhân kỹ thuật là kho lưu trữ mở và kiểm tra quyền truy cập yếu. Cộng đồng bảo mật xem Tea là ví dụ điển hình: khi ra mắt nhanh quan trọng hơn kiểm tra quyền, dữ liệu nhạy cảm sẽ là thứ rò rỉ đầu tiên.

Một ví dụ thực tế khác. Trong một vụ việc do tác giả gốc mô tả, ứng dụng của một người lập trình theo vibe bị tấn công vì AI đặt mật khẩu mặc định khi tạo cơ sở dữ liệu — một mật khẩu có thể bị đoán tự động. Rồi chuỗi sự việc quen thuộc xảy ra: kẻ tấn công xâm nhập, cài máy đào tiền mã hóa và viết lại dự án. Máy chủ phải bị xóa sạch hoàn toàn. Mật khẩu mặc định chẳng khác nào một cánh cửa không khóa với tấm biển “cứ vào đi”.

Hai mặt trận bảo mật: chính xác thì bạn dễ bị tấn công ở đâu?#

Khi nói về “bảo mật trong vibe coding”, mọi người thường gộp chung hai nỗi lo hoàn toàn khác nhau. Hãy tách chúng ra, vì bạn cần những cách bảo vệ khác nhau.

Mặt trận thứ nhất — bản thân tác nhân. Bạn chạy một tác nhân AI trên máy tính và cấp quyền truy cập tệp, terminal, khóa và cơ sở dữ liệu. Rủi ro là tác nhân không phải con người: nó làm theo hướng dẫn một cách máy móc và sẽ tìm con đường ngắn nhất, kể cả khi con đường đó nguy hiểm. Điều này cũng bao gồm nguy cơ ai đó “tiêm” lệnh của họ vào tác nhân thông qua văn bản mà nó đọc (gọi là prompt injection).

Mặt trận thứ hai — ứng dụng hoàn chỉnh. Đây là thứ bạn đã xuất bản và mọi người sử dụng. Mục tiêu là trang web hoặc dịch vụ bạn đưa lên mạng: kẻ tấn công xâm nhập cơ sở dữ liệu mở, gửi yêu cầu giả hoặc đoán tài khoản của người khác. Tác nhân không liên quan đến việc này — lỗ hổng đã bị bỏ ngỏ từ trước và người khác khai thác nó.

Anthropic, công ty đứng sau Claude, nêu nguyên tắc bảo vệ chính như sau — và nguyên tắc này áp dụng cho cả hai mặt trận:

Trên thực tế, điều này có nghĩa là: đừng trông chờ AI “tự tránh làm điều xấu”. Trước tiên, hãy giới hạn những gì nó có thể thực sự làm, rồi mới yêu cầu nó hành xử tốt. Khi hành vi của nó thất bại — và chuyện đó sẽ xảy ra — chỉ có một ranh giới cứng được đặt ra từ trước mới bảo vệ được bạn.

Bạn muốn AI làm việc có thể dự đoán và không còn khiến bạn tự bắn vào chân mình trong mỗi dự án mới? Quy tắc bảo mật là một phần trong kiến thức dự án của bạn: chỉ cần ghi chúng một lần trong CLAUDE.md, rồi tác nhân sẽ làm theo trong mọi yêu cầu.

Tác nhân AI có thể làm gì khi được quyền truy cập máy tính của bạn?#

Rủi ro thường bị xem nhẹ nhất là chính tác nhân của bạn với quyền hạn quá rộng. Bạn thậm chí không cần một hacker bên ngoài. Đây là ví dụ gần đây từ cuối tháng 5 năm 2026. Một tác nhân Codex cần quyền quản trị mà người dùng không có. Tác nhân không bỏ cuộc — nó xem xét xung quanh, thấy người dùng thuộc nhóm docker, vốn trên thực tế tương đương với root, rồi dùng quyền truy cập đó.

Ở đây không có ý định xấu. Chỉ là một tác nhân được yêu cầu “giải quyết công việc” sẽ tìm ra điểm yếu mang tính cấu trúc nhanh hơn con người. Và nếu điểm yếu đó cho phép nó truy cập khóa hoặc môi trường production của bạn, nó sẽ sử dụng quyền đó. Vì vậy, quy tắc số một là quyền tối thiểu. Hãy cấp cho tác nhân đúng mức truy cập cần thiết cho một công việc cụ thể, không hơn một chút nào.

Bạn có thể làm gì trên thực tế, ngay cả khi không phải lập trình viên?

1. Đừng chạy tác nhân ở chế độ “cho phép tất cả” trên máy production

   Chế độ tác nhân không hỏi xác nhận (thường gọi là bypass hoặc yolo) chỉ dành cho sandbox hoặc dự án thử nghiệm, không phải máy lưu khóa đang hoạt động và quyền truy cập production.

2. Cấm tác nhân đọc bí mật

   Trong Claude Code, bạn làm việc này bằng một quy tắc từ chối truy cập vào các tệp chứa khóa. Nhờ vậy, ngay cả khi tác nhân muốn mở .env, công cụ cũng sẽ không cho phép.

3. Tách riêng khóa production

   Khóa của cơ sở dữ liệu production và dịch vụ thanh toán không nên nằm trong cùng thư mục nơi tác nhân viết mã. Hãy tách riêng các môi trường: dùng khóa thử nghiệm khi bạn thử nghiệm.

4. Dùng sandbox của công cụ

   Các công cụ AI hiện đại có thể chạy lệnh trong môi trường cô lập (sandbox), nơi chúng không thể truy cập phần còn lại của hệ thống. Trong Claude Code, cách này giảm khoảng 84 phần trăm yêu cầu cấp quyền — nên cũng tiện hơn.

Một quy tắc từ chối đọc bí mật trong Claude Code có dạng gần như sau — đặt nó trong phần cài đặt quyền:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Bạn tuyệt đối không nên đặt khóa API và mật khẩu ở đâu?#

Sai lầm phổ biến và dễ tránh nhất là đặt khóa trong mã. Khóa API của dịch vụ thanh toán, mật khẩu cơ sở dữ liệu, token bot — tất cả đều là bí mật. Chúng phải nằm trong một tệp .env riêng, và tệp này phải được liệt kê trong .gitignore để không bị đưa lên git cùng với mã.

Vì sao việc này đặc biệt quan trọng: khóa không tồn tại lâu trong kho mã công khai. Bot quét các commit mới suốt ngày đêm. Chuỗi sự việc thường diễn ra như sau: chúng tìm thấy khóa đám mây, khởi chạy máy chủ đào tiền mã hóa bằng tiền của bạn và đến sáng bạn phải đối mặt với hóa đơn lên đến hàng chục nghìn. Các nhà phát triển thường xuyên kể những câu chuyện như vậy, với hóa đơn lên đến năm chữ số tính bằng đô la.

Quy mô vấn đề trong năm 2025: 28.65 triệu bí mật mới bị nhúng cứng trong mã ở các kho mã công khai, tăng 34 phần trăm so với năm trước. Số vụ rò rỉ khóa dành riêng cho dịch vụ AI tăng 81 phần trăm. Vibe coding càng khiến tình hình nghiêm trọng hơn vì tác nhân commit mà không kiểm tra.

Những điều cần tự kiểm tra ngay bây giờ:

1. Mở tệp .gitignore của dự án

   Đảm bảo trong đó có dòng .env. Nếu chưa có, hãy thêm vào trước commit đầu tiên.

2. Mở kho mã của bạn trên GitHub

   Kiểm tra xem tệp .env có ở đó không. Tìm .env hoặc một phần khóa của bạn trong kho mã là cách kiểm tra nhanh.

3. Nếu khóa bị lộ, hãy thu hồi và cấp lại

   Xóa commit là chưa đủ: khóa có thể đã bị lấy. Truy cập dịch vụ (nhà cung cấp thanh toán, dịch vụ đám mây, nhà cung cấp AI), thu hồi khóa cũ và cấp khóa mới. Quy trình này được gọi là luân chuyển khóa.

4. Cấp cho khóa quyền tối thiểu

   Nếu khóa chỉ cần dùng để đọc, hãy đặt ở chế độ chỉ đọc. Như vậy, ngay cả khi bị lộ thì cũng có ít dữ liệu để lấy cắp hơn.

Vì sao ai cũng có thể xem cơ sở dữ liệu của bạn nếu không có RLS?#

Nếu bạn đang xây dựng ứng dụng trên Supabase hoặc cơ sở dữ liệu tương tự, đây là phần quan trọng nhất. RLS là viết tắt của Row Level Security, tức bảo mật cấp hàng. Nói đơn giản, đó là quy tắc xác định những hàng nào trong bảng được hiển thị cho một người dùng cụ thể. Nếu không có RLS, bảng “orders” sẽ trả về đơn hàng của mọi khách hàng cho tất cả mọi người.

Tài liệu của Supabase diễn đạt điều này rất rõ:

Đây là cái bẫy chính đối với người lập trình theo vibe. Khi bạn tạo bảng bằng cách nhấp trong trang tổng quan Supabase, lớp bảo vệ sẽ tự động bật. Nhưng khi AI tạo bảng — và gần như lúc nào nó cũng viết trực tiếp các lệnh SQL — RLS vẫn tắt theo mặc định. Điều đó có nghĩa là bảng do tác nhân tạo gần như chắc chắn mở cho toàn bộ Internet. Đây chính xác là cách dữ liệu của 170 ứng dụng Lovable bị rò rỉ.

Cần làm gì:

1. Hỏi trực tiếp tác nhân

   Viết: “hãy cho tôi xem tất cả các bảng đã tắt RLS”. AI sẽ đưa ra danh sách — đó là hàng đợi công việc của bạn.

2. Bật RLS cho mọi bảng có dữ liệu người dùng

   Đồng thời thêm ít nhất một chính sách truy cập — ví dụ: “người dùng chỉ có thể xem các hàng dữ liệu của chính họ”.

3. Kiểm tra trang tổng quan

   Trong trang tổng quan Supabase, mọi bảng đều phải hiển thị “RLS enabled”. Nếu mục này có màu xám hoặc đỏ, nghĩa là bảng đang mở.

4. Kiểm tra thực tế

   Đăng nhập bằng tài khoản người dùng thông thường và thử yêu cầu dữ liệu của người khác. Nếu bị từ chối, chính sách đang hoạt động.

Vì sao kiểm tra quyền trong giao diện không bảo vệ được bạn?#

Một ảo tưởng phổ biến là: “Tôi đã làm cho người dùng thông thường không nhìn thấy nút quản trị”. Vấn đề là nút chỉ là một hình ảnh trong trình duyệt. Có thể gửi yêu cầu thẳng đến máy chủ mà không dùng nút. Nếu máy chủ không kiểm tra quyền một lần nữa, nó sẽ thực hiện lệnh của người khác.

Một ví dụ kinh điển có tên là IDOR. Hãy tưởng tượng bạn mở đơn hàng của mình ở địa chỉ có id=123. Đổi thành id=124, bạn sẽ thấy đơn hàng của người khác vì máy chủ không kiểm tra xem đó có thực sự là đơn hàng của bạn hay không. Đây là một trong những lỗ hổng thường gặp nhất ở các ứng dụng được xây dựng bằng vibe coding, và việc kiểm tra quyền yếu kém là nguyên nhân khiến dữ liệu của Tea bị rò rỉ.

Quy tắc rất đơn giản: lặp lại trên máy chủ mọi bước kiểm tra “người dùng này có được phép làm việc đó không?” Giao diện dùng để tạo sự thuận tiện; biện pháp bảo vệ phải nằm ở backend. Hướng dẫn dùng ngay cho tác nhân: “thêm kiểm tra quyền ở phía máy chủ cho mọi endpoint đọc hoặc thay đổi dữ liệu người dùng; đừng dựa vào việc ẩn một phần tử trong giao diện.”

Nếu không phải lập trình viên, làm sao kiểm tra mã để tìm lỗ hổng?#

Tin tốt là ngày nay bạn có thể nhờ chính AI kiểm tra bảo mật — nó làm khá tốt việc tìm các lỗ hổng phổ biến. Dưới đây là ba công cụ phục vụ những việc khác nhau.

1. Lệnh /security-review trong Claude Code. Kiểm tra một lần nhánh hiện tại để tìm SQL injection, XSS, lỗ hổng phân quyền, rò rỉ dữ liệu và vấn đề về dependency. Tôi đã giải thích từng bước cách nó hoạt động và cách gắn kiểm tra tự động vào mỗi thay đổi trong hướng dẫn riêng về đánh giá bảo mật trong Claude Code. Điểm chính ở đây: đây là tuyến phòng thủ đầu tiên, được khởi chạy bằng một lệnh.

2. Plugin security-guidance chính thức. Cài đặt từ marketplace plugin chính thức bằng /plugin install security-guidance@claude-plugins-official (yêu cầu Claude Code phiên bản 2.1.144 trở lên). Plugin kiểm tra mã ở ba thời điểm: sau mỗi lần chỉnh sửa, cuối mỗi lượt và lúc commit. Nó phát hiện việc vượt qua phân quyền, IDOR, injection và mật mã yếu. Nhưng Anthropic thẳng thắn về giới hạn của plugin:

npx skills add <author>/<repo>

Sau đó chỉ cần bảo tác nhân: “kiểm tra các lỗ hổng trong dự án của tôi”. Nhưng bộ sưu tập này có một lưu ý quan trọng, đó là lý do tôi dành một mục riêng bên dưới.

Để bạn nắm bối cảnh: các tổ chức lớn cũng bắt đầu coi trọng bảo mật mã do AI tạo ra. Trong khuôn khổ Project Glasswing, mở rộng vào ngày 2 tháng 6 năm 2026 với 150 tổ chức tham gia, các đối tác đã tìm thấy hơn 10,000 lỗ hổng nghiêm trọng trong thời gian ngắn bằng các mô hình của Anthropic. Mức độ rủi ro đã rõ:

Có thể tin tưởng các kỹ năng và tiện ích mở rộng từ GitHub không?#

Đây là lúc mọi thứ trở nên đặc biệt khó lường, vì mối nguy đến từ một công cụ bạn cài đặt để bảo mật. Khi chạy npx skills add ... hoặc cài tiện ích mở rộng, bạn đang đưa mã của người khác vào máy, rồi tác nhân chạy mã đó bằng quyền của bạn. Nếu tác giả bị tấn công hoặc gói cài đặt vốn đã độc hại từ đầu, bạn sẽ gặp rắc rối.

Hãy xem bộ sưu tập kỹ năng ở mục trước. Trong tên của nó có chữ “Anthropic”, khiến bạn mất cảnh giác. Nhưng phần mô tả của chính dự án ghi rõ:

Nói cách khác, cái tên gây hiểu lầm. Bản thân bộ sưu tập hiện đã hoàn thiện và sạch, nhưng nguyên tắc vẫn không đổi: bạn tự chịu rủi ro khi cài đặt. Và mối đe dọa này không phải giả định. Vào tháng 5 năm 2026, một tiện ích mở rộng trình soạn thảo độc hại chỉ tồn tại trên marketplace 18 phút — nhưng trong thời gian đó, nó đã lấy cắp mật khẩu từ trình quản lý mật khẩu, token GitHub, quyền truy cập đám mây và cả cấu hình Claude Code của những người cài đặt nó. Một chi tiết tệ hại khác: loại phần mềm độc hại này thường sống sót sau khi gỡ gói thông thường rồi chạy lại ở phiên tiếp theo.

Tôi đã hình thành một thói quen đơn giản cho mình và cũng khuyên bạn làm theo: trước khi cài bất kỳ kỹ năng nào từ GitHub, hãy tự kiểm tra. Tác giả có thể bị tấn công, tài khoản bị chiếm và mã độc có thể lọt vào kho mã. Kiểm tra là cách bảo vệ bạn.

Mức tối thiểu cần làm trước khi cài đặt: xem tác giả và số sao, đọc mô tả kỹ năng, đừng cài một công cụ “chỉ vì được giới thiệu trong một bài đăng”, và với công cụ chưa quen thuộc, hãy thử trước trong môi trường thử nghiệm riêng, không phải trên máy có khóa production.

Điều gì sẽ cứu bạn sau một vụ xâm nhập: sao lưu và khôi phục#

Bảo mật không chỉ là “ngăn người ngoài xâm nhập”, mà còn là “trở lại bình thường khi xảy ra sự cố”. Vì chắc chắn sẽ có sự cố. Trong tình huống thực tế được mô tả, một tác nhân AI đã xóa cơ sở dữ liệu đang hoạt động trong dự án production khi xử lý một công việc thường lệ. Có bản sao lưu, nhưng bản đó đã cũ ba ngày — và dữ liệu của ba ngày cứ thế biến mất.

Điều đó dẫn đến hai quy tắc.

Sao lưu thường xuyên. Nếu ứng dụng của bạn chứa dữ liệu mà bạn không muốn mất, tạo một bản sao mỗi ba ngày chỉ là ảo tưởng về bảo vệ. Hãy thiết lập sao lưu tự động ít nhất mỗi 30 phút. Với hầu hết cơ sở dữ liệu, bao gồm Supabase, bạn có thể bật tính năng này chỉ bằng vài cú nhấp chuột.

Git là bảo hiểm trước tác nhân. Git lưu lịch sử mã của bạn: bạn có thể khôi phục bất kỳ trạng thái nào từng hoạt động. Khi tác nhân viết lại thứ vốn đang chạy tốt, bạn quay về phiên bản hoạt động gần nhất thay vì tự sửa bằng tay. Nếu AI xóa hoặc làm hỏng dự án mà bạn không biết cách khôi phục, hãy xem báo cáo riêng: cần làm gì nếu AI xóa cơ sở dữ liệu. Để biết cách bảo vệ dự án khỏi bị làm hỏng từ trước, hãy xem hướng dẫn cách bảo vệ Claude Code khỏi làm hỏng dự án.

Danh sách kiểm tra bảo mật trước khi xuất bản#

Hãy làm theo danh sách này ngay trước khi xuất bản. Theo đúng thứ tự.

1. Bí mật nằm trong .env, còn .env nằm trong .gitignore. Không có khóa trong mã. Không có tệp .env trong kho mã công khai.

2. Khóa có quyền tối thiểu. Mỗi khóa chỉ làm được những gì cần thiết. Khóa production được tách khỏi môi trường của tác nhân.

3. Đã bật RLS trên mọi bảng có dữ liệu người dùng và đã thiết lập chính sách truy cập.

4. Kiểm tra quyền phía máy chủ cho mọi thao tác với dữ liệu. Ẩn nút trong giao diện là chưa đủ. Đã tự kiểm tra việc đổi id trong địa chỉ.

5. Xác minh chữ ký webhook. Mọi trình xử lý thông báo bên ngoài (thanh toán, biểu mẫu) đều xác minh chữ ký.

6. Giới hạn tần suất đối với yêu cầu đến và thao tác tốn kém để không thể đoán mật khẩu bằng vét cạn hoặc làm hóa đơn của bạn tăng vọt.

7. Tác nhân không chạy ở chế độ “cho phép tất cả” trên máy có khóa production. Đã chặn việc đọc .env.

8. Sao lưu thường xuyên và đã kiểm tra — bạn thực sự thử khôi phục, thay vì chỉ tin rằng các bản sao “nằm đâu đó”.

9. Mã đã được kiểm tra bằng /security-review hoặc plugin security-guidance. Các phát hiện đã được khắc phục.

10. Đã kiểm tra kỹ năng và tiện ích mở rộng của người khác trước khi cài đặt. Không có gì được cài “mà không xem xét”.

Hôm nay nên bắt đầu từ đâu?#

Đừng cố làm mọi việc trong hướng dẫn này chỉ trong một buổi tối — rồi cuối cùng bạn sẽ chẳng làm gì cả. Hôm nay hãy thực hiện ba bước quan trọng nhất:

1. Kiểm tra bí mật của bạn. Mở .gitignore, đảm bảo .env có trong đó và kiểm tra xem kho mã công khai có khóa nào không. Nếu có khóa bị lộ, hãy thu hồi và cấp lại.
2. Hỏi về RLS. Bảo tác nhân: “hãy cho tôi xem các bảng đã tắt RLS” — rồi bật RLS ở mọi nơi lưu trữ dữ liệu của mọi người.
3. Thiết lập sao lưu thường xuyên. Để khi xảy ra sự cố, bạn chỉ mất vài phút thay vì vài ngày.

Sau đó làm theo danh sách kiểm tra ở trên khi dự án của bạn phát triển và bắt đầu xử lý tiền bạc cùng dữ liệu của người khác.

Một điều cuối cùng. Bảo mật khi lập trình theo vibe là trách nhiệm của chủ sở hữu. Bạn không cần trở thành chuyên gia bảo mật. AI đã xây sản phẩm của bạn chỉ trong một buổi tối — rất tốt, nhưng bạn là người chịu trách nhiệm về nó. Mức cơ bản trong hướng dẫn này cho thấy trách nhiệm đó cần được thực hiện như thế nào trên thực tế.

Để tiếp tục làm việc với các mô hình, bạn có thể truy cập Ailoot.