اگر امروز یک اپلیکیشن هوش مصنوعی میسازید که محتوای تولیدشده توسط مدل را مستقیماً در مرورگر نمایش میدهد، احتمالاً یک درِ پشتی باز برای هکرها ایجاد کردهاید. در عصر هوش مصنوعی زاینده، مرورگر دیگر فقط پنجرهای برای دیدن وبسایت نیست، بلکه محیطی پرخطر برای اجرای کدهای پیچیده است.
به نقل از راهنمای معماری dev.to که در ۵ سپتامبر ۲۰۲۶ منتشر شد، بسیاری از توسعهدهندگان هنوز فرانتاند را صرفاً لایه نمایش میبینند که این یک اشتباه استراتژیک و خطرناک است. اکثر توسعهدهندگان تصور میکنند فرانتاند منطقهای امن برای منطق رابط کاربری (UI Logic) است، اما اپلیکیشنهای هوش مصنوعی بردارهای حمله جدیدی را معرفی میکنند. این برنامهها با میکروفون، دوربین و فایلهای رسانهای حجیم سر و کار دارند، در حالی که جاوااسکریپتهای پیچیده و مدلهای محلی هوش مصنوعی را اجرا میکنند. آنها با APIهای هوش مصنوعی تعامل دارند، محتوای تولیدشده را نمایش میدهند، وضعیت احراز هویت را حفظ میکنند و از پایگاههای داده مرورگر مانند IndexedDB استفاده میکنند. این تغییر به این معناست که مرورگر اکنون به یک مرز امنیتی اصلی تبدیل شده است که میتواند توسط کاربر دستکاری شود یا توسط خروجیهای مخرب هوش مصنوعی به خطر بیفتد.
مدل اعتماد و مجوزها
یک قاعده بنیادین در معماری امن این است که مرورگر محیطی «نیمهاعتماد» است. شما باید فرض کنید هر چیزی که در مرورگر کاربر اجرا میشود، در نهایت تحت کنترل اوست. بنابراین، فرانتاند باید مسئول تجربه کاربری و لایههای دفاعی اولیه (Defense-in-Depth) باشد، اما سرور باید تنها مرجع نهایی برای تمام عملیات حساس باقی بماند.
یک شکست رایج، سپردن تصمیمات امنیتی منحصراً به کدهای فرانتاند است. برای مثال، استفاده از چکهایی مانند if (user.role === "admin") { showAdminPanel(); } تنها روی قابلیت مشاهده (Visibility) کنترل دارد و هیچ احرازی برای مجوزها (Authorization) ایجاد نمیکند. یک سیستم امن نیاز به هر دو لایه احراز هویت در فرانتاند و بکاند دارد تا یک لایه دفاعی واقعی ایجاد شود. بکاند باید پیش از اجرای هر عملیات دارای امتیاز ویژه، مجوز کاربر را بهطور مستقل تأیید کند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، جابهجایی منطق از سرور به کلاینت همیشه ریسک نشت داده را افزایش میدهد.
مدلسازی تهدیدات فرانتاند
طبق گزارش dev.to، یک مدل جامع تهدیدات فرانتاند برای هوش مصنوعی باید چهار دسته اصلی از ریسکها را در نظر بگیرد:
- تهدیدات ورودی: متنهای مخرب، HTMLهای غیرمجاز، انواع فایلهای غیرمنتظره، آپلودهای با حجم بیش از حد، رسانههای بدشکل (Malformed) و متادیتای خطرناک.
- تهدیدات مرورگر: حملات XSS (تزریق کد)، CSRF، کلیکجکینگ (Clickjacking)، افزونههای مخرب مرورگر، ذخیرهسازی ناامن و وابستگیهای (dependencies) آلوده.
- تهدیدات شبکه: اتصالات ناامن، پیکربندی غلط CORS، نشت توکنها و دسترسیهای غیرمجاز به API.
- تهدیدات خاص هوش مصنوعی: تزریق پرامپت (Prompt Injection)، محتوای آپلودشده مخرب، محتوای تولیدشده ناامن، خروجیهای مدلهای نامعتبر و دسترسیهای بیش از حد در سمت کلاینت.
دفاع در برابر تهدیدات خاص هوش مصنوعی
برنامههای هوش مصنوعی بهدلیل رندر کردن محتوای تولیدشده، بهشدت در برابر حملات XSS — شبیه به این است که شما نامهای را باز کنید و ناگهان بمبی داخل آن منفجر شود — آسیبپذیر هستند. اگر یک مدل هوش مصنوعی HTML، Markdown، کد یا لینکهایی را برگرداند که مرورگر آنها را به عنوان کد قابل اجرا تفسیر کند، مهاجم میتواند نشست (session) کاربر را برباید.
برای جلوگیری از این اتفاق، توسعهدهندگان باید یک خط لوله رندرینگ سختگیرانه را دنبال کنند:
- تمام خروجیهای هوش مصنوعی را «نامعتبر» بدانید.
- محتوا را تجزیه (Parse) و اعتبارسنجی کنید.
- هر HTML ضروری را پاکسازی (Sanitize) کنید.
- از یک رندرکننده امن استفاده کنید و تا حد امکان متن ساده (plain-text) را ترجیح دهید.
فریمورکهایی مانند React پیشفرضهای امنی دارند، اما توسعهدهندگان میتوانند آنها را دور بزنند. هر مکانیزمی که معادل تزریق مستقیم HTML باشد باید به عنوان ریسک بالا تلقی شود. سیاست باید این باشد: بهصورت پیشفرض متن را امن رندر کن و فقط در موارد استثنایی و پس از اعتبارسنجی، پاکسازی، محدودسازی و بازرسی، اجازه نمایش HTML را بده.
در این میان، سیاست امنیت محتوا (CSP) به عنوان خط دفاع دوم عمل میکند. یک CSP بهخوبی پیکربندی شده، محدود میکند که مرورگر اجازه بارگذاری کدام اسکریپتها، استایلها، تصاویر، اتصالات و فریمها را دارد. یک سیاست مفهومی میتواند شامل default-src 'self', script-src 'self', و connect-src 'self' https://approved-api.example باشد، در حالی که object-src 'none' و frame-ancestors 'none' برای جلوگیری از کلیکجکینگ تنظیم شوند. ارائهدهندگان خارجی هوش مصنوعی، ابزارهای تحلیل، CDNها و سرویسهای احراز هویت ممکن است به منابع اضافی و بهدقت محدودشده نیاز داشته باشند.
امنیت هوش مصنوعی محلی و ذخیرهسازی
انتقال محاسبات هوش مصنوعی به دستگاه کاربر از طریق مدلهای محلی میتواند تأخیر را کم کند، ترافیک سرور را کاهش دهد و حریم خصوصی را برای برخی حجمهای کاری بهبود بخشد. با این حال، این کار بهطور خودکار دادهها را خصوصی نمیکند. مدلهای محلی باید مانند کدهای برنامه و دادهها تلقی شوند و کنترلهای سختگیرانهای روی یکپارچگی مدل، جلوگیری از تخلیه منابع و منشأ مصنوعات مدل (Model Artifacts) اعمال شود. یک معماری امن باید بهطور صریح تعریف کند که چه دادههایی مجاز به خروج از دستگاه هستند. در این راستا، ابزارهایی مانند پروژه SafePrompt برای حذف کلیدهای API از ورودیها میتوانند لایهی اضافهای از امنیت را در سطح دستگاه کاربر فراهم کنند.
برای پردازشهای سنگین، استفاده از Web Workers توصیه میشود تا رابط کاربری قفل نشود. برای حفظ امنیت، این ورکرها نباید کل وضعیت (state) برنامه را دریافت کنند. در عوض، رشته اصلی (Main Thread) باید پیامهای حداقلی ارسال کند و ورکر تنها نتایج پاکسازیشده را برگرداند. ارتباط بین رشته اصلی و ورکرها باید انواع پیامها را اعتبارسنجی کند (مثلاً بررسی اینکه پیام "resize" حاوی اعداد معتبر برای عرض و ارتفاع باشد) تا از وضعیتهای غیرمنتظره برنامه جلوگیری شود.
در مورد ذخیرهسازی نیز باید از رویکرد لایهای استفاده کرد:
- localStorage: مناسب برای ترجیحات عمومی UI مانند تم، زبان یا چیدمان ادیتور. این مکان یک مخزن امن برای اسرار (Secrets) نیست.
- IndexedDB: مفید برای دادههای ساختاریافته مانند پروژههای ویرایشی موقت، وضعیت آفلاین برنامه، متادیتای کششده رسانهها و پیشنویسهای غیرحساس.
- Cookies: کوکیهای احراز هویت باید حتماً دارای ویژگیهای
Secure(فقط HTTPS)،HttpOnly(جلوگیری از دسترسی JS) وSameSiteباشند تا ریسک CSRF کاهش یابد.
توکنهای حساس احراز هویت هرگز نباید در پارامترهای URL، لاگهای کنسول، عناصر DOM یا دادههای ارسالی به ابزارهای تحلیل قرار گیرند. مدل کوکیهای نشست HttpOnly امن برای کاهش دسترسی مستقیم جاوااسکریپت به اعتبارنامهها ترجیح داده میشود.
خط لوله پردازش رسانه
اپلیکیشنهای هوش مصنوعی مدام با JPEG، PNG، WebP، ویدیو، صدا و PDF سر و کار دارند، اما پسوندهای فایل را بهراحتی میتوان جعل کرد. یک خط لوله امن باید فراتر از نام فایل رفته و یک بررسی چندمرحلهای را اجرا کند:
۱. اعتبارسنجی در فرانتاند برای بازخورد سریع به کاربر.
۲. درگاه آپلود برای اعمال محدودیتهای حجم و احراز هویت.
۳. بررسی Content-Type و تأیید امضای فایل (File Signature) برای تشخیص فرمت واقعی فایل.
۴. اسکن بدافزار در یک محیط ایزوله.
۵. پردازش پاکسازیشده در یک ورکر قرنطینه شده.
ریسک «تخلیه منابع» (Resource Exhaustion) نیز یک خطر بزرگ است. ویدیوهای با رزولوشن بالا یا فایلهای صوتی عظیم میتوانند سرور را متوقف کنند. معماری سیستم باید حداکثر حجم فایل، مدتزمان، رزولوشن، نرخ فریم و زمان پردازش را در سطح API Gateway و ورکرهای پردازشی اعمال کند. این کار از مصرف سوء منابع توسط کدکهای پیچیده یا تعداد فریمهای بیش از حد جلوگیری میکند. برای صدا، این شامل بررسی نرخ نمونهبرداری (Sample Rate) و تعداد کانالها پیش از شروع پردازشهای هزینهبر است.
کتابخانههای پردازش رسانه پیچیده هستند و باید ایزوله شوند. خط لوله باید این جریان را دنبال کند: آپلود $ \rightarrow $ قرنطینه $ \rightarrow $ ورکر پردازش $ \rightarrow $ اعتبارسنجی $ \rightarrow $ تبدیل $ \rightarrow $ خروجی پاکسازیشده. علاوه بر این، رسانههای موقت باید چرخه عمر سختگیرانهای داشته باشند تا دادهها پس از ذخیره نتیجه حذف شوند و از تبدیل ذخیرهسازی موقت به یک آرشیو پنهان دائمی جلوگیری شود.
حریم خصوصی و مدیریت وابستگیها
فرانتاندهای آگاه به حریم خصوصی باید یک خط لوله «حداقلسازی دادهها» را اجرا کنند. پیش از ارسال داده به یک ارائهدهنده خارجی هوش مصنوعی، سیستم باید بپرسد: آیا این داده ضروری است؟ آیا میتوان آن را به حداقل رساند؟ آیا میتوان آن را بهصورت محلی پردازش کرد؟ آیا میتوان متادیتای حساس (مانند مختصات GPS یا اطلاعات دستگاه در تصاویر) را حذف کرد؟
علاوه بر این، برنامه باید مرزهای شفاف حریم خصوصی مرورگر را حفظ کند. اگر دادهای در نهایت به یک سرویس ابری ارسال میشود، نباید به کاربر گفته شود که دادهها «محلی» هستند. شفافیت بخش اصلی امنیت است. برای سازمانهایی که به دنبال کنترل کامل بر دادهها هستند، استفاده از زیرساختهای متنباز در برابر مدلهای بسته راهکاری برای حذف وابستگی به تامینکنندگان ابری و افزایش حریم خصوصی است.
در نهایت، مرز اعتماد به جاوااسکریپتهای شخص ثالث گسترش مییابد. هر اسکریپت تحلیل، رابط پرداخت یا ویجت پشتیبانی، سطح حمله را افزایش میدهد. توسعهدهندگان باید از lockfileها، بررسی نسخهها، اسکن آسیبپذیری و SRI (یکپارچگی زیرمنبع) برای تأیید هش رمزنگاریشده منابع خارجی استفاده کنند. یک گراف وابستگی کوچک بهطور کلی راحتتر ایمن میشود.
امنیت عملیاتی و مدیریت خطا
مدیریت خطا در فرانتاند باید بهدقت مدیریت شود تا از نشت جزئیات حساس پیادهسازی جلوگیری شود. خطاهای محیط عملیاتی باید کلی باشند (مثلاً: «تولید محتوا انجام نشد») در حالی که stack traceهای مفصل، نامهای میزبان داخلی و اسرار ارائهدهندگان در لاگهای کنترلشده سمت سرور باقی بمانند.
ابزارهای توسعه، نقاط انتهایی دیباگ (debug endpoints) و لاگهای مفصل باید در بیلدهای عملیاتی غیرفعال شوند. به همین ترتیب، سازمانها باید تصمیم بگیرند که آیا نقشههای منبع (source maps) عملیاتی باید عمومی باشند یا بهصورت خصوصی ذخیره شوند تا از افشای جزئیات کد برنامه جلوگیری شود. سیاستهای کشینگ (Caching) نیز باید با حساسیت دادهها مطابقت داشته باشد: داراییهای استاتیک عمومی میتوانند بهشدت کش شوند، اما رسانههای تولیدشده خصوصی و دادههای حساب کاربری به کشینگ کنترلشده نیاز دارند تا از نشت حریم خصوصی جلوگیری شود.
طراحی API و وضعیت امن
وضعیت (State) فرانتاند باید دستهبندی شود تا کنترلهای امنیتی مناسب اعمال گردد:
- وضعیت UI: تم، سایدبار و تبهای انتخابشده.
- وضعیت برنامه: پروژه جاری، تنظیمات ادیتور و رسانههای انتخابشده.
- وضعیت سرور: وضعیت تولید، تاریخچه کارهای کاربر و اطلاعات حساب.
- وضعیت حساس امنیتی: بافت احراز هویت و اطلاعات مجوزها.
وضعیتهای حساس امنیتی نیاز به برخورد ویژه دارند. نقشهای ارسالی از سمت کلاینت (مثلاً { "role": "admin" }) هرگز نباید به عنوان مرجع مورد اعتماد باشند. سرور باید مجوزها را از وضعیت معتبر سمت سرور تعیین کند.
درخواستهای API فرانتاند باید صریح باشند. برای یک درخواست تولید محتوا، بکاند باید بهطور مستقل اندازه پرامپت، در دسترس بودن مدل، محدودیتهای رزولوشن، مجوزهای کاربر، سهمیهها (Quotas) و محدودیتهای سیاست را اعتبارسنجی کند. CORS باید برای کنترل اینکه کدام مبدأهای مرورگر مجاز به تعامل با API هستند استفاده شود، تا به عنوان مکمل احراز هویت عمل کند و نه جایگزین آن.
تست امنیت و چرخه حیات
یک چرخه حیات بالغ امنیت فرانتاند مسیری از مدلسازی تهدیدات و طراحی امن تا اعتبارسنجی ورودی، بررسی وابستگیها و نظارت در زمان اجرا را دنبال میکند. تستها باید موارد زیر را پوشش دهند:
- امنیت عملکردی: انقضای نشست، رفتار خروج از حساب و اقدامات غیرمجاز در UI.
- امنیت ورودی: متنهای بدشکل، یونیکدهای غیرمنتظره و فرمتهای رسانهای پشتیبانینشده.
- امنیت مرورگر: CSP، پیکربندی کوکیها و محدودیتهای فریم.
- امنیت هوش مصنوعی: خروجیهای تولیدشده نامعتبر و محتوای تزریق پرامپت.
- حریم خصوصی: ذخیرهسازی مرورگر، کش و یکپارچگیهای شخص ثالث.
اصلاحات امنیتی باید به تستهای رگرسیون دائمی در خط لوله CI تبدیل شوند تا از بازگشت آسیبپذیریها جلوگیری شود.
کنترلهای پیادهسازی دقیق
برای عملیاتی کردن این اصول، معماری باید کنترلهای فنی خاصی را در سراسر پشته (Stack) پیاده کند:
اعتبارسنجی ورودی و رسانه
- تأیید امضای فایل: بکاند باید بایتهای واقعی یک فایل را بررسی کند، به جای اینکه به پسوند
.jpgیا.pdfاعتماد کند. - سهمیههای منابع: پیادهسازی حداکثر کارهای همزمان و حداکثر زمان پردازش برای جلوگیری از DoS از طریق فایلهای رسانهای پیچیده.
- حذف متادیتای حساس: یک خط لوله آگاه به حریم خصوصی باید مرحلهای برای بازرسی متاداتا و حذف دادههای مکان یا دستگاه پیش از اشتراکگذاری خروجی داشته باشد.
- اعتبارسنجی مستقل از رابط: خط لوله امنیتی یکسان باید اعمال شود، چه فایل از طریق انتخابگر فایل برسد، چه با کشیدن و رها کردن (drag-and-drop)، کلیپبورد یا اشتراکگذاری موبایل.
سختسازی مرورگر و API
- امنیت کلیپبورد: برنامههایی که دادههای کلیپبورد را میخوانند باید مجوزهای صریح درخواست کنند و از نگهداری غیرضروری محتوا اجتناب کنند.
- حداقلسازی مجوزها: مجوزهای دوربین و میکروفون باید فقط در لحظه استفاده درخواست شوند، نه در هنگام شروع برنامه.
- یکپارچگی زیرمنبع (SRI): استفاده از هشهای رمزنگاریشده برای اطمینان از اینکه اسکریپتهای شخص ثالث در حین انتقال دستکاری نشدهاند.
- URLهای امضا شده: استفاده از URLهای موقت و کوتاهمدت امضا شده برای ذخیرهسازی اشیاء خصوصی تا از افشای لینکهای عمومی دائمی جلوگیری شود.
مدیریت نشست و وضعیت
- ویژگیهای کوکی نشست: پیکربندی کوکیها با
HttpOnlyبرای مسدود کردن دسترسی جاوااسکریپت وSecureبرای تضمین انتقال فقط از طریق HTTPS. - دستهبندی وضعیت: جداسازی سختگیرانه وضعیت UI (مثلاً تب انتخابشده) از وضعیت حساس امنیتی (مثلاً بافت احراز هویت) برای جلوگیری از افشای تصادفی.
- طراحی صریح API: تعریف رابطهای سختگیرانه برای درخواستها (مثلاً
CreateGenerationRequest) و اعتبارسنجی هر فیلد در سرور، از جمله اندازه پرامپت و محدودیتهای رزولوشن.
ماتریس مرز امنیتی
یک معماری قدرتمند، کنترلها را در سه لایه توزیع میکند:
- فرانتاند: اعتبارسنجی UI، پیشبررسی حجم فایل و رندرینگ امن.
- بکاند: احراز هویت، مجوزها، محدودیت نرخ (Rate Limiting)، مدیریت اسرار و مدیریت اعتبارنامههای ارائهدهنده هوش مصنوعی.
- زیرساخت: WAF/API Gateway، اسکن بدافزار، سهمیههای منابع و سیستمهای پشتیبان.
این رویکرد لایهای تشخیص میدهد که کلاینت میتواند توسط کاربر تغییر کند یا جایگزین شود. با اعتبارسنجی زودهنگام در فرانتاند و اجرای سختگیرانه در بکاند، توسعهدهندگان میتوانند رابطهای هوش مصنوعی بسازند که هم قدرتمند و هم تابآور باشند.
گام بعدی شما
- تمام توابع رندرینگ محتوای AI را بررسی کنید و هر جا از
dangerouslySetInnerHTMLیا مشابه آن استفاده شده، آن را با یک کتابخانه پاکسازی (Sanitization) جایگزین کنید. - کوکیهای نشست خود را به
HttpOnlyوSecureتغییر دهید تا از سرقت توکنها توسط اسکریپتهای مخرب جلوگیری شود. - یک سیاست CSP سختگیرانه تعریف کنید که فقط به دامنههای تأییدشده اجازه اتصال (connect-src) میدهد.
اما امنیت در لایه زیرساخت و مدیریت GPUها چالشهای پیچیدهتری دارد — به تحلیل ما دربارهی بهینهسازی هزینههای استنتاج مراجعه کنید.
گفتگو