Cách Bảo Mật Code Được Tạo Bởi AI — Danh Sách Kiểm Tra Bảo Mật Vibe Coding

Nếu bạn đã code một ứng dụng với Claude hay Cursor và sắp bàn giao nó cho khách hàng, hãy dừng lại. Code do AI tạo ra thường chứa những lỗ hổng bảo mật dễ đoán — API keys để lộ, thiếu xác thực đầu vào, quyền cơ sở dữ liệu mặc định khiến bất kỳ người dùng nào cũng có thể xem dữ liệu của những người khác. Những vấn đề này không phải trường hợp riêng lẻ. Chúng xảy ra ở hầu hết mọi lần tạo code đầu tiên bằng AI.

Hướng dẫn này là danh sách kiểm tra bảo mật trước khi ra mắt. Làm theo từng bước trước khi bất kỳ người dùng thực tế nào sử dụng ứng dụng của bạn. Nó được viết cho ngăn xếp vibe coding phổ biến nhất (Next.js + Supabase + Vercel), nhưng các nguyên tắc áp dụng bất kể bạn sử dụng công cụ nào.

Tại sao Code Được Tạo bởi AI Có Vấn đề Bảo mật

Các mô hình AI tối ưu hóa cho "nó có hoạt động không?" chứ không phải "nó có an toàn không?" Khi bạn bảo Claude "hãy tạo cho tôi một trình quản lý tác vụ có tài khoản người dùng," nó sẽ tạo code để tạo người dùng, lưu trữ tác vụ và hiển thị chúng. Những gì nó có thể sẽ không làm tự động: đảm bảo Người dùng A không thể xem tác vụ của Người dùng B, xác thực rằng các trường đầu vào không thể chấp nhận các kịch bản độc hại, ẩn API keys của bạn khỏi công cụ phát triển của trình duyệt, hoặc thêm giới hạn tần suất để ngăn ai đó tấn công các điểm cuối của bạn.

Đây không phải là thất bại của AI — đó là những khoảng trống trong lời nhắc của bạn. AI xây dựng những gì bạn yêu cầu. Bạn có thể không yêu cầu bảo mật vì bạn đang tập trung vào các tính năng. Bây giờ là lúc quay lại và thêm nó vào.

Bước 1: Kiểm tra Các Biến Môi trường của Bạn

Đây là lỗi phổ biến nhất và nguy hiểm nhất trong các ứng dụng vibe-coded. Kiểm tra mỗi tệp trong dự án của bạn để tìm API keys, URL cơ sở dữ liệu hoặc bí mật được mã hóa cứng.

Những gì cần tìm: Tìm kiếm trong mã nguồn của bạn các chuỗi bắt đầu với sk-, eyJ, sbp_, supabase, postgres://, hoặc bất kỳ chuỗi dài ngẫu nhiên nào. Kiểm tra những tệp này cụ thể: bất kỳ tệp nào trong thư mục /app hoặc /pages của bạn, bất kỳ tệp thành phần nào, next.config.js của bạn, và bất kỳ tệp tiện ích nào.

Cách sửa: Di chuyển mọi bí mật vào các biến môi trường. Trong Next.js, chỉ các biến có tiền tố NEXT_PUBLIC_ được công khai cho trình duyệt. URL cơ sở dữ liệu, khóa vai trò dịch vụ và bí mật API của bạn không bao giờ nên có tiền tố này.

# .env.local (KHÔNG BAO GIỜ commit tệp này)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Những cái này được phép công khai cho trình duyệt:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Xác minh: Kiểm tra tệp .gitignore của bạn bao gồm .env.local. Nếu bạn đã commit bí mật vào Git, chúng sẽ nằm trong lịch sử của bạn ngay cả sau khi xóa — xoay vòng (tạo lại) mọi khóa được công khai ngay lập tức.

Bước 2: Bật Bảo mật Cấp Hàng trong Supabase

