آیا اپ‌های وایب کدینگ امن‌اند؟ ۸ حفره امنیتی برای بررسی

آیا اپ‌هایی که با وایب کدینگ ساخته می‌شوند امن‌اند؟

نه به‌طور پیش‌فرض: همه پژوهش‌های بزرگی که اینجا نقل شده‌اند، در بخش بزرگی از اپ‌هایی که بررسی کرده‌اند حفره‌های امنیتی جدی یافته‌اند ^[3][4][5]. اپ‌ها معمولاً کار می‌کنند. مشکل این است که به غریبه‌ها اجازه چه کارهایی می‌دهند.

یک ممیزی در سال ۲۰۲۶، تعداد ۹۰۴۱ اپ متن‌باز ساخته‌شده با Claude Code و Lovable را گردآوری کرد و ۲۰۰ مورد از آن‌ها را که عمومی منتشر شده بودند بررسی کرد. این ممیزی ۱۱۸۶ آسیب‌پذیری یافت و ۱۸۲ اپ از ۲۰۰ اپ (۹۱٫۰٪) دست‌کم یکی داشتند ^[4]. از این ضعف‌ها، ۶۵٫۷۷٪ بحرانی یا شدید ارزیابی شدند که ۱۸٫۴۷٪ آن‌ها بحرانی بود ^[4].

پژوهشگران همچنین آزمودند که آیا دستورهای بهتر و تنظیمات بهتر عامل‌ها مشکل را حل می‌کنند یا نه. این کار مشکل را کم کرد اما از بین نبرد، و همان کار وقتی سه بار اجرا می‌شد، می‌توانست یک بار نتیجه امن و بار بعد نتیجه ناامن بدهد ^[4]. یعنی یک نتیجه تمیز در یک نسخه چیز زیادی درباره نسخه بعدی نمی‌گوید.

برای مبانی این روش، راهنمای Pouyam با عنوان Vibe Coding Explained: What It Is, How It Works and the Real Risks (وایب کدینگ چیست و خطرهای واقعی آن) را ببینید. برای نخستین پروژه، راهنمای Vibe Coding for Beginners: How to Start Safely in ۲۰۲۶ (وایب کدینگ برای مبتدی‌ها) یک برنامه شروع می‌دهد. این صفحه یک لایه عمیق‌تر می‌رود: حفره‌های مشخص و روش آزمودن هرکدام.

پژوهش‌های امنیتی در اپ‌های وایب کدینگ چه می‌یابند؟

چهار منبع مستقل به یک نقطه ضعف اشاره می‌کنند: داده‌هایی که آدمِ نادرست می‌تواند بخواند یا تغییر دهد ^[1][3][4][5].

• ممیزی ۲۰۰ اپ منتشرشده (۲۰۲۶): کنترل دسترسی معیوب بزرگ‌ترین دسته بود، با ۳۳۹ مورد از ۱۱۸۶ ضعف (۲۸٫۵۸٪)، و ۶۴٫۰۰٪ اپ‌ها را درگیر کرد. تزریق ۵۴٫۰۰٪ و خطاهای احراز هویت ۵۱٫۵۰٪ اپ‌ها را درگیر کردند ^[4].
• پژوهش ACM CCS ۲۰۲۶: در ۸۶۴۱ مخزن Lovable با تاریخچه کامل، ۱۱٫۲٪ از قواعد خواندن برای بازدیدکنندگانِ واردنشده باز بود و ۶۱٫۲٪ مخزن‌ها دست‌کم یک قاعده این‌چنینی داشتند. آزمون بازپخش، افشا را در ۳۵۳ مخزن از ۴۰۰ مخزن نمونه تأیید کرد ^[5].
• Escape (اکتبر ۲۰۲۵): یک اسکن غیرفعال روی بیش از ۵۶۰۰ اپ عمومی ساخته‌شده روی پلتفرم‌هایی مانند Lovable، Base44 و Create.xyz بیش از ۲۰۰۰ آسیب‌پذیری، بیش از ۴۰۰ راز افشاشده و ۱۷۵ مورد داده شخصی یافت، از جمله پرونده‌های پزشکی، شماره‌های IBAN (شناسه حساب بانکی)، شماره تلفن‌ها و ایمیل‌ها ^[3].
• CVE-2025-48757 (۲۰۲۵): اسکنی که ۲۱ مارس ۲۰۲۵ تمام شد، ۳۰۳ نقطه دسترسی پایگاه داده را در ۱۷۰ پروژه از ۱۶۴۵ پروژه Lovable، حدود ۱۰٫۳٪، با قواعد ردیفِ ناکافی یافت ^[1].

