خطرات امنیتی Vibe Coding؛ وقتی کدی که کار میکند لزوماً کد امنی نیست
ریسکهای امنیتی کدنویسی با هوش مصنوعی: Backdoor، Injection، نشت Secret، اشتباه AuthN/AuthZ و وابستگیهای خطرناک — با منابع OWASP، CWE، GitHub و NIST SSDF.
بنیانگذار و مهندس محصول
Vibe Coding یعنی با کمک مدلهای زبانی و ابزارهای تولید کد، سریع به یک نسخهٔ قابلاجرا برسید: درخواست را مینویسید، پیشنهاد را میپذیرید، و وقتی صفحه بالا میآید یا تست دود (Smoke Test) سبز میشود، حس میکنید کار تمام است. این سرعت واقعی است؛ اما معیار «کار میکند» با معیار «در برابر سوءاستفاده مقاوم است» یکی نیست.
بیشتر آسیبپذیریهای وب از همین فاصله بیرون میآیند: ورودی کاربر با فرمان یکی شده، دسترسی فقط روی رابط کاربری چک شده، کلید در مخزن رفته، یا بستهای قدیمی/مشکوک وارد پروژه شده است. فهرست OWASP Top 10 و چارچوبهایی مثل NIST SSDF دقیقاً برای همین فاصله نوشته شدهاند: کاهش آسیبپذیری در چرخهٔ توسعه، نه بعد از رخداد.
این متن فهرست رخداد ساختگی یا CVE جعلی نیست. تعریفها را از OWASP، CWE و مستندات GitHub میگیرد و نشان میدهد همان ریسکها در کد تولیدشده با AI چگونه ظاهر میشوند و قبل از استقرار چه چیزهایی را باید بررسی کنید.
پاسخ کوتاه
کد تولیدشده با هوش مصنوعی اغلب الگوی درست را تقلید میکند و مسیر خوشبینانه را کامل میکند؛ مسیرهای خصمانه، مرز اعتماد، و سیاست دسترسی را کمتر پوشش میدهد. نتیجه میتواند اپلیکییشنی باشد که دمو را پاس میکند و در عین حال در برابر Injection، دور زدن Authorization، نشت Secret یا وابستگی ناامن باز است.
حداقل کار عملی: هر تغییری را مثل کد یک همکار تازهکار بازبینی کنید؛ ورودی را از فرمان جدا نگه دارید؛ Authentication را با Authorization قاطی نکنید؛ Secret را از مخزن و از پرامپت دور کنید؛ و موجودی وابستگیها را پایش کنید. Secret scanning و push protection در GitHub، و تمرینهای SSDF در NIST، ابزار و چارچوب همین عادتاند — جایگزین فکر کردن نیستند.
اگر فقط پرسیدید «کار میکند؟» و نپرسیدید «چه کسی با چه ورودیای میتواند آن را بشکند؟»، هنوز بازبینی امنیتی نکردهاید.
چرا Vibe Coding ریسک امنیتی را جابهجا میکند؟
مدلها روی حجم عظیمی از کد عمومی آموزش دیدهاند؛ بخش زیادی از آن کد «نمونهٔ آموزشی» است نه الگوی سختشده برای تولید. وقتی از ابزار میخواهید «یک API لاگین سریع» یا «فرم نظرات با ذخیره در دیتابیس» بسازد، معمولاً مسیر موفق را کامل میکند: ثبت، خواندن، نمایش. کمتر بهصورت پیشفرض میپرسد: آیا پارامترها parameterized هستند؟ آیا مالکیت رکورد روی سرور چک میشود؟ آیا کلید در فایل env مانده و به گیت نرفته؟
NIST در Secure Software Development Framework (SSDF، SP 800-218) تأکید میکند تمرینهای امن باید داخل SDLC بیایند: آمادهسازی سازمان، محافظت از اجزا، تولید نرمافزار امنتر، و پاسخ به آسیبپذیری. برای تیم کوچکی که با AI کد مینویسد، ترجمهٔ عملی SSDF این است: محیط امن، بازبینی، تست کنترل دسترسی، مدیریت Secret، و موجودی وابستگی — نه اینکه «بعداً اگر وقت شد».
ریسک دیگر، اعتماد بیش از حد به ظاهر کد است. اگر diff را نخوانید، ممکن است مسیر پنهان، حساب سختکد، یا فراخوانی خارجی ناخواسته را از دست بدهید. این موضوع را در بخش Backdoor با تعریف CWE جدا میکنیم تا با شایعه قاطی نشود.
جدول ریسکها: ظاهر در کد AI و چکلیست بررسی
| ریسک | چگونه در کد AI دیده میشود | چه چیزی را چک کنید |
|---|---|---|
| Backdoor / قابلیت پنهان | مسیر دیباگ، حساب ثابت، ارسال داده به مقصد ناشناس، پرچم مخفی در env | هر مسیر و شرط غیرمستند؛ خروجی شبکه؛ حسابهای hard-coded |
| Injection (SQL/XSS/…) | رشتهٔ SQL با الحاق؛ رندر خام HTML از ورودی کاربر | Parameterized query؛ encode خروجی؛ عدم اعتماد به ORM خام |
| Secret Leakage | کلید در کد، .env کامیتشده، Secret در لاگ یا پرامپت | gitignore؛ secret scanning؛ push protection؛ چرخش کلید |
| AuthN ≠ AuthZ | فقط «لاگین شده» چک میشود؛ IDOR با عوض کردن id | چک مالکیت روی سرور برای هر درخواست حساس |
| Dependency Risk | نصب بسته با نام شبیه؛ قفلنشدن نسخه؛ کتابخانهٔ بدون نگهداری | منبع رسمی؛ SCA؛ حذف وابستگی بلااستفاده |
Backdoor را دقیق تعریف کنید — بدون داستان جعلی
در گفتوگوی روزمره «بکدور» اغلب یعنی هر چیزی که مهاجم از آن وارد میشود. در طبقهبندی ضعفها، باید دقیقتر بود. CWE-912 (Hidden Functionality) میگوید محصول قابلیتای دارد که در مشخصات/مستندات نیست، برای کاربر یا مدیر آشکار نیست، و از مسیر رابط معمولی دیده نمیشود. این قابلیت میتواند عمداً مخرب باشد، «Easter Egg» باشد، یا میانبر توسعهدهنده مثل حساب سختکد برای پشتیبانی.
CWE-506 (Embedded Malicious Code) زیرمجموعهٔ مرتبط است و به کد مخرب تعبیهشده اشاره میکند؛ در مستندات CWE از نامهایی مثل Trojan، trapdoor و logic-bomb هم یاد شده است. نکتهٔ مهم برای Vibe Coding: لازم نیست مدل «عمداً مهاجم» باشد تا قابلیت پنهان وارد شود. کافی است در نمونهٔ آموزشی یک مسیر دیباگ یا توکن ثابت بوده باشد و شما بدون خواندن diff آن را بپذیرید.
این مقاله رخداد ساختگی اختراع نمیکند. اگر جایی ادعای نفوذ با بکدور شنیدید، منبع باید شناسهٔ CVE معتبر یا گزارش فنی قابلراستیآزمایی داشته باشد — نه نقل قول شبکههای اجتماعی. کار شما قبل از استقرار: پوشش مسیرها را با تست و بازبینی بسنجید؛ هر شرطی که فقط با هدر مخفی یا پارامتر جادویی فعال میشود را حذف یا مستند و محافظت کنید؛ و یکپارچگی بستهها را از منبع رسمی بگیرید (همراستا با توصیهٔ OWASP دربارهٔ اجزای شخص ثالث).
نشانههای عملی در بازبینی
- مسیر یا متد API که در OpenAPI/مستند نیست اما در کد هست.
- کاربر/رمز ثابت در سورس برای «فقط لوکال» که بدون گارد محیطی مانده.
- ارسال لاگ یا دادهٔ کاربر به دامنهٔ ناشناس.
- شاخهٔ if که با مقدار مخفی در query یا header باز میشود.
Injection: OWASP A03، SQL Injection و XSS
در OWASP Top 10:2021، Injection در جایگاه A03 است. تعریف خلاصه: وقتی دادهٔ تأمینشده توسط کاربر بدون اعتبارسنجی/پالایش وارد مفسر میشود، یا کوئری پویا بدون جداسازی داده و فرمان ساخته میشود. CWEهای شاخص شامل CWE-89 (SQL Injection) و CWE-79 (XSS) هستند. OWASP میگوید بهترین تشخیص اغلب بازبینی سورس است؛ ابزارهای SAST/DAST/IAST در CI کمک میکنند اما جایگزین فهم مرز داده/فرمان نیستند.
SQL Injection در پیشنهادهای AI
الگوی خطرناک کلاسیک اتصال رشته است: ساخت SELECT با چسباندن پارامتر درخواست به متن SQL. OWASP SQL Injection Prevention Cheat Sheet دفاع اصلی را parameterized query (Prepared Statement) میداند؛ گزینههای دیگر مثل stored procedure امن و allow-list برای نام جدول/ستون وقتی bind ممکن نیست. Escape بهتنهایی شکننده است و برای پروژهٔ جدید توصیهٔ اول نیست.
در Vibe Coding این الگو زیاد دیده میشود چون در آموزشهای قدیمی رایج است و «سریع کار میکند». حتی با ORM، اگر خامکوئری یا HQL با الحاق رشته بنویسید، همان ریسک برمیگردد — OWASP در A03 و در cheat sheet به این نکته اشاره کرده است.
XSS: ورودی به خروجی HTML بدون encode
طبق OWASP، حملهٔ Cross-Site Scripting نوعی Injection است که اسکریپت مخرب از طریق اپلیکیشن به مرورگر کاربر دیگر میرسد. وقتی ورودی در پاسخ پویا بدون اعتبارسنجی/کدگذاری مناسب قرار گیرد، مرورگر آن را از «منبع قابل اعتماد» اجرا میکند؛ پیامد میتواند سرقت نشست، تغییر محتوا، یا هدایت کاربر باشد. انواع رایج: Reflected، Stored، و DOM-based.
ابزار AI اگر «کامنت را همانطور که هست در صفحه نشان بده» را پیاده کند، ممکن است HTML خام را رندر کند. چک عملی: هر خروجی کاربرمحور encode متناسب با زمینه (HTML/Attribute/JS/URL)؛ ترجیح کتابخانهٔ قالب امن؛ و اجتناب از innerHTML روی دادهٔ خارجی.
Injection یعنی مرز داده و فرمان شکسته است — چه در SQL، چه در HTML، چه در فرمان سیستمعامل.
Secret Leakage: از کامیت تا push protection
Secret یعنی هر اعتبارنامهای که اگر افشا شود دسترسی غیرمجاز میدهد: API key، توکن ابری، رمز دیتابیس، کلید خصوصی. مستندات GitHub دربارهٔ secret scanning میگوید وقتی اینها بهصورت hard-coded در تاریخچهٔ گیت بروند، هدف سوءاستفاده میشوند. اسکن میتواند کل تاریخچه، Issue، PR، Discussion و ویکی را پوشش دهد؛ در مخازن عمومی بهصورت پیشفرض فعال است و برای جلوگیری از «secret sprawl» طراحی شده است.
Push protection لایهٔ پیشگیرانه است: بهجای هشدار بعد از واقعه، pushای که Secret شناختهشده دارد را قبل از ورود به مخزن مسدود میکند — از CLI، UI، آپلود فایل و برخی مسیرهای API. اگر دور زده شود، بسته به دلیل، هشدار و رد ممیزی ثبت میشود. اینها جایگزین چرخش کلید بعد از نشت نیستند؛ سرعت کشف و جلوگیری را بالا میبرند.
در Vibe Coding سه مسیر نشت رایج است: (۱) مدل کلید را داخل کد نمونه میگذارد چون در پرامپت یا فایل باز بوده؛ (۲) فایل .env بدون gitignore کامیت میشود؛ (۳) Secret در لاگ خطا یا پیام چت ابزار میماند. قانون ساده: Secret را در متغیر محیطی نگه دارید، هرگز در پرامپت عمومی paste نکنید، و قبل از اولین push اسکن را جدی بگیرید.
Authentication در برابر Authorization
OWASP Authentication Cheat Sheet تعریف میکند: Authentication (AuthN) یعنی تأیید هویت ادعاشده با اعتبارسنجهایی مثل رمز یا توکن. Authorization جدا است: تأیید اینکه آن هویت اجازهٔ عمل یا منبع مشخص را دارد. Cheat Sheet مجوز (Authorization) صریحاً میگوید کاربر احراز هویتشده لزوماً مجاز به همهٔ منابع نیست؛ و بعضی منابع عمومی حتی بدون AuthN مجازند.
در OWASP Top 10:2021، Broken Access Control در A01 بالاترین رخداد را در مجموعهٔ دادهها داشته است. نمونههای کلاسیک: دور زدن چک با دستکاری URL یا شناسه (IDOR)، نبود کنترل روی متدهای POST/PUT/DELETE، ارتقای نقش، دستکاری JWT/کوکی، و force browsing به صفحهٔ ادمین. پیشگیری رسمی: deny by default روی سرور، مکانیزم یکپارچه، مالکیت رکورد، و تست واحد/یکپارچه برای کنترل دسترسی.
اشتباه رایج در کد AI: middleware فقط «آیا توکن معتبر است؟» را چک میکند و سپس GET به شناسهٔ سفارش هر سفارشی را برمیگرداند. کاربر لاگینشده است (AuthN موفق) اما مالک آن id نیست (AuthZ شکست). چکلیست: برای هر عملیات حساس، روی سرور نقش/مالکیت/ویژگی را دوباره ارزیابی کنید؛ به مخفیبودن id تکیه نکنید؛ و هرگز کنترل دسترسی را فقط در فرانتاند نگذارید.
ریسک وابستگی: بستهٔ قدیمی، بدون نگهداری، یا مخرب
OWASP A06:2021 (Vulnerable and Outdated Components) میگوید اگر نسخهٔ اجزای مستقیم و تو در تو را نمیشناسید، اگر پایش آسیبپذیری ندارید، یا اگر بهروزرسانی را دیر انجام میدهید، احتمالاً آسیبپذیرید. توصیهٔ پیشگیری: حذف وابستگی بلااستفاده، موجودی پیوسته، استفاده از منبع رسمی و ترجیحاً بستهٔ امضاشده، و توجه به کتابخانههای بدون نگهداری. خود OWASP یادآوری میکند نقص در جزء میتواند تصادفی یا عمدی (مثلاً بکدور در یک جزء) باشد.
در اکوسیستم AI-assisted، نصب بستهای که مدل پیشنهاد کرد بدون خواندن نام بسته، یکی از سریعترین راههای وارد کردن ریسک است: typosquatting، نسخهٔ قفلنشده، یا بستهٔ متروک. کار حداقلی: قفل وابستگی (lockfile)، بررسی نام و ناشر، اجرای Software Composition Analysis در CI، و نخواندن «آخرین نسخه» بهعنوان مترادف «امن».
حداقل فرایند امن کنار Vibe Coding
نیازی نیست از روز اول برنامهٔ AppSec سازمانی کامل داشته باشید. یک حلقهٔ کوتاه کافی است تا فاصلهٔ «کار میکند» و «قابل دفاع است» کم شود:
- قبل از پذیرش پیشنهاد بزرگ: diff را بخوانید؛ مسیرهای جدید، دسترسی شبکه، و فایلهای پیکربندی را علامت بزنید.
- برای ورودی کاربر: فرض کنید خصمانه است؛ parameterized query و encode خروجی را اجباری کنید.
- برای هر API حساس: تستی بنویسید که کاربر A به دادهٔ کاربر B نرسد.
- قبل از push: Secret در staged changes نباشد؛ push protection و secret scanning روشن باشد.
- بعد از وابستگی جدید: منبع، مجوز، و سابقهٔ نگهداری را در یک دقیقه بررسی کنید.
- قبل از production: حداقل یک مرور کنترلهای ورودی، نشست و دسترسی (همراستا با روح OWASP ASVS) را چکلیست کنید.
SSDF این عادتها را در زبان «تمرین و نتیجه» صورتبندی میکند؛ OWASP Top 10 زبان «ریسک پرتکرار وب» را میدهد. هر دو برای تصمیمگیریاند، نه برای ترسیدن از ابزار AI. ابزار سرعت میدهد؛ مسئولیت مرز اعتماد با کسی است که دکمهٔ merge را میزند.
جمعبندی برای تصمیم
Vibe Coding خطرناک نیست چون «هوش مصنوعی شرور است»؛ خطرناک میشود وقتی معیار پذیرش فقط اجرای خوشمسیر باشد. Backdoor را با تعریف CWE بفهمید نه با شایعه. Injection را با جداسازی داده/فرمان ببندید. Secret را از تاریخچهٔ گیت دور نگه دارید. AuthN را با AuthZ اشتباه نگیرید. وابستگی را مثل کد خودتان جدی بگیرید.
اگر همین هفته یک کار میکنید: روی مخزن push protection و secret scanning را بررسی کنید، یک endpoint حساس را برای IDOR تست کنید، و آخرین PR تولیدشده با AI را فقط از زاویهٔ جدول ریسک این مقاله بخوانید.
برای ادامه، جزئیات احراز هویت و مجوز، مدیریت Secret، و عادت ندادن کلید به مدل را در مقالات مرتبط سری بخوانید؛ این صفحه نقشهٔ ریسک است نه جایگزین بازبینی تخصصی روی سیستم پرداخت یا دادهٔ سلامت.
منابع و مراجع
- OWASP Top 10:2021 — A03 Injection — https://owasp.org/Top10/2021/A03_2021-Injection/
- OWASP Top 10:2021 — A01 Broken Access Control — https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
- OWASP Top 10:2021 — A06 Vulnerable and Outdated Components — https://owasp.org/Top10/2021/A06_2021-Vulnerable_and_Outdated_Components/
- OWASP — Cross Site Scripting (XSS) — https://owasp.org/www-community/attacks/xss/
- OWASP Cheat Sheet — SQL Injection Prevention — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
- OWASP Cheat Sheet — Authentication — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- OWASP Cheat Sheet — Authorization — https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
- CWE-912: Hidden Functionality — https://cwe.mitre.org/data/definitions/912.html
- CWE-506: Embedded Malicious Code — https://cwe.mitre.org/data/definitions/506.html
- GitHub Docs — About secret scanning — https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
- GitHub Docs — Push protection — https://docs.github.com/en/code-security/secret-scanning/protecting-pushes-with-secret-scanning
- NIST — Secure Software Development Framework (SSDF) / SP 800-218 — https://csrc.nist.gov/Projects/ssdf
نویسنده
بنیانگذار و مهندس محصول
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.