۹۸٪ از اپلیکیشن‌های ساخته‌شده با هوش مصنوعی دارای حفره‌های امنیتی هستند

اگر امروز یک اپلیکیشن را تنها با کمک ابزارهای هوش مصنوعی بالا آورده‌اید، احتمالاً کلیدهای خصوصی و کد منبع شما در دسترس هر متجاوز اینترنتی است. این ریسک دیگر یک احتمال نیست، بلکه یک آمار تاییدشده است.

طبق گزارش Symbiotic Security در ژوئن ۲۰۲۶، بررسی ۱۰۷۲ اپلیکیشن ساخته‌شده با Supabase نشان داد که ۹۸٪ آن‌ها حداقل یک مشکل امنیتی دارند و ۱۶٪ این موارد، آسیب‌هایی در سطح «بحرانی» هستند. این وضعیت به دلیل رویکرد Vibe Coding (برنامه‌نویسی حسی) رخ می‌دهد؛ روشی که در آن برنامه‌نویس بیشتر نقش یک رهبر ارکسترا را دارد تا یک بازبین کد و تنها بر اساس «حس» و خروجی ظاهری پیش می‌رود. این رویکرد hastily-built به‌قدری گسترش یافته که حتی سرویس‌های تخصصی برای بازسازی و اصلاح این اپلیکیشن‌های «وایب‌کد شده» با قیمت‌های گزاف ظهور کرده‌اند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های مولد اشاره کردیم، سرعت تولید کد توسط هوش مصنوعی، سرعتِ تفکر امنیتی ما را پیشی گرفته است. در این مدل، ابزارهایی مثل Lovable، Bolt و v0 می‌توانند در ۴۰ دقیقه یک محصول را روی یک URL واقعی مستقر کنند، اما شکاف بین یک «نمونه اولیه فعال» و یک «محیط عملیاتی امن»، به یک خطر quantifiable تبدیل شده است. به نقل از پژوهش Deng et al، اپلیکیشن‌های کدنویسی‌شده توسط هوش مصنوعی، الگوهای آسیب‌پذیری تکرارشوندی دارند که با کدهای انسانی متفاوت است؛ یعنی ما با اشتباهات تصادفی نیستیم، بلکه با شکست‌های ساختاری مواجهیم. بر اساس بررسی‌های Xint.io که توسط SecurityWeek منتشر شد، ۴۳۴ نقص قابل بهره‌برداری در سه حوزه شناسایی شده است: افشای اسرار (Secrets)، شکست در احراز هویت و حملات منع سرویس.

نشت‌های فاجعه‌بار و افشای کلیدهای محرمانه

بحرانی‌ترین شکست‌ها مربوط به فایل‌های پیکربندی است. این اتفاق معمولاً زمانی می‌افتد که دایرکتوری خروجیِ بیلد (build output directory) و ریشه پروژه (project root) به یک مسیر تبدیل شوند. شما باید بررسی کنید که آیا فایل‌های .env یا .env.local یا .env.production از طریق HTTP قابل دسترس هستند یا خیر. با استفاده از دستور curl -sI روی این مسیرها، هر پاسخی به جز ۴۰۴ یک وضعیت اضطراری است. در چنین حالتی باید فوراً تمام کلیدهای موجود در آن فایل را تغییر (Rotate) دهید، چون بات‌ها به‌طور مداوم این مسیرها را می‌کاوند.

دسترسی به دایرکتوری‌های .git حتی خطرناک‌تر از فایل‌های .env است، زیرا کل تاریخچه تغییرات کد شما را فاش می‌کند؛ این شامل کلیدهایی است که فکر می‌کردید قبلاً آن‌ها را حذف کرده‌اید. اگر یک درخواست به مسیر /.git/HEAD پاسخ ۲۰۰ OK بدهد، هر غریبه‌ای می‌تواند کل مخزن (Repository) کد شما را بازسازی کند.

همچنین در بسته‌های کلاینت (Client Bundle)، دستیارهای هوش مصنوعی اغلب کلید anon را با کلید service_role در Supabase اشتباه می‌گیرند. کلید anon برای مرورگر امن است، اما کلید service_role نیست—زیرا این کلید تمام لایه‌های امنیت سطح ردیف (RLS) — که مثل یک نگهبان سخت‌گیر جلوی هر ردیف از داده‌ها می‌ایستد تا فقط شخص مجاز آن را ببیند — را به‌طور کامل دور می‌زند. برای یافتن این موارد، در DevTools مرورگر، به بخش Sources بروید و عباراتی مثل sk- یا service_role یا SECRET یا PRIVATE_KEY یا توکن‌های JWT که با eyJ شروع می‌شوند را جست‌وجو کنید.

زیرساخت و کنترل‌های دسترسی

امنیت سطح ردیف (RLS) یکی از نقاط شکست رایج است چون به‌طور پیش‌فرض «خاموش» (default-off) است. اگر از کلید anon در مرورگر استفاده کنید و برای هر جدول سیاست‌های صریح RLS تعریف نکرده باشید، شما در همان ۱۶٪ اپلیکیشن‌های دارای آسیب‌پذیری بحرانی ثبت‌شده توسط Symbiotic Security قرار می‌گیرید. جمله «بعداً سیاست‌ها را اضافه می‌کنم» دلیل اصلی باقی ماندن این حفره‌های بحرانی است.

سایر خلأهای زیرساختی عبارت‌اند از:

• نبود هدرهای امنیتی: اکثر استقرارهای AI هیچ‌کدام از هدرهای امنیتی استاندارد را برنمی‌گردانند. دو مورد حیاتی Content-Security-Policy (یا حداقل frame-ancestors) برای جلوگیری از کلیک‌جکینگ و Strict-Transport-Security برای جلوگیری از حملات کاهش سطح TLS هستند تا مهاجم نتواند رمزنگاری شما را حذف کند. سایر هدرهای غایب معمولاً شامل x-frame-options و x-content-type-options و referrer-policy و permissions-policy هستند.
• انتشار نقشه‌های منبع (Source Maps): فایل‌هایی مثل _next/static/chunks/main.js.map در محیط عملیاتی، کد منبع خوانا و اصلی شما را به مهاجم می‌دهد. این امر کامنت‌ها، نام توابع داخلی و مسیرهای کد بلااستفاده (dead code paths) را فاش می‌کند. این فایل‌ها باید در تنظیمات بیلد خاموش شوند یا دسترسی به آن‌ها محدود به کاربران احراز هویت شده باشد.
• مسیرهای یتیم (Orphan Routes): اسکلت‌بندی‌های هوش مصنوعی علاقه زیادی دارند که مسیرهای دیباگ بدون احراز هویت را باقی بگذارند. مسیرهایی مثل /api/debug یا /api/test یا /admin یا /api/seed را چک کنید که برای توسعه بوده اما به اشتباه به محیط عملیاتی منتقل شده‌اند.

ریسک‌های API و داده‌های کاربر

محدودسازی نرخ درخواست (Rate Limiting) تقریباً هیچ‌گاه به‌طور خودکار اعمال نمی‌شود مگر اینکه صراحتاً درخواست شده باشد. بدون آن، نقطه ورود Login شما یک هدف رایگان برای حملات Credential Stuffing است و APIهای متصل به هوش مصنوعی زاینده (Generative AI) — که مثل یک سرور گران‌قیمت است که برای هر پاسخ هزینه می‌کند — توسط دیگران برای مصرف بودجه استنتاج (Inference Budget) شما مورد سوءاستفاده قرار می‌گیرند. شما باید بررسی کنید که آیا میزبان (Host) شما امکان Rate Limiting در لبه (Edge) را از طریق یک پرچم پیکربندی فراهم می‌کند یا خیر.

علاوه بر این، ایجاد خطاهای عمدی—مانند ارسال JSON ناقص به یک endpoint یا یک ID اشتباه در پارامتر مسیر—اغلب باعث نمایش Stack Trace یا مسیرهای فایل یا خطاهای ORM می‌شود. این نشت‌ها، reconnaissance یا شناسایی رایگان برای هر کسی فراهم می‌کند که در حال کاوش در اپلیکیشن شماست تا نام جداول و ستون‌های داخلی شما را بفهمد.

از نظر انطباق قانونی (Compliance)، بسیاری از قالب‌های هوش مصنوعی با ابزارهای تحلیل داده داخلی عرضه می‌شوند. اگر Google Analytics یا Meta Pixel یا یک ضبط‌کننده نشست (Session Recorder) پیش از اینکه کاربر روی چیزی کلیک کند فعال شوند، شما در اتحادیه اروپا با مشکل رضایت (Consent) مواجه هستید. همچنین بارگذاری فونت‌های گوگل از CDN، آی‌پی بازدیدکنندگان را به کشور ثالث می‌فرستد. یک دادگاه آلمانی در سال ۲۰۲۲ دقیقاً روی این موضوع حکم داد که منجر به موجی از نامه‌های هشدار قانونی شد؛ راهکار درست، میزبانی شخصی (Self-hosting) فونت‌ها است.

پرداخت نهایی و استانداردهای قانونی

باقی ماندن عبارات پیش‌فرض (Boilerplate) مثل "Create Next App" در عنوان صفحه یا نبود تصویر Open Graph، سیگنالی از عدم بازبینی است. اگرچه این‌ها آسیب‌پذیری فنی مستقیم نیستند، اما نحوه قضاوت پژوهشگران امنیتی درباره محصول شما را تغییر می‌دهند و به آن‌ها می‌فهمانند که این سایت احتمالاً ارزش بررسی و نفوذ را دارد.

برای کاربران در آلمان یا اتریش، داشتن Impressum (اطلاعات مالکیت قانونی) و یک سیاست حریم خصوصی دقیق (که دقیقاً توضیح دهد چه داده‌هایی جمع‌آوری می‌شود) الزامی است. این‌ها رایج‌ترین موارد فراموش‌شده هستند چون پرامپت‌های هوش مصنوعی به‌ندرت آن‌ها را درخواست می‌کنند و این موارد «کسل‌کننده» تلقی می‌شوند.

این حجم از آسیب‌پذیری، محصول جانبی گردش کار Vibe Coding است؛ جایی که توسعه‌دهنده به‌جای بازبین، فقط یک هماهنگ‌کننده (Orchestrator) است. وقتی AI اسکلت پروژه را می‌سازد، اغلب الزامات غیرعملکردی (Non-functional requirements) مربوط به امنیت و قانون را نادیده می‌گیرد.

برای کسانی که محصولات ساخته‌شده با هوش مصنوعی را عرضه می‌کنند، این یک «بدهی فنی» (Technical Debt) جدید است. این یک اتفاق یک‌باره نیست؛ هر ویژگی جدیدی که توسط AI اضافه شود، می‌تواند دوباره همین نشت‌ها را ایجاد کند. یک بررسی تک‌مرحله‌ای کافی نیست؛ باید پیش از هر استقرار معنادار، یک خود-ارزیابی (Self-audit) انجام شود.

گام بعدی شما

برای ایمن‌سازی اپلیکیشن خود، می‌توانید یک خود-ارزیابی ۱۵ دقیقه‌ای انجام دهید:

• یک حلقه curl ساده بنویسید تا مسیرهای .env و .git/HEAD و .git/config و مسیرهای دیباگ را چک کنید؛ هر پاسخ ۲۰۰ OK در این مسیرها یک یافته امنیتی است.
• هدرهای پاسخ سرور خود را برای نبود سیاست‌های امنیتی (CSP و HSTS) بررسی کنید.
• کلیدهای service_role را در کد کلاینت جست‌وجو کرده و در صورت یافتن، فوراً آن‌ها را به متغیرهای محیطی سرور منتقل کنید.

نتایج خود را در سه دسته قرار دهید: «توقف» (افشای اسرار/کلیدهای service_role)، «تکرار» (نبود هدرها/نقشه‌های منبع/عبارات پیش‌فرض) یا «حرکت» (همه چیز پاک‌نظامی است).

افشاگری: من در decivo کار می‌کنم، جایی که ما این بازبینی را از طریق ابزاری رایگان به نام Vibe Code Rescue ارائه می‌دهیم که بر اساس این بررسی‌های خارجی، حکم Go / Iterate / Stop را صادر می‌کند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.