Đây là bước quan trọng nhất nếu bạn đang sử dụng Supabase. Theo mặc định, các bảng Supabase không có hạn chế truy cập — bất kỳ ai có khóa anon của bạn đều có thể đọc và ghi mọi hàng trong mọi bảng. Điều này có nghĩa là Người dùng A có thể xem dữ liệu của Người dùng B bằng một lệnh gọi API đơn giản.

Cách sửa: Bật Row-Level Security (RLS) trên mọi bảng, sau đó tạo các chính sách hạn chế truy cập.

Đi tới bảng điều khiển Supabase của bạn → Table Editor → chọn mỗi bảng → nhấp vào "RLS Disabled" để bật nó. Sau đó thêm các chính sách:

Đối với một ứng dụng điển hình trong đó người dùng chỉ nên thấy dữ liệu của riêng họ, hãy tạo chính sách SELECT: auth.uid() = user_id. Tạo các chính sách tương tự cho INSERT, UPDATE và DELETE.

Kiểm tra nó: Đăng nhập dưới dạng Người dùng A, cố gắng truy cập dữ liệu của Người dùng B thông qua API. Nếu bạn có thể thấy nó, các chính sách của bạn không đúng. Supabase có một trình soạn SQL nơi bạn có thể kiểm tra các chính sách trực tiếp.

Lỗi AI phổ biến: Claude thường tạo các truy vấn Supabase bằng cách sử dụng khóa service_role (bỏ qua RLS) thay vì khóa anon với các chính sách RLS thích hợp. Kiểm tra rằng mã phía khách hàng của bạn chỉ sử dụng khóa anon. Khóa vai trò dịch vụ chỉ nên tồn tại trong mã phía máy chủ (API routes, server actions) và không bao giờ được công khai cho trình duyệt.

Bước 3: Thêm Xác thực Đúng cách

Code xác thực do AI tạo ra thường hoạt động nhưng có những phím tắt. Kiểm tra những vấn đề cụ thể này:

Quản lý phiên: Đảm bảo rằng các phiên hết hạn. Kiểm tra rằng thiết lập xác thực của bạn bao gồm thời gian chờ phiên hợp lý (các mặc định của Supabase thường ổn, nhưng hãy xác minh). Đảm bảo rằng đăng xuất thực sự làm mất hiệu lực phiên, không chỉ xóa cookie cục bộ.

Yêu cầu mật khẩu: Nếu bạn có xác thực email/mật khẩu, hãy thực thi độ dài mật khẩu tối thiểu (8+ ký tự). Supabase xử lý điều này trong cài đặt dự án của bạn → Authentication → Password Requirements.

Các tuyến đường được bảo vệ: Mọi trang hiển thị dữ liệu dành riêng cho người dùng đều cần phải có phần mềm trung gian xác thực. Trong Next.js App Router, tạo một phần mềm trung gian kiểm tra phiên hợp lệ và chuyển hướng người dùng chưa xác thực đến trang đăng nhập. Không dựa vào các kiểm tra phía khách hàng một mình — một người dùng có thể bỏ qua chúng bằng cách truy cập API của bạn trực tiếp.

Xác minh email: Bật xác nhận email trong cài đặt Supabase Auth. Điều này ngăn mọi người tạo tài khoản bằng địa chỉ email giả và thêm một lớp hợp lệ tính tài khoản cơ bản.

Bước 4: Xác thực Tất cả Đầu vào

Các biểu mẫu do AI tạo ra thường có xác thực cơ bản (các trường bắt buộc, định dạng email) nhưng hiếm khi bảo vệ chống lại đầu vào độc hại.

Những gì cần thêm:

Xác thực phía máy chủ trên mọi điểm cuối API. Không bao giờ tin tưởng xác thực phía khách hàng một mình — nó có thể bị vượt qua bằng cách gửi các yêu cầu trực tiếp đến API của bạn. Sử dụng thư viện xác thực như Zod (cho TypeScript) để xác định lược đồ cho mọi dữ liệu mà ứng dụng của bạn chấp nhận.

Làm sạch HTML trong bất kỳ nội dung do người dùng tạo nào được hiển thị. Nếu ứng dụng của bạn có bình luận, mô tả hoặc bất kỳ trường văn bản nào được hiển thị trong trình duyệt, hãy sử dụng thư viện như DOMPurify để tước bỏ các kịch bản nguy hiểm. Nếu không, ai đó có thể chèn JavaScript để ăn cắp phiên của những người dùng khác (cross-site scripting / XSS).

Giới hạn kích thước và loại tệp tải lên nếu ứng dụng của bạn chấp nhận tệp tải lên. Các trình xử lý tải lên do AI tạo ra thường không có giới hạn, có nghĩa là ai đó có thể tải lên tệp 2GB hoặc một tệp thực thi. Thêm giới hạn kích thước (5MB là hợp lý cho hầu hết các ứng dụng) và hạn chế loại tệp cho những gì bạn thực sự cần (ảnh, PDF, v.v.).

Bước 5: Bảo mật Các Tuyến đường API của Bạn

Kiểm tra mọi API route hoặc server action trong ứng dụng của bạn để tìm những vấn đề này:

Xác thực trên mỗi điểm cuối. Mọi API route trả về hoặc sửa đổi dữ liệu người dùng phải xác minh phiên của người dùng trước tiên. AI thường tạo các API route chấp nhận yêu cầu từ bất kỳ ai.

Ủy quyền vượt quá xác thực. Ngay cả sau khi xác nhận người dùng đã đăng nhập, hãy xác minh rằng họ được phép truy cập tài nguyên cụ thể mà họ đang yêu cầu. "Người dùng A đã đăng nhập" không có nghĩa là "Người dùng A có thể chỉnh sửa hồ sơ của Người dùng B." Kiểm tra quyền sở hữu trên mọi truy cập dữ liệu.

Giới hạn tần suất. Nếu không có giới hạn tần suất, ai đó có thể gửi hàng nghìn yêu cầu mỗi giây đến API của bạn, hoặc để cạo dữ liệu hoặc để làm quá tải máy chủ của bạn. Thêm giới hạn tần suất cơ bản bằng thư viện như rate-limiter-flexible hoặc sử dụng giới hạn tần suất tích hợp của Vercel trên Edge Functions.

Phương thức HTTP. Đảm bảo các API route của bạn chỉ phản hồi các phương thức HTTP mà chúng nên phản hồi. Một tuyến đường xử lý yêu cầu POST không nên phản hồi các yêu cầu DELETE trừ khi bạn có ý định thiết kế như vậy.

Bước 6: Kiểm tra Cấu hình Triển khai của Bạn

Nền tảng triển khai của bạn có các cài đặt bảo mật mà AI không cấu hình cho bạn.

Cài đặt Vercel để kiểm tra: Bật "Deployment Protection" (yêu cầu xác thực để xem các bản triển khai xem trước — ngăn khách hàng vô tình chia sẻ các URL xem trước công khai những công việc đang tiến hành). Thiết lập giới hạn chi tiêu để ngăn chặn các khoản phí không mong muốn nếu ứng dụng của bạn nhận lưu lượng tăng đột biến. Cấu hình các miền được phép của bạn trong tiêu đề CORS.

Miền tùy chỉnh và SSL: Nếu bạn đang cung cấp nó cho khách hàng, hãy thiết lập miền tùy chỉnh của họ với HTTPS. Vercel và Netlify xử lý SSL tự động. Không bao giờ cung cấp ứng dụng khách hàng trên tên miền phụ .vercel.app — nó trông không chuyên nghiệp và khách hàng không thể chuyển nó dễ dàng.

Tiêu đề: Thêm tiêu đề bảo mật vào next.config.js hoặc vercel.json của bạn: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (ngăn trang web của bạn bị nhúng trong iframes để tấn công clickjacking), Strict-Transport-Security (buộc HTTPS). Đây là những bổ sung một lần ngăn chặn toàn bộ các loại tấn công.

Bước 7: Chạy Quét Bảo mật Cuối cùng

Trước khi bàn giao bất cứ điều gì cho khách hàng, hãy chạy những kiểm tra miễn phí này:

npm audit: Chạy npm audit trong thư mục dự án của bạn. Nó cờ các lỗ hổng đã biết trong các phụ thuộc của bạn. Sửa các vấn đề về tính nghiêm trọng cao và quan trọng. Chạy npm audit fix để sửa tự động khi có sẵn.

Lighthouse: Mở trang web được triển khai của bạn trong Chrome, mở DevTools, chạy kiểm tra Lighthouse. Kiểm tra điểm "Best Practices" — nó phát hiện các vấn đề bảo mật phổ biến như HTTPS bị thiếu, thư viện dễ bị tổn thương và tiêu đề không an toàn.

Kiểm tra thủ công: Đăng nhập dưới dạng một người dùng, cố gắng truy cập dữ liệu của người dùng khác bằng cách sửa đổi URL hoặc lệnh gọi API. Cố gắng gửi biểu mẫu trống, đầu vào lớn hơn kích thước và các ký tự đặc biệt (như tải trọng XSS được mã hóa). Nếu bất kỳ những cái nào trong số này hoạt động, bạn có vấn đề cần sửa.

Danh sách Kiểm tra Trước khi Ra mắt

In cái này và kiểm tra mọi mục trước khi đi trực tiếp:

• Tất cả bí mật trong các biến môi trường (không có khóa được mã hóa cứng)
• .env.local trong .gitignore (và không có bí mật trong lịch sử Git)
• Supabase RLS được bật trên mọi bảng
• Các chính sách RLS được kiểm tra (Người dùng A không thể xem dữ liệu của Người dùng B)
• Mã phía khách hàng chỉ sử dụng khóa anon (chỉ khóa vai trò dịch vụ phía máy chủ)
• Xác thực trên mọi API route
• Kiểm tra ủy quyền (xác minh quyền sở hữu) trên truy cập dữ liệu
• Xác thực đầu vào trên mọi biểu mẫu (phía máy chủ, không chỉ phía khách hàng)
• Giới hạn tải lên tệp (kích thước và loại) nếu áp dụng
• Giới hạn tần suất trên các điểm cuối API
• Tiêu đề bảo mật được cấu hình
• npm audit chạy và các vấn đề quan trọng được sửa
• Miền tùy chỉnh với SSL được cấu hình
• Các bản triển khai xem trước được bảo vệ
• Kiểm tra truy cập dữ liệu chéo người dùng thủ công đã vượt qua

Điều Tóm tắt

Bảo mật một ứng dụng vibe-coded không phải là về việc trở thành một chuyên gia bảo mật. Đó là về việc chạy qua một danh sách kiểm tra bắt những khoảng trống có thể dự đoán được mà AI để lại. Các bước trên mất 2–4 giờ và ngăn chặn các lỗ hổng phổ biến nhất. Đối với ứng dụng phải đối mặt với khách hàng, điều này không phải là tùy chọn — đó là sự khác biệt giữa công việc chuyên nghiệp và một trách nhiệm pháp lý.

Nếu bạn đang xây dựng ứng dụng vibe-coded đầu tiên của mình, hãy bắt đầu với hướng dẫn đầy đủ về vibe coding của chúng tôi. Nếu bạn muốn cải thiện các lời nhắc bạn sử dụng với Claude hoặc Cursor, hãy thử trình tối ưu hóa lời nhắc miễn phí của chúng tôi. Và để biết bảng phân tích các công cụ mã hóa tốt nhất, hãy xem Claude Code vs Codex.

Công khai: Một số liên kết trong bài viết này là liên kết liên kết. Chúng tôi chỉ khuyến nghị các công cụ mà chúng tôi đã thử nghiệm và sử dụng thường xuyên. Xem chính sách công khai đầy đủ của chúng tôi.