Hầu hết các "vibe coder" vẫn đang ra mắt ứng dụng mà không có bất kỳ lớp bảo mật nào. Họ chỉ tập trung vào tính năng, thiết kế và tốc độ ra mắt. Những thứ nhàm chán như bảo mật thì cứ để sau.
Một số người đang phải trả giá cho điều đó. Hóa đơn Supabase $200 qua đêm. Spam tràn ngập ngay ngày đầu tiên. Một vài người nhận được thư yêu cầu ngừng hoạt động mà không hề lường trước.
Và rồi có một nhóm nhỏ âm thầm chạy một checklist 30 phút trước mỗi lần ra mắt. Đó là thứ không xuất hiện trong bản demo của bạn nhưng lại quyết định liệu ứng dụng của bạn có thể sống sót qua những người dùng thực sự đầu tiên hay không.
Tôi đã từng chia sẻ một phiên bản ngắn gọn của bài viết này dưới dạng một bài đăng. Nó đã đạt hơn 900,000 lượt xem, và các phản hồi cùng tin nhắn đều hỏi cùng một thứ: bản phân tích chuyên sâu đầy đủ, bối cảnh đại lý, và những phần tôi phải cắt bỏ để vừa với giới hạn ký tự. Vậy nên, nhiều bạn đã yêu cầu, và đây là nó, giờ đã được cập nhật cho bối cảnh thực tế của năm 2026.
Tôi đã xây dựng hơn 60 MVP tại agency trong gần 2 năm. Tôi đã ra mắt sản phẩm trong 21 ngày và đưa thẳng vào sản xuất. Và tôi đã học được rằng bảo mật không phải là thứ bạn thêm vào sau. Nó là thứ bạn phải tích hợp ngay trước khi ra mắt, nếu không bạn sẽ phải trả giá bằng những cuộc chạy đua chữa cháy, tiền hoàn trả và danh tiếng bị tổn hại.
Bài viết này là phiên bản đầy đủ. Nó bắt đầu với những gì một nhà phát triển với hơn 20 năm kinh nghiệm đã chia sẻ trên Reddit, sau đó kết hợp với mọi thứ chúng tôi thực hiện trên mọi dự án tại agency trước khi cho phép bất cứ thứ gì đi vào hoạt động.
Đây là bản phân tích đầy đủ.
Những Gì Bài Đăng Reddit Đã Đúng (Và Những Gì Nó Đã Bỏ Sót)
Một nhà phát triển với hơn 20 năm kinh nghiệm gần đây đã chia sẻ một checklist trước khi ra mắt trên Reddit và nó đã lan truyền trong cộng đồng vibe coding. Nó rất gọn gàng. Năm hạng mục. Những prompt thực tế mà bạn có thể copy vào Claude hoặc Cursor.
Anh ấy đã đặt nền móng một cách chính xác.
→ Tự bảo vệ mình về mặt pháp lý trước khi thu thập bất kỳ email nào
→ Sử dụng AI để kiểm tra tình trạng bảo mật của chính bạn trong 2 phút
→ Căn chỉnh với OWASP, không chỉ các header bảo mật
→ Kiểm tra rò rỉ dữ liệu ở frontend và các route API
→ Không bao giờ gửi API key ra trình duyệt
Nhưng sau khi kiểm tra hàng tá ứng dụng vibe coded trước khi báo giá xây dựng lại cho khách hàng, có một lớp bên dưới mà hầu hết mọi người xây dựng đều bỏ lỡ.
Bài đăng Reddit đề cập đến bề mặt. Bài viết này đề cập đến nền tảng bên dưới. Cả hai đều quan trọng. Nếu bạn chỉ làm một cái, bạn vẫn đang gặp rủi ro.
Vấn Đề Với Cách Tiếp Cận Bảo Mật Của Hầu Hết Các Vibe Coder
Hầu hết những người xây dựng đều coi bảo mật như một tính năng sẽ được thêm vào ở phiên bản 2.
Nó không phải là một tính năng. Nó là nền tảng tối thiểu.
AI cho phép bạn ra mắt một sản phẩm trong một ngày cuối tuần. Tốc độ tương tự đó cũng cho phép bạn ra mắt một món nợ trong một ngày cuối tuần. Codebase trông có vẻ sạch sẽ. Giao diện người dùng trông có vẻ bóng bẩy. Bản demo chạy hoàn hảo. Không điều nào trong số đó bảo vệ bạn khi ai đó mở DevTools và đọc toàn bộ cơ sở dữ liệu của bạn.
Khi các nhà sáng lập đến agency của chúng tôi và yêu cầu xây dựng lại một MVP hỏng hóc, năm hạng mục thất bại tương tự hầu như luôn xuất hiện. Cơ sở dữ liệu mở. Luồng xác thực bị rò rỉ thông tin. API key nằm trong các bundle frontend. Không có giới hạn tốc độ trên các endpoint đắt tiền. Thông báo lỗi hiển thị toàn bộ schema cho bất kỳ kẻ tấn công nào kích hoạt chúng.
Giải pháp không phải là hoang tưởng.
Giải pháp là một checklist 30 phút bạn chạy trước mỗi lần ra mắt. Năm hạng mục. Giống như cái chúng tôi chạy tại agency. Cũng là cái tôi sắp hướng dẫn bạn.
Phần 1: Tự Bảo Vệ Bạn, Không Chỉ Ứng Dụng Của Bạn
Ngay khi bạn thu thập dữ liệu người dùng, bạn đã bước vào lãnh thổ pháp lý. GDPR. CCPA. Điều khoản dịch vụ của nền tảng.
Hầu hết các vibe coder không nghĩ về điều này cho đến khi đã quá muộn.
Ba điều tối thiểu.
→ Một chính sách bảo mật thực sự, dù có được tạo ra hay không. Termly và PrivacyPolicies.com đều làm điều này miễn phí trong vòng chưa đầy 5 phút.
→ Biết chính xác dữ liệu người dùng của bạn sống ở đâu. Vùng Supabase, vùng Vercel, bất kỳ dịch vụ bên thứ ba nào chạm vào dữ liệu.
→ Không có gì mờ ám. Không bán dữ liệu người dùng. Không xuất nó sang email cá nhân của bạn. Không giữ mật khẩu dưới dạng văn bản thuần túy.
Không cần hoàn hảo. Chỉ cần không liều lĩnh.
Đây là 10 phút làm việc rẻ nhất trong cả năm của bạn và nó là sự khác biệt giữa một buổi ra mắt bình thường và nhận được một email yêu cầu ngừng hoạt động vào tuần thứ hai.
Những gì đã thay đổi vào năm 2026, và tại sao phần này lại quan trọng hơn bây giờ.
Nền tảng pháp lý cho các ứng dụng do AI xây dựng đã thay đổi trong năm nay, và hầu hết những người xây dựng vẫn chưa bắt kịp.
→ Tòa án Tối cao đã giữ nguyên phán quyết về quyền tác giả của con người. Mã được viết hoàn toàn bởi AI không thể được bảo vệ bản quyền tại Mỹ. Nếu đối thủ cạnh tranh clone ứng dụng do AI xây dựng của bạn từng dòng, bạn có thể không có cơ sở pháp lý để ngăn chặn họ.
→ Nếu AI của bạn âm thầm kéo mã nguồn mở theo giấy phép như GPL, bạn có thể bị buộc phải mã nguồn mở toàn bộ codebase của mình, hoặc đối mặt với khiếu nại vi phạm. Bạn nhận tất cả trách nhiệm pháp lý và không có sự bảo vệ nào.
→ Vụ kiện bản quyền AI lớn nhất từ trước đến nay đã kết thúc với khoản bồi thường 1.5 tỷ đô la, và nó đã nhận được sự chấp thuận cuối cùng của tòa án trong tuần này. Các luật sư không phải sắp đến. Họ đã ở đây rồi.
Không điều nào trong số này có nghĩa là bạn nên ngừng xây dựng. Nó có nghĩa là hãy ngừng ra mắt một cách mù quáng. Phần còn lại của checklist này là cách bạn làm điều đó.
Phần 2: Khóa Chặt Cơ Sở Dữ Liệu Của Bạn
Đây là phần chúng tôi dành nhiều thời gian nhất khi kiểm tra các dự án đến. Hầu hết mọi ứng dụng vibe coded mà chúng tôi từng mở ra đều thất bại ít nhất một trong ba bước kiểm tra dưới đây.
Row Level Security trên Supabase.
Nếu không có RLS, bất kỳ ai cũng có thể mở DevTools của trình duyệt, chạy một truy vấn và đọc toàn bộ cơ sở dữ liệu của bạn. Không phải hack. Không phải khai thác. Chỉ cần mở bảng điều khiển và gõ một lệnh.
Đi tới bảng điều khiển Supabase của bạn. Nhấp vào Authentication, sau đó Policies. Nếu bạn thấy không có chính sách nào, ứng dụng của bạn đang trần trụi.
Giải pháp rất đơn giản. Thêm các chính sách hạn chế ai có thể đọc, chèn, cập nhật hoặc xóa các hàng dựa trên người dùng đã được xác thực. Nếu bạn đang sử dụng Lovable hoặc Bolt, chỉ cần yêu cầu agent bật RLS và viết chính sách cho các bảng của bạn. Nó sẽ tự động tạo SQL.
5 phút. Sự khác biệt giữa một ứng dụng an toàn và một vụ rò rỉ dữ liệu đang chờ xảy ra.
Xác thực phía máy chủ trên mọi biểu mẫu.
Zod trên client không phải là bảo mật. Nó là trải nghiệm người dùng.
Kẻ tấn công tắt JavaScript, mở Postman và gửi bất cứ thứ gì chúng muốn trực tiếp đến API của bạn. Nếu xác thực duy nhất của bạn là ở frontend, chúng có thể gửi dữ liệu sai định dạng, các nỗ lực SQL injection hoặc tập lệnh. Nếu biểu mẫu của bạn ghi vào cơ sở dữ liệu, hãy xác thực NÓ MỘT LẦN NỮA trên máy chủ. Kiểm tra kiểu dữ liệu. Kiểm tra giới hạn độ dài. Làm sạch đầu vào.
Đây là điều cơ bản. Không phải tùy chọn.
Thông báo lỗi không làm rò rỉ dữ liệu.
Thông báo lỗi tồi. "SELECT * FROM users WHERE email failed."
Điều đó cho kẻ tấn công biết tên bảng, tên cột và logic truy vấn của bạn.
Thông báo lỗi tốt. "User not found."
Ghi lại các lỗi đầy đủ ở phía máy chủ kèm ngữ cảnh. Hiển thị thông báo chung chung cho người dùng. Không bao giờ để lộ stack trace trong môi trường sản xuất. An ninh hoạt động cơ bản. Hầu hết các ứng dụng đều thất bại ngay ngày đầu tiên.
Thông báo xấu trao cho kẻ tấn công schema của bạn. Thông báo tốt không tiết lộ gì.
Một prompt. Hầu hết các lỗ hổng OWASP của bạn được gắn cờ trong 30 giây.
Phần 3: Kiểm Tra Các Trường Hợp Thất Bại Trên Auth
Hầu hết các nhà phát triển chỉ kiểm tra luồng thành công. Đăng ký với một email hợp lệ. Đăng nhập. Xem như xong.
Ứng dụng hỏng khi mọi thứ sai. Đó chính xác là nơi kẻ tấn công thăm dò đầu tiên.
Đây là bài kiểm tra trường hợp thất bại 4 điểm chính xác mà chúng tôi chạy trước khi ký duyệt bất kỳ dự án nào.
→ Đăng nhập với sai mật khẩu 5 lần liên tiếp. Nó có khóa tài khoản không? Nó hiển thị lỗi chung chung hay xác nhận email tồn tại?
→ Đặt lại mật khẩu cho một email không tồn tại. Nó có tiết lộ liệu email có trong hệ thống không?
→ Nhấp vào liên kết xác minh email hai lần. Nó có làm hỏng luồng hay xử lý một cách trơn tru?
→ Đăng ký với một email đã được đăng ký. Nó có làm lộ rằng người dùng đã tồn tại không?
10 phút kiểm tra. Bắt 80% lỗ hổng xác thực trước khi chúng hoạt động.
Chúng tôi đã chạy bài kiểm tra chính xác này trên mọi cuộc kiểm tra đến mà chúng tôi đã thực hiện trong năm nay. Nó đã phát hiện ra các vấn đề trong khoảng 7 trên 10 codebase. Các vibe coder với giao diện đẹp đã bỏ lỡ những điều này mọi lúc.
Phần 4: 4 Prompt AI Bạn Chạy Trước Mỗi Lần Ra Mắt
Đây là phần mà bài đăng Reddit đã làm rất tốt. Bốn prompt này bao phủ 80% cuộc kiểm tra bảo mật bề mặt và mất tổng cộng khoảng 8 phút.
Bạn chạy chúng bên trong Claude Code, Cursor hoặc bất kỳ agent nào bạn xây dựng. Lưu chúng lại. Biến chúng thành một phần của nghi thức ra mắt của bạn.
Prompt 1. Tình trạng bảo mật cơ bản.
Hãy xem xét ứng dụng của tôi với tư cách là một chuyên gia bảo mật và đảm bảo tôi có
các header bảo mật mạnh mẽ và một tình trạng bảo mật cơ bản vững chắc.
2 phút. Sửa các lỗ hổng rõ ràng. Chỉ riêng các header là không đủ nhưng chúng là nền tảng tối thiểu.
Prompt 2. Kiểm tra tiêu chuẩn OWASP.
Xem xét ứng dụng của tôi theo các tiêu chuẩn OWASP và làm nổi bật các lỗ hổng.
Đây là nơi SQL injection, XSS và các vấn đề xác thực thực sự bị phát hiện.
Prompt 3. Kiểm tra rò rỉ dữ liệu.
Kiểm tra ứng dụng của tôi để tìm bất kỳ rò rỉ thông tin đăng nhập hoặc dữ liệu nhạy cảm nào trong
các route frontend hoặc API.
Mã do AI tạo ra rò rỉ dữ liệu ở 3 nơi hầu như mọi lúc. Giá trị .env kết thúc trong mã frontend. Phản hồi API trả về quá nhiều dữ liệu. Bí mật xuất hiện trong nhật ký.
Prompt 4. Kiểm tra phơi bày API key.
Đảm bảo không có API key nào bị phơi bày trong mã frontend hoặc các cuộc gọi mạng.
Nếu key của bạn nằm trong trình duyệt, hãy coi như nó đã bị lấy. Một lỗi này đã làm tiêu hao toàn bộ các dự án indie trong một ngày cuối tuần duy nhất.
Đi Sâu Hơn Về API Key.
Prompt đó bắt các trường hợp rõ ràng. Đây là quy tắc chúng tôi chạy trên mọi dự án ngoài điều đó.
Khóa công khai có thể ở lại frontend. Khóa anon Supabase, khóa Stripe publishable, bất cứ thứ gì được đánh dấu rõ ràng là công khai. Chúng được thiết kế để bị phơi bày.
Khóa bí mật phải ở lại phía máy chủ. Khóa service role, khóa Stripe secret, khóa OpenAI, bất cứ thứ gì không có tiền tố "publishable". Lưu trữ chúng trong Supabase Edge Function Secrets hoặc biến môi trường Vercel. Không bao giờ commit chúng vào hệ thống kiểm soát phiên bản. Không bao giờ dán chúng vào mã frontend của bạn.
Nếu bạn nghĩ rằng một khóa có thể đã bị phơi bày, hãy tạo lại nó ngay lập tức. Đừng chờ đợi. Đừng hy vọng không ai tìm thấy nó. Các kho GitHub công khai bị quét để tìm khóa trong vòng vài phút.
Hai phút để biết liệu các header bảo mật của bạn có đang làm gì đó không.
Phần 5: Bảo Vệ Cơ Sở Hạ Tầng Của Bạn
Đây là phần bảo vệ ví tiền của bạn, không chỉ dữ liệu của bạn.
Giới hạn tốc độ trên mọi endpoint.
Đây là cách nhanh nhất để một ứng dụng vibe coded rỗng túi của bạn. Nếu không có giới hạn tốc độ, ai đó có thể spam API của bạn 10,000 lần trong một phút. Có thể là brute force đăng nhập. Có thể là quét cơ sở dữ liệu của bạn. Có thể chỉ là ác ý.
Cá nhân tôi đã chứng kiến hóa đơn Supabase tăng từ $20 lên $200 trong một ngày duy nhất trên một dự án phụ chỉ vì một endpoint không có giới hạn tốc độ. Nó xảy ra nhanh chóng.
Ba điều tối thiểu.
→ Giới hạn tốc độ mọi endpoint chạm vào API trả phí (OpenAI, Anthropic, Stripe, Resend)
→ Đặt giới hạn hàng ngày cứng trong bảng điều khiển OpenAI và Anthropic
→ Thiết lập cảnh báo ở mức 50% giới hạn hàng ngày của bạn để bạn bắt kịp một đợt tăng đột biến trước khi nó ảnh hưởng đến bạn vào buổi sáng
Đối với Supabase Edge Functions, Upstash là giải pháp giới hạn tốc độ dễ dàng nhất. 100 yêu cầu mỗi phút mỗi IP cho các endpoint công khai, 1,000 mỗi phút cho người dùng đã xác thực là một đường cơ sở hợp lý.
CAPTCHA trên mọi biểu mẫu công khai.
Biểu mẫu liên hệ, trang đăng ký, danh sách chờ. Nếu không có CAPTCHA, bot sẽ tràn ngập bạn ngay ngày đầu tiên. Chúng tôi đã thấy các biểu mẫu liên hệ thu thập 500 bài gửi spam trong một giờ trên các ứng dụng không có biện pháp bảo vệ nào.
Cloudflare Turnstile miễn phí và tập trung vào quyền riêng tư. Tích hợp mất 10 phút.
Hạn chế CORS trên API của bạn.
Theo mặc định, nhiều framework cho phép các yêu cầu API từ bất cứ đâu. Tốt cho phát triển cục bộ. Thảm họa trong sản xuất.
Chỉ định chính xác tên miền nào có thể truy cập API của bạn. Cho phép tên miền sản xuất của bạn. Cho phép localhost để kiểm tra. Chặn mọi thứ khác. 2 phút. Ngăn chặn cross-site request forgery và truy cập API trái phép.
Giới hạn cứng và cảnh báo. Cài đặt 3 phút giúp bạn tiết kiệm hóa đơn hàng tháng.
Chạy Bản Quét Bảo Mật Tích Hợp Cuối Cùng
4 prompt trong Phần 4 là thủ công. Bạn dán chúng và đọc những gì chúng trả về. Kể từ 3 ngày trước, bạn có một thứ tốt hơn cho cổng cuối cùng.
Anthropic vừa ra mắt plugin Claude Security cho Claude Code.
Nó đang trong giai đoạn beta, được phát hành vào ngày 22 tháng 7, và nó không phải là một prompt đơn lẻ. Nó là một trình quét lỗ hổng đa tác nhân chạy ngay trong terminal của bạn. Cài đặt nó bên trong một phiên Claude Code:
/plugin install claude-security@claude-plugins-official sau đó /reload-plugins. Điều đó cung cấp cho bạn một lệnh, /claude-security.
Điều gì làm cho nó khác biệt so với việc dán một prompt.
→ Một nhóm các tác nhân ánh xạ kiến trúc của bạn, xây dựng một mô hình mối đe dọa, sau đó săn lùng trên 4 hạng mục: injection, xác thực và truy cập, bộ nhớ, và mã hóa và bí mật
→ Mọi phát hiện phải vượt qua một hội đồng đối kháng gồm 3 tác nhân trước khi nó đến được báo cáo của bạn, vì vậy bạn không phải lội qua các kết quả dương tính giả
→ Báo cáo cung cấp cho bạn mức độ nghiêm trọng, ID CWE và chính xác tệp và dòng, và nó có thể biến các phát hiện thành các tệp vá mà bạn tự xem xét và áp dụng
→ Mô hình đằng sau nó đã tìm thấy hơn 500 lỗ hổng mức độ nghiêm trọng cao chưa từng được biết đến trước đây trong các codebase mã nguồn mở
Bạn cần một gói Claude Code trả phí (v2.1.154 trở lên) và các lần quét sử dụng token của gói bạn.
Cursor và các trình xây dựng trực quan như Lovable cũng có các trình quét riêng của họ để gắn cờ cấu hình RLS sai, bí mật bị phơi bày, các phụ thuộc dễ bị tấn công và các mẫu không an toàn. Chạy bất cứ cái nào mà stack của bạn có.
Sửa mọi thứ chúng gắn cờ. Đừng ra mắt với các cảnh báo. Đừng tự nhủ sẽ sửa sau. Nợ bảo mật chồng chất nhanh hơn nợ tính năng.
Coi bản quét này như cổng cuối cùng trước khi triển khai. Các prompt thủ công bắt những gì trình quét bỏ sót. Trình quét bắt những gì bạn quên prompt. Giờ đây khi Anthropic đã xây dựng một cái thực sự vào Claude Code, không có lý do gì để bỏ qua nó.
Khi Nào Sử Dụng Checklist Này
Checklist này được xây dựng cho 80% những người xây dựng đang ra mắt MVP, SaaS, công cụ AI hoặc bất cứ thứ gì có dữ liệu người dùng.
Sử dụng nó khi.
→ Bạn đang ra mắt bất kỳ ứng dụng nào thu thập dữ liệu người dùng, dù chỉ là một email
→ Bạn đang chạy trên Supabase, Firebase hoặc bất kỳ backend nào có quyền truy cập cơ sở dữ liệu
→ Bạn đang gọi các API trả phí (OpenAI, Anthropic, Stripe) từ codebase của mình
→ Bạn sắp chia sẻ ứng dụng của mình công khai lần đầu tiên
Triển khai dần dần khi.
→ Bạn đang ra mắt các công cụ nội bộ chỉ được sử dụng bởi nhóm của bạn sau xác thực
→ Bạn đang làm việc với một nhóm bảo mật đã chạy một cuộc kiểm tra toàn diện hơn
→ Bạn đang ở chế độ khám phá tiền MVP và không thu thập bất kỳ dữ liệu người dùng nào
Đối với hầu hết các vibe coder ra mắt bất cứ thứ gì thực tế, mọi mục trong danh sách này đều áp dụng. Bỏ qua bất kỳ mục nào trong số đó là đang gánh chịu trách nhiệm pháp lý mà bạn không cần.
Những Điều Cần Lưu Ý
Một vài lưu ý trung thực trước khi bạn coi đây là lời cuối cùng.
Checklist này đưa bạn đến một mức cơ bản tự tin, không phải tuân thủ cấp doanh nghiệp. Nếu bạn đang lưu trữ dữ liệu sức khỏe, dữ liệu tài chính hoặc bất cứ thứ gì được quản lý, bạn cần một cuộc kiểm tra bảo mật thực sự bên cạnh điều này.
Các prompt và trình quét AI bắt các vấn đề ở mức bề mặt. Chúng không bắt các lỗ hổng logic nghiệp vụ, lỗi trạng thái xác thực phức tạp hoặc các cuộc tấn công injection tinh vi. Hãy coi chúng là nền tảng tối thiểu, không phải là trần nhà.
Nợ bảo mật chồng chất. Bạn càng chờ đợi lâu, việc dọn dẹp càng đau đớn. Chạy nó trước mỗi lần ra mắt, không chỉ một lần khi bắt đầu.
Các chính sách RLS rất dễ viết sai. Hãy kiểm tra chúng bằng cách thử truy cập dữ liệu với tư cách một người dùng khác. Chỉ bật RLS mà không kiểm tra còn tệ hơn là không có nó vì nó tạo ra sự tự tin sai lầm.
Điều Này Thực Sự Có Nghĩa Là Gì
Đây là quan điểm trung thực của tôi.
Nền kinh tế vibe coding đang trưởng thành nhanh chóng. Một năm trước, bạn có thể ra mắt bất cứ thứ gì và không ai quan tâm. Giờ đây, các nền tảng đang thực thi các chính sách bảo mật. Người dùng mong đợi điều đó. Các nhà đầu tư đang kiểm tra nó. Các tòa án đã vạch ra những ranh giới thực sự trong năm nay, và các luật sư đã bắt đầu xuất hiện.
30 phút bạn bỏ qua trước khi ra mắt sẽ khiến bạn mất 30 ngày chạy đua chữa cháy khi có sự cố xảy ra. Chúng tôi đã chứng kiến điều đó xảy ra trong nhiều cuộc kiểm tra đến trong năm nay, nơi các nhà sáng lập đến gặp chúng tôi yêu cầu xây dựng lại sau khi phiên bản đầu tiên của họ bắt đầu rò rỉ dữ liệu hoặc đốt tiền.
Tại agency, chúng tôi coi checklist này như việc triển khai. Nó không phải là tùy chọn. Nó là một phần của việc ra mắt. Và với việc Anthropic hiện đang tích hợp một trình quét bảo mật trực tiếp vào Claude Code, khoảng cách giữa những người xây dựng chạy nó và các vibe coder bỏ qua nó sẽ còn rộng hơn nhanh chóng.
Bạn không cần phải hoang tưởng. Bạn không cần bảo mật cấp doanh nghiệp vào ngày đầu tiên. Bạn chỉ cần checklist này.
Hãy chạy nó trước mỗi lần ra mắt. Biến nó thành một phần của quy trình làm việc của bạn. Coi nó như việc kiểm thử hoặc triển khai.
Bởi vì các ứng dụng sống sót trong năm 2026 không chỉ là những ứng dụng ra mắt nhanh. Chúng là những ứng dụng ra mắt nhanh và không bị hỏng khi người dùng thực sự xuất hiện.
Năm 2026 sẽ KHÔNG CÔNG BẰNG cho những người xây dựng coi bảo mật như một quy trình làm việc thay vì một suy nghĩ muộn màng.
TLDR
→ Các vibe coder đang bị kiện, bị phạt và bị hút sạch. Hầu hết vẫn chưa nhận ra.
→ Mới trong năm 2026: Mã chỉ do AI tạo ra không thể được bảo vệ bản quyền tại Mỹ, nhiễm GPL có thể buộc bạn phải mã nguồn mở toàn bộ ứng dụng của mình, và thỏa thuận bản quyền AI lớn nhất trong lịch sử (1.5 tỷ đô la) vừa nhận được sự chấp thuận cuối cùng của tòa án. Hãy tự bảo vệ mình trước.
→ Bước 1. Tự bảo vệ mình về mặt pháp lý. Chính sách bảo mật, vị trí dữ liệu, không xử lý mờ ám.
→ Bước 2. Khóa chặt cơ sở dữ liệu của bạn. RLS trên Supabase, xác thực phía máy chủ trên mọi biểu mẫu, thông báo lỗi không làm rò rỉ dữ liệu.
→ Bước 3. Kiểm tra các trường hợp thất bại trên auth. Sai mật khẩu 5 lần. Đặt lại mật khẩu cho email giả. Liên kết xác minh được nhấp hai lần. Đăng ký với email đã tồn tại.
→ Bước 4. Chạy 4 prompt bảo mật AI. Tình trạng bảo mật. OWASP. Rò rỉ dữ liệu. Phơi bày API key.
→ Khóa chặt các biến môi trường. Khóa công khai có thể sống ở frontend. Khóa bí mật đi vào Supabase Edge Function Secrets hoặc biến môi trường Vercel. Nếu bị phơi bày, hãy tạo lại ngay lập tức.
→ Bước 5. Bảo vệ cơ sở hạ tầng của bạn. Giới hạn tốc độ mọi endpoint. Đặt giới hạn cứng trên các API trả phí. CAPTCHA trên các biểu mẫu công khai. Hạn chế CORS trên API của bạn.
→ Chạy một trình quét thực sự như cổng cuối cùng của bạn. Plugin Claude Security mới của Anthropic chạy một bản quét đa tác nhân ngay trong terminal của bạn. Beta, các gói Claude Code trả phí.
→ Điều này mất 30 phút. Hãy chạy nó trước mỗi lần ra mắt.
→ Khoảng cách giữa những người xây dựng chạy nó và những người xây dựng bỏ qua nó sẽ mở rộng nhanh chóng vào năm 2026.
Bài đăng Reddit đầy đủ đã gây ra điều này. https://www.reddit.com/r/vibecoding/comments/1sthzcj/if_youre_about_to_launch_a_vibe_coded_app_read/
Chụp màn hình cái này. Chạy nó trước mỗi lần ra mắt.
Chơi thôi.