Escape تأکید می‌کند که اسکنش هیچ کار مخربی انجام نداده، پس ارقامش حداقل است و آزمون عمیق‌تر موارد بیشتری می‌یافت ^[3]. همین احتیاط درباره همه ارقام این صفحه صدق می‌کند: این پژوهش‌ها چیزی را می‌شمارند که از بیرون دیده می‌شد.

چرا ابزارهای هوش مصنوعی اپ‌های ناامن می‌سازند؟

چون این ابزارها دنبال اپی هستند که کار کند، اما قواعد امنیتی به جزئیات کسب‌وکار بستگی دارد که دستورها به‌ندرت می‌گویند ^[4][11].

بررسی کدی که اجرا می‌شود آسان است: صفحه باز می‌شود، دکمه کار می‌کند. اما اینکه چه کسی اجازه دیدن هر رکورد را دارد یک تصمیم کسب‌وکاری است و اگر کسی آن را ننویسد، ابزار باید حدس بزند. ممیزی ۲۰۲۶ ضعف‌ها را به هشت الگوی خطای تکرارشونده نسبت می‌دهد که در سه محدودیت عامل‌های هوش مصنوعی دسته‌بندی می‌شوند: حافظه، اهداف و دانش ^[4].

آزمون‌های گسترده مدل‌های هوش مصنوعی همین شکاف را نشان می‌دهند. گزارش GenAI Code Security Report ۲۰۲۶ شرکت Veracode نشان داد در آزمون‌های این شرکت حدود ۴۴٪ از کارهای تولید کد یک آسیب‌پذیری امنیتی به همراه داشتند ^[11]. یک آزمون مقایسه‌ای که AWS به آن استناد کرده نشان داد بهترینِ ۱۲ تنظیم عامل، ۵۷٪ کارها را درست حل کرد، اما فقط ۱۱٫۸٪ را هم درست و هم امن ^[10].

بسیاری از اپ‌های وایب کدینگ همچنین امنیت را به پایگاه داده می‌سپارند. مرورگر مستقیم با یک پایگاه داده میزبانی‌شده حرف می‌زند، پس قواعد آن تنها مانع میان بازدیدکننده و هر ردیف است ^[1][6]. اگر قواعد نباشند یا بیش از حد گشاد باشند، هر کسی که نشانی را بداند می‌تواند همه چیز را درخواست کند.

اول کدام ۸ حفره امنیتی را بررسی کنم؟

از حفره‌هایی شروع کنید که پژوهش‌ها بیشتر از همه یافته‌اند، به ترتیب آسیبی که می‌توانند بزنند ^[1][3][4][5].

1. قواعد باز پایگاه داده: جدول‌هایی بدون امنیت در سطح ردیف، یا با قواعدی که به هر بازدیدکننده اجازه خواندن همه ردیف‌ها را می‌دهند. این ریشه CVE-2025-48757 و یافته‌های ACM بود ^[1][5].
2. کنترل دسترسی معیوب: کاربرِ واردشده با تغییر یک شناسه در نشانی یا درخواست، رکورد کاربر دیگری را باز می‌کند. این بزرگ‌ترین دسته در ممیزی ۲۰۲۶ بود ^[4].
3. کلیدهای مخفی در مرورگر: کلید secret یا service_role در Supabase، کلید پرداخت یا کلید یک ارائه‌دهنده هوش مصنوعی که در کد سمت کاربر گذاشته شده. Escape بیش از ۴۰۰ راز افشاشده یافت ^[3][6].
4. نبود یا ضعف بررسی ورود: صفحه‌های خصوصی یا مسیرهای API که بدون نشست پاسخ می‌دهند. خطاهای احراز هویت ۵۱٫۵۰٪ اپ‌های ممیزی‌شده را درگیر کرد ^[4].
5. تزریق: ورودی کاربر بدون بررسی به پرس‌وجوهای پایگاه داده یا HTML می‌رسد؛ در ۵۴٫۰۰٪ اپ‌های ممیزی‌شده دیده شد ^[4].
6. جدول‌های قابل نوشتن: قواعدی که به بازدیدکننده اجازه افزودن یا تغییر داده می‌دهند، نه فقط خواندن. در پرونده CVE، یک درخواست بدون توکن ورود رکوردی با برچسب "پرداخت‌شده" افزود و مرحله پرداخت را دور زد ^[1].
7. پاسخ‌های پرحرف: APIهایی که کل رکورد کاربر، ایمیل یا توکن را برمی‌گردانند درحالی‌که صفحه فقط یک نام لازم دارد. Escape تعداد ۱۷۵ مورد داده شخصی افشاشده شمرد ^[3].
8. دسترسی پرخطر عامل: عامل کدنویسی که اعتبارنامه‌های محیط اصلی را دارد می‌تواند آسیب واقعی بزند؛ در ژوئیه ۲۰۲۵ یک عامل در دوره توقف تغییر کد، یک پایگاه داده زنده را پاک کرد ^[10].

حفره‌های ۱ تا ۴ بیشترِ چیزی را که مهاجمان بیرونی سوءاستفاده می‌کنند پوشش می‌دهند، پس پیش از هر چیز آن‌ها را بیازمایید.

چطور اپ وایب کدینگ خودم را برای این حفره‌ها آزمایش کنم؟

از اپ همان‌طور استفاده کنید که یک مهاجم می‌کند: به‌عنوان غریبه، به‌عنوان کاربر دوم، و با خواندن آنچه مرورگر دریافت می‌کند ^[1][4][5]. هیچ‌یک از این مراحل ابزار خاصی لازم ندارد.

1. دو حساب آزمایشی بسازید. با حساب A یک رکورد بسازید، نشانی یا شناسه آن را کپی کنید، با حساب B وارد شوید و سعی کنید آن را باز کنید، ویرایش کنید و پاک کنید. اگر شد، کنترل دسترسی معیوب است ^[4].
2. بدون ورود تکرار کنید. همان نشانی‌ها را در یک پنجره خصوصی بدون نشست باز کنید. در پرونده CVE، حذف سرآیند ورود برای دور زدن همه بررسی‌ها کافی بود ^[1].
3. زبانه شبکه را زیر نظر بگیرید. در ابزارهای توسعه‌دهنده مرورگر، هر درخواست صفحه و پاسخ آن را ببینید. پاسخ‌ها فقط باید چیزی را داشته باشند که آن صفحه لازم دارد، هرگز ایمیل یا توکن کاربران دیگر را ^[3].
4. در کد صفحه دنبال کلید بگردید. رشته‌هایی را که با sb_secret_ شروع می‌شوند، برچسب service_role یا کلیدهای ارائه‌دهندگانی مثل پرداخت و هوش مصنوعی را جست‌وجو کنید. کلید publishable عادی است؛ کلید secret وضعیت اضطراری است ^[6].
5. قواعد هر جدول را بررسی کنید. در داشبورد پایگاه داده مطمئن شوید امنیت در سطح ردیف برای همه جدول‌ها روشن است و هر قاعده را به زبان ساده بخوانید: چه کسی می‌تواند بخواند، چه کسی می‌تواند بنویسد ^[7].
6. ورودی‌های عجیب را امتحان کنید. متن‌های خیلی بلند، علامت نقل‌قول و تگ‌های HTML را در هر فرم بچسبانید و ببینید اپ از کار می‌افتد یا آن‌ها را به‌صورت کد نشان می‌دهد ^[4].

فقط اپ‌هایی را آزمایش کنید که مال خودتان است یا اجازه آزمودنشان را دارید. بدون اجازه کتبی در اپ‌های دیگران کاوش نکنید.

چطور قواعد باز Supabase و کلیدهای لورفته را درست کنم؟

امنیت در سطح ردیف را برای هر جدول روشن کنید، قواعد محدود بنویسید، کلیدهای مخفی را روی سرور نگه دارید و هر کلید لورفته را عوض کنید ^[6][7][8].

• امنیت در سطح ردیف را همه‌جا روشن کنید. راهنمای Supabase می‌گوید آن را روی هر جدول در یک schema در معرض دسترسی روشن کنید ^[7]. پس از روشن کردن، کلید عمومی تا وقتی قاعده اضافه نکنید به هیچ چیز دسترسی ندارد ^[7].
• مجوزهای پیش‌فرض را بردارید. در پروژه‌هایی که هنوز آن‌ها را به‌طور پیش‌فرض می‌دهند، هر جدول عمومی تازه با همه امتیازها برای نقش‌های واردنشده (anon) و واردشده (authenticated) شروع می‌شود و افزودن قاعده آن مجوزها را پس نمی‌گیرد ^[7]. آن‌ها را لغو کنید و به هر نقش فقط آنچه لازم دارد بدهید ^[7].
• قواعد را بر پایه هر کاربر بنویسید. قاعده یک جدول خصوصی باید با شناسه کاربرِ واردشده تطبیق کند، نه اینکه به هر کسی که وارد شده اجازه دهد. از قواعدی که همیشه درست‌اند روی جدول‌های حساس پرهیز کنید ^[2].
• کلیدهای مخفی را سمت سرور نگه دارید. کلید publishable در Supabase فقط به این دلیل در مرورگر امن است که قواعد ردیف آن را محدود می‌کنند؛ کلیدهای secret و service_role همه قواعد را دور می‌زنند و باید در کد سرور یا تنظیمات امن محیط بمانند ^[6].
• کلیدهای لورفته را عوض کنید. اگر کلیدی مخفی حتی یک بار به مرورگر یا یک مخزن کد عمومی رسیده، کلید را عوض کنید و کلید لورفته را غیرفعال کنید، همان‌طور که راهنمای کلیدهای Supabase توصیه می‌کند ^[6].

تا ۱۵ نوامبر ۲۰۲۶، مستندات Supabase می‌گوید کلیدهای قدیمی anon و service_role را تا پایان ۲۰۲۶ به نفع کلیدهای publishable و secret کنار می‌گذارد ^[8]. کلیدهای secret تازه وقتی در مرورگر به کار روند خطا (HTTP 401) برمی‌گردانند، هرچند کلید لورفته هنوز از ابزارهای دیگر قابل استفاده است ^[6][8]. این جابه‌جایی فرصت خوبی برای بازبینی همه کلیدهایی است که یک اپ به کار می‌برد.

آیا اسکنرهای امنیتی داخلی همه چیز را پیدا می‌کنند؟

نه: اسکنرهای پلتفرم‌ها کمک می‌کنند، اما چند پژوهش نشان می‌دهد مهم‌ترین قواعد را از قلم می‌اندازند ^[1][2][5].

در ۲۰۲۵ پژوهشگرانی که CVE-2025-48757 را کشف کردند دریافتند اسکنر Lovable فقط وجود یک قاعده ردیف را بررسی می‌کرد، نه درستی آن را ^[1]. اطلاعیه آن‌ها می‌افزاید که بررسی انتشار Lovable جدول‌های بدون قاعده را علامت می‌زند، اما نشان نمی‌دهد قواعد به اندازه کافی سخت‌گیرانه‌اند یا نه ^[2]. یک قاعده باز از چنین بررسی‌ای رد می‌شود.

پژوهش ACM همین را با عدد نشان می‌دهد: سهم کمِ قواعد باز، ۶٫۳٪ در شش ابزار، باز هم ۵۶٫۹٪ مخزن‌ها را با دست‌کم یک جدول افشاشده باقی گذاشت، چون یک قاعده باز کافی است ^[5]. پژوهشگران یک ابزار بررسی رایگان منتشر کردند که چنین قواعدی را پیش از ثبت کد علامت می‌زند ^[5].

از اسکنرها به‌عنوان صافی اول استفاده کنید و آزمون دو‌حسابی و بدون ورود را خودتان انجام دهید. جدول زیر ارقام را خلاصه می‌کند.

آیا استفاده از اپ‌هایی که دیگران با وایب کدینگ ساخته‌اند امن است؟

با هر چیزی که داده شخصی، سلامت یا پرداخت می‌خواهد محتاط باشید، چون کاربران نمی‌بینند اپ چطور از آن محافظت می‌کند ^[3][4]. Escape در میان داده‌های افشاشده پرونده‌های پزشکی و شماره‌های IBAN (شناسه حساب بانکی) یافت ^[3].

چند عادت ساده خطر را کم می‌کند. برای هر اپ تازه یک رمز عبور جداگانه به کار ببرید تا لو رفتن یکی، حساب‌های دیگر را باز نکند؛ راهنمای Pouyam با عنوان Password Managers Explained: How They Work and Whether They Are Safe (مدیران رمز عبور چطور کار می‌کنند) روشش را توضیح می‌دهد. فقط داده‌ای را بدهید که اپ لازم دارد و صفحه‌های پرداخت ارائه‌دهندگان شناخته‌شده را به فرم‌های درون اپ ترجیح دهید.

مسئولیت اصلی با سازندگان است. اگر اپی منتشر می‌کنید که داده دیگران را نگه می‌دارد، بررسی‌های بالا را پیش از انتشار و پس از هر تغییر بزرگ انجام دهید، چون یک قابلیت تازه می‌تواند حفره‌ای بسته را دوباره باز کند ^[4][5].