چک‌لیست امنیت برای اپ‌های ساخته‌شده با هوش مصنوعی: پیش از انتشار چه چیزی را بررسی کنیم

پیش از اینکه افراد واقعی از اپی که با هوش مصنوعی ساخته‌اید استفاده کنند، هفت مورد را بررسی کنید: هر صفحه و هر API تعیین می‌کند کاربر کیست و چه کاری مجاز است انجام دهد؛ کلیدهای محرمانه فقط روی سرور نگهداری می‌شوند، نه در مرورگر یا گفتگو؛ تمام ورودی‌ها روی سرور اعتبارسنجی می‌شوند؛ هر کاربر فقط به رکوردهای خودش دسترسی دارد؛ ورود و نقاط پرهزینه محدودیت نرخ دارند؛ وابستگی‌ها به‌روز هستند؛ و در صورت بروز مشکل می‌توانید داده‌ها را بازیابی کنید. چک‌لیست زیر هر کدام از این موارد را به آزمون‌های مشخصی تبدیل می‌کند که بدون خواندن کد قابل اجرا هستند.

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

نحوه استفاده از این چک‌لیست

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

• الزامی — پیش از استفاده هر کس دیگری از اپ انجام شود.
• توصیه‌شده — پیش از داشتن کاربران واقعی یا داده واقعی انجام شود.
• بعداً — وقتی اپ رشد می‌کند ارزش انجام دارد.

اگر فقط یک ساعت وقت دارید، همه موارد الزامی را انجام دهید.

۱. احراز هویت: این شخص کیست؟

احراز هویت یعنی تأیید اینکه فردی کیست، معمولاً از طریق ورود. برای مبانی به احراز هویت چیست و برای گزینه‌ها به نحوه افزودن ورود به اپ مراجعه کنید.

• الزامی: هر صفحه‌ای که داده خصوصی نشان می‌دهد نیاز به ورود دارد. آزمایش: خارج شوید، سپس نشانی یک صفحه خصوصی را مستقیم در مرورگر وارد کنید.
• الزامی: هر نقطه API پشت آن صفحات هم نیاز به ورود دارد، نه فقط خود صفحه. آزمایش: خارج شوید، تب شبکه مرورگر را باز کنید و درخواستی را که اپ وقتی وارد بودید فرستاده بود دوباره اجرا کنید.
• الزامی: گذرواژه‌ها با یک الگوریتم هش کندِ مخصوص گذرواژه ذخیره می‌شوند، هرگز متن ساده. راهنمای ذخیره گذرواژه در OWASP ابتدا Argon2id را توصیه می‌کند و scrypt، bcrypt یا PBKDF2 را به‌عنوان جایگزین. بپرسید: «گذرواژه‌ها چگونه ذخیره می‌شوند؟»
• توصیه‌شده: لینک‌های بازنشانی گذرواژه منقضی می‌شوند و فقط یک بار کار می‌کنند.
• توصیه‌شده: کوکی‌های نشست با Secure، HttpOnly و SameSite علامت‌گذاری شده‌اند و خروج، نشست را روی سرور پایان می‌دهد.
• بعداً: احراز هویت دو مرحله‌ای ارائه دهید، یا ورود از طریق ارائه‌دهنده‌ای که آن را دارد.

هر مسیر API و هر صفحه‌ای را که داده کاربر برمی‌گرداند بررسی کنید. هر کدام باید درخواست کاربران واردنشده را روی سرور رد کند، نه فقط در کد صفحه. مسیرهایی را که بررسی کرده‌اید فهرست کنید.

۲. مجوزدهی: مجاز به انجام چه کارهایی هستند؟

مجوزدهی مرحله بعد از ورود است: تعیین اینکه این کاربر مشخص اجازه دیدن و تغییر چه چیزی را دارد. اپ‌های ساخته‌شده با هوش مصنوعی اغلب در همین بخش حفره‌های جدی دارند، چون اپ «درست» به نظر می‌رسد — داشبورد هر کاربر فقط داده خودش را نشان می‌دهد — در حالی که اگر کسی مستقیم درخواست کند، سرور داده هر کسی را بی‌چون‌وچرا تحویل می‌دهد.

• الزامی: هر خواندن، به‌روزرسانی و حذف روی سرور بررسی می‌کند که رکورد متعلق به کاربر فعلی (یا تیم او) است.
• الزامی: آزمایش کنید: دو حساب A و B بسازید. با A یکی از رکوردهای A را باز کنید و شناسه آن را در نشانی یا درخواست شبکه یادداشت کنید. با B وارد شوید و همان شناسه را درخواست کنید. B باید خطا بگیرد، نه داده A.
• الزامی: صفحات مدیریتی و نقاط API مدیریتی نقش کاربر را روی سرور بررسی می‌کنند. پنهان کردن لینک مدیریت محافظت نیست.
• الزامی: کاربران با ویرایش درخواست نمی‌توانند نقش، قیمت، موجودی یا فیلدهای مالک خودشان را تغییر دهند. آزمایش: در تب شبکه ببینید به‌روزرسانی پروفایل چه چیزی می‌فرستد. اگر فیلدهایی مانند role یا isAdmin دارد، از هوش مصنوعی بخواهید آن‌ها را از سمت کلاینت نادیده بگیرد.
• توصیه‌شده: شناسه‌های داخل نشانی‌ها سخت حدس زده شوند (شناسه تصادفی به‌جای ۱، ۲، ۳). این جایگزین بررسی دسترسی نیست، اما وقتی بررسی‌ای جا افتاده باشد، آسیب را محدود می‌کند.

برای هر نقطه‌ای که رکوردی را می‌خواند یا تغییر می‌دهد، روی سرور بررسی کنید که کاربر واردشده مالک آن است یا اجازه دسترسی دارد. اگر نه، ۴۰۴ برگردانید. سپس نشان دهید با دو حساب چگونه این را آزمایش می‌کنید.

۳. دسترسی سطح ردیف در پایگاه داده

«دسترسی سطح ردیف» یعنی هر ردیف یک جدول (مثلاً یک رزرو یا یک فاکتور) فقط برای کاربرانی قابل‌دیدن است که به آن‌ها تعلق دارد. دو روش رایج برای اعمال آن وجود دارد:

هر دو را می‌توان درست انجام داد. آنچه مهم است:

• الزامی: اگر مرورگر مستقیم با پایگاه داده صحبت می‌کند (برخی محصولات پایگاه داده میزبانی‌شده این را اجازه می‌دهند)، قوانین سطح ردیف برای هر جدول فعال باشد. بدون آن‌ها، هر کسی با کلید عمومی می‌تواند کل جدول را بخواند.
• الزامی: کوئری‌ها بر اساس کاربر یا تیم فعلی فیلتر شوند، نه بر اساس شناسه‌ای که مرورگر می‌فرستد.
• توصیه‌شده: داده مشترک (مثلاً پروژه‌های یک تیم) قاعده روشنی درباره عضویت تیم داشته باشد که در یک جا اعمال شود.

۴. کلیدهای محرمانه و کلیدهای API

کلید API گذرواژه یک سرویس است. Stripe، سرویس‌های ایمیل و ارائه‌دهندگان هوش مصنوعی همه از آن‌ها استفاده می‌کنند. برای پیش‌زمینه، متغیرهای محیطی و رازها چیستند را ببینید.

• الزامی: کلیدها در متغیرهای محیطی یا رازهای پروژه نگهداری می‌شوند و هرگز در کد نوشته نمی‌شوند.
• الزامی: کلیدهایی که می‌توانند هزینه ایجاد کنند یا داده خصوصی بخوانند فقط روی سرور استفاده می‌شوند. آزمایش: سایت زنده را باز کنید، سورس صفحه و فایل‌های JavaScript را در ابزارهای توسعه‌دهنده ببینید و ابتدای کلیدتان را جستجو کنید (مثلاً sk_). نباید ظاهر شود.
• الزامی: کلیدها هرگز در گفتگو، مخزن عمومی یا اسکرین‌شات قرار نگرفته‌اند. اگر قرار گرفته‌اند، آن‌ها را تعویض کنید در ارائه‌دهنده (یک کلید جدید بسازید و کلید قدیمی را حذف کنید).
• توصیه‌شده: در جاهایی که ارائه‌دهنده امکانش را می‌دهد، از کلیدهای محدود یا با دامنه مشخص استفاده کنید. برای مثال Stripe کلیدهای محدودی را توصیه می‌کند که فقط دسترسی‌های لازم یکپارچه‌سازی شما را دارند.
• توصیه‌شده: کلیدهای آزمایشی و زنده جدا باشند و اپ زنده فقط وقتی آماده‌اید از کلیدهای زنده استفاده کند.

برخی کلیدها عمداً عمومی طراحی شده‌اند؛ مثل کلید قابل‌انتشار Stripe (pk_…) یا کلید نقشه که به دامنه شما محدود شده است. قاعده درباره کلیدهایی است که قدرت می‌دهند، نه هر رشته‌ای که شبیه کلید است.

۵. اعتبارسنجی ورودی

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

• الزامی: اعتبارسنجی روی سرور انجام شود، نه فقط در مرورگر. بررسی‌های مرورگر برای راحتی هستند؛ هر کسی می‌تواند از آن‌ها رد شود.
• الزامی: کوئری‌های پایگاه داده از پارامتر استفاده کنند، نه از متنی که از ورودی کاربر به هم چسبانده شده (این جلوی SQL injection را می‌گیرد). از هوش مصنوعی بخواهید تأیید کند.
• الزامی: متنی که کاربران وارد می‌کنند به‌صورت متن نمایش داده شود، نه به‌عنوان HTML اجرا شود. آزمایش: <b>hello</b> را به‌عنوان نام خود وارد کنید. باید خود برچسب‌ها را ببینید، نه متن پررنگ.
• توصیه‌شده: آپلود فایل نوع و حجم را بررسی کند و فایل‌های آپلودشده از دامنه اصلی اپ به‌صورت صفحه قابل‌اجرا سرو نشوند.
• توصیه‌شده: خطاهایی که به کاربر نشان داده می‌شوند ساده باشند («مشکلی پیش آمد»)؛ جزئیات خطا فقط در لاگ‌های سرور ثبت شود.
• توصیه‌شده: وب‌هوک‌های سرویس‌هایی مثل Stripe امضای ارائه‌دهنده را پیش از اقدام بررسی کنند. وب‌هوک چیست را ببینید.

به هر فرم و هر نقطه API اعتبارسنجی سمت سرور اضافه کنید: فیلدهای الزامی، طول‌ها، قالب‌ها و مقادیر مجاز. هر چیز دیگری را با پیام واضح رد کنید. جزئیات داخلی خطا را به کاربران نشان ندهید.

۶. محدودیت نرخ و سوءاستفاده

محدودیت نرخ سقف تعداد درخواست‌هایی است که یک نفر در بازه زمانی مشخص می‌تواند بفرستد. بدون آن، هر کسی می‌تواند تمام روز گذرواژه حدس بزند، فرم ثبت‌نام شما را پر کند یا هزینه یک API پولی را بالا ببرد.

• الزامی: ورود، ثبت‌نام و بازنشانی گذرواژه برای هر آدرس IP و هر حساب محدودیت نرخ دارند.
• الزامی: هر چیزی که به ازای هر فراخوانی برای شما هزینه دارد — درخواست‌های مدل هوش مصنوعی، پیامک، ایمیل — سقف برای هر کاربر دارد و نیاز به ورود است.
• توصیه‌شده: فرم‌های عمومی (تماس، لیست انتظار) حفاظت در برابر اسپم دارند: محدودیت نرخ، فیلد پنهان تله، یا CAPTCHA.
• توصیه‌شده: سقف هزینه یا هشدار را نزد ارائه‌دهندگان پولی تنظیم کنید تا یک باگ یا مهاجم نتواند صورتحساب نامحدود ایجاد کند.

۷. وابستگی‌ها

اپ‌ها از بسته‌های متن‌باز ساخته می‌شوند و بسته‌ها گاهی آسیب‌پذیری شناخته‌شده دارند.

• توصیه‌شده: از هوش مصنوعی بخواهید آسیب‌پذیری‌های شناخته‌شده را بررسی کند (برای پروژه‌های JavaScript، npm audit یا معادل آن در مدیر بسته شما) و بسته‌های آسیب‌دیده را به‌روز کند.
• توصیه‌شده: بسته‌هایی را که اپ دیگر استفاده نمی‌کند حذف کنید.
• توصیه‌شده: نسبت به بسته‌هایی که کاربر بسیار کم دارند یا نامشان شبیه غلط‌املایی بسته‌های محبوب است، محتاط باشید.
• بعداً: هر یکی دو ماه دوباره بررسی کنید، یا اگر کدتان در GitHub است، هشدارهای خودکار را روشن کنید.

۸. پشتیبان‌گیری و بازیابی

امنیت شامل توانایی بازگشت از اشتباه است — اشتباه خودتان، اشتباه هوش مصنوعی یا حمله مهاجم.

• الزامی: بدانید داده‌تان کجا نگهداری می‌شود و آیا پشتیبان دارد. فرض نکنید؛ مستندات میزبان خود را بررسی کنید.
• توصیه‌شده: خروجی دوره‌ای خودتان از داده‌های مهم را نگه دارید (مثلاً امکان خروجی CSV یا dump پایگاه داده) و جای جدا ذخیره کنید.
• توصیه‌شده: کدتان را در کنترل نسخه نگه دارید تا هر نسخه‌ای قابل بازیابی باشد.
• توصیه‌شده: اقدامات مخرب (حذف حساب، حذف پروژه) تأیید بخواهند و «حذف نرم» را در نظر بگیرید که برای مدتی قابل برگشت باشد.
• بعداً: یک بار واقعاً بازیابی را امتحان کنید. پشتیبانی که هرگز بازیابی نشده، یک امید است، نه یک برنامه.

۹. پیش از انتشار

• الزامی: سایت زنده همه‌جا از HTTPS استفاده کند.
• الزامی: داده نمونه، حساب‌های آزمایشی و صفحات اشکال‌زدایی توسعه حذف شده باشند.
• توصیه‌شده: سیاست حریم خصوصی بگوید چه داده‌ای جمع می‌کنید و چرا — در بسیاری از کشورها اگر داده شخصی جمع می‌کنید الزامی است. گواهینامه‌هایی (SOC 2، HIPAA) را که ندارید ادعا نکنید.
• توصیه‌شده: راهی برای تماس درباره مسائل امنیتی داشته باشید و بدانید چگونه همه کلیدها را سریع تعویض کنید.

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

چه زمانی بررسی حرفه‌ای بگیریم

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

امنیت هنگام ساخت روی Mythex

Mythex پنل اسکن امنیتی ندارد، پس چک‌لیست بالا همان فرایندی است که باید دنبالش کنید. چند چیز که کمک می‌کند:

• رازهای پروژه. کلیدها را در تنظیمات پروژه ← Secrets نگه دارید، یا از کارت رازهایی که عامل در گفتگو نشان می‌دهد استفاده کنید، تا در کد و پیام‌ها نباشند. پس از تغییر یک راز برای اپ زنده، دوباره منتشر کنید.
• حالت‌های Plan و Ask. از عامل بخواهید بدون ویرایش دسترسی‌ها را بررسی کند: «در حالت Ask، هر مسیر API و بررسی دسترسی‌اش را فهرست کن.»
• /test باعث می‌شود عامل پیش‌نمایش شما را مثل یک کاربر بگردد — برای آزمایش دو حسابی بخش ۲ مفید است.
• Checkpoints اجازه می‌دهند تغییری را که چیزی را خراب کرده برگردانید.

به امنیت اپ‌هایی که می‌سازید و متغیرهای محیطی و رازها در مستندات مراجعه کنید. اگر در ادامه حساب کاربری اضافه می‌کنید، نحوه افزودن ورود به اپ را بخوانید.

پرسش‌ها