Nếu bạn vừa code một ứng dụng với Claude hoặc Cursor và sắp bàn giao cho khách hàng thanh toán, dừng lại. Code được tạo ra bởi AI đi kèm với những lỗ hổng bảo mật có thể dự đoán — API key bị lộ, thiếu xác thực đầu vào, quyền hạn cơ sở dữ liệu mặc định cho phép bất kỳ người dùng nào xem dữ liệu của người khác. Đây không phải những trường hợp cạnh biên. Chúng xảy ra trong hầu hết mọi cơ sở mã được tạo bởi AI lần đầu tiên.
Hướng dẫn này là danh sách kiểm tra bảo mật trước khi ra mắt. Thực hiện từng bước trước khi bất kỳ người dùng thực tế nào chạm vào ứ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ể công cụ của bạn là gì.
Tại sao Code được tạo ra bởi AI lại có vấn đề bảo mật
Các mô hình AI được tối ưu hóa cho "liệu nó có hoạt động không?" chứ không phải "liệu nó có an toàn không?" Khi bạn nói với Claude "xây dựng 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 key của bạn khỏi các công cụ dành cho nhà phát triển của trình duyệt, hoặc thêm giới hạn tỷ lệ để ngăn ai đó tấn công các điểm cuối của bạn.
Đây không phải những lỗi của AI — chúng là những khoảng trống trong lời nhắc. 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 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 toán các biến môi trường của bạn
Đây là sai lầm phổ biến nhất và nguy hiểm nhất trong các ứng dụng được mã hóa theo vibe. Kiểm tra mọi tệp trong dự án của bạn để tìm API key được mã hóa cứng, URL cơ sở dữ liệu hoặc bí mật.
Những gì cần tìm: Tìm kiếm trong cơ sở mã của bạn những chuỗi bắt đầu bằng sk-, eyJ, sbp_, supabase, postgres://, hoặc bất kỳ chuỗi dài trông ngẫu nhiên nào. Kiểm tra các tệp này cụ thể: bất kỳ tệp nào trong thư mục /app hoặc /pages, 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Ờ cam kết 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-keyXác minh: Kiểm tra tệp .gitignore của bạn bao gồm .env.local. Nếu bạn đã cam kết bí mật cho Git, chúng nằm trong lịch sử của bạn ngay cả sau khi xóa — xoay (tái tạo) mọi khóa bị lộ 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 Bảo mật ở cấp độ hàng (RLS) trên mọi bảng, sau đó tạo chính sách giới hạn truy cập.
Đi đến bảng điều khiển Supabase của bạn → Trình chỉnh sửa bảng → chọn mỗi bảng → nhấp vào "RLS Disabled" để bật nó. Sau đó thêm chính sách:
Đối với một ứng dụng điển hình nơi người dùng chỉ nên xem dữ liệu của chính 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ể nhìn thấy nó, chính sách của bạn là sai. Supabase có trình chỉnh sửa SQL nơi bạn có thể kiểm tra chính sách trực tiếp.
Sai lầm 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 code 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 code phía máy chủ (API route, server action) và không bao giờ được công khai cho trình duyệt.
Bước 3: Thêm xác thực một cách chính xác
Code xác thực được tạo bởi AI thường hoạt động nhưng có những phím tắt. Kiểm tra các vấn đề cụ thể sau:
Quản lý phiên: Hãy chắc chắn rằng phiên hết hạn. Kiểm tra rằng cài đặt xác thực của bạn bao gồm một khoảng thời gian chờ phiên hợp lý (các mặc định Supabase nói chung là tốt, 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 của 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 → Xác thực → Yêu cầu mật khẩu.
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ần mềm trung gian xác thực. Trong Next.js App Router, hãy tạo 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. Đừng chỉ dựa vào các kiểm tra phía khách hàng — người dùng có thể bỏ qua những kiểm tra đó bằng cách truy cập trực tiếp vào API của bạn.
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 tính hợp lệ tài khoản cơ bản.
Đang nhận giá trị từ cái này? Chúng tôi xuất bản một bài sâu sắc mỗi tuần về các công cụ AI, quy trình làm việc và hướng dẫn thực tế. Tham gia những độc giả nhận được nó trước tiên →
Bước 4: Xác thực tất cả các đầu vào
Các biểu mẫu được tạo ra bởi AI 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ị bỏ qua bằng cách gửi 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.
Vệ sinh 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ó nhận xét, 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 để loại bỏ các kịch bản nguy hiểm. Không có điều này, ai đó có thể chèn JavaScript để đánh cắp phiên của những người dùng khác (kịch bản trang chéo / 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ải lên tệp. Các trình xử lý tải lên được tạo bởi AI thường không có giới hạn, 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ế các loại tệp cho những gì bạn thực sự cần (hình ả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 tuyến đường API hoặc hành động máy chủ trong ứng dụng của bạn cho các vấn đề này:
Xác thực trên mọi điểm cuối. Mọi tuyến đường API trả về hoặc sửa đổi dữ liệu người dùng nên xác minh phiên của người dùng trước tiên. AI thường tạo các tuyến đường API chấp nhận yêu cầu từ bất kỳ ai.
Ủy quyền ngoài xác thực. Ngay cả sau khi xác nhận người dùng đã đăng nhập, hãy xác minh họ được phép truy cập tài nguyên cụ thể mà họ 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ỷ lệ. Nếu không có giới hạn tỷ lệ, ai đó có thể gửi hàng nghìn yêu cầu mỗi giây đến API của bạn, để 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ỷ lệ cơ bản bằng cách sử dụng thư viện như rate-limiter-flexible hoặc sử dụng giới hạn tỷ lệ tích hợp của Vercel trên Chức năng Edge.
Phương thức HTTP. Đảm bảo các tuyến đường API của bạn chỉ phản hồi các phương thức HTTP mà chúng nên. Một tuyến xử lý các yêu cầu POST không nên phản hồi các yêu cầu DELETE trừ khi bạn thiết kế rõ ràng cho nó.
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 cần kiểm tra: Bật "Bảo vệ triển khai" (yêu cầu xác thực để xem các 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 dữ liệu đang trong quá trì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. Định cấu hình các miền được phép trong tiêu đề CORS.
Miền tùy chỉnh và SSL: Nếu bạn đang giao ứng dụng này 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ờ giao ứng dụng khách hàng trên miền con .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 được nhúng trong iframe để tấn công nhấp), 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 cuộc 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 các 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ó gắ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 đề quan trọng và mức độ cao. Chạy npm audit fix cho các bản sửa tự động nếu 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ó bắt các vấn đề bảo mật phổ biến như HTTPS bị thiếu, thư viện dễ bị tấn cô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 các lệnh gọi API. Thử gửi các biểu mẫu trống, đầu vào quá lớn và các ký tự đặc biệt (như tải trọng XSS được mã hóa). Nếu bất kỳ điều gì 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 tuyến:
- 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.localtrong.gitignore(và không có bí mật trong lịch sử Git)- Supabase RLS được bật trên mọi bảng
- 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)
- Code phía khách hàng chỉ sử dụng khóa anon (khóa vai trò dịch vụ máy chủ duy nhất)
- Xác thực trên mọi tuyến đường API
- 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ỷ lệ trên các điểm cuối API
- Tiêu đề bảo mật được cấu hình
npm auditchạ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 triển khai xem trước được bảo vệ
- Kiểm tra truy cập dữ liệu của người dùng chéo thủ công đã vượt qua
Dòng dưới cùng
Bảo mật ứng dụng được mã hóa theo vibe không phải về việc trở thành chuyên gia bảo mật. Nó là về chạy qua một danh sách kiểm tra bắt được những khoảng trống có thể dự đoán 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 hướng đến khách hàng, đây không phải tùy chọn — đó là sự khác biệt giữa công việc chuyên nghiệp và trách nhiệp pháp lý.
Nếu bạn đang xây dựng ứng dụng được mã hóa theo vibe đầu tiên, 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à để tìm hiểu chi tiết các công cụ mã hóa tốt nhất, hãy xem Claude Code vs Codex.
Đây là những gì chúng tôi làm mỗi tuần. Một bài sâu sắc về các công cụ AI, quy trình làm việc và những nhận xét trung thực — không có hype, không có chất độn. Tham gia chúng tôi →
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 dùng các công cụ mà chúng tôi đã kiểm tra cá nhân và sử dụng thường xuyên. Xem chính sách công khai đầy đủ của chúng tôi.