یک پنل ادمین با رابط کاربری خیرهکننده و کدهای تمیز React یا Vue نوشتهاید؛ اما آیا میدانید یک اسکریپت چندخطی در مرورگر میتواند توکنهای کاربران را سرقت کند؟ بسیاری از توسعهدهندگان تصور میکنند تامین امنیت صرفاً وظیفه تیم بکاند و تنظیمات فایروال است. همین خطای دیدگاه، کلاینت را به آسیبپذیرترین نقطه معماری نرمافزار تبدیل میکند. کدهای شما مستقیماً روی سیستم کاربر اجرا میشوند؛ محیطی که هیچ کنترلی روی آن ندارید و هکرها به تمام جزئیاتش دسترسی دارند.
در این مقاله از کندو، چکلیستی عملی برای پیادهسازی امنیت در فرانت اند را مرور میکنیم. از مهار حملات XSS و CSRF گرفته تا چالش همیشگی ذخیرهسازی توکنها در localStorage یا کوکیهای HttpOnly، کانفیگ دقیق هدرهای CSP و ایمنسازی پکیجهای npm را با مثالهای واقعی بررسی خواهیم کرد.
چرا امنیت در فرانت اند اهمیت دارد؟
با رواج اپلیکیشنهای تکصفحهای (SPA)، بخش بزرگی از منطق برنامه و مدیریت وضعیتها از سرور به مرورگر منتقل شده است. این جابهجایی، سطح حمله (Attack Surface) وسیعی ایجاد میکند.
در بسیاری از پروژههای واقعی میبینیم که توسعهدهندگان به دلیل فشار ددلاین، بررسی سطح دسترسی (Authorization) را به پنهان کردن چند دکمه در UI محدود میکنند. غافل از اینکه مهاجم به راحتی از طریق تب Network مرورگر، ساختار درخواستها را دیده و APIهای حساس درخواست ارسال میکند.
مرورگر؛ خط مقدم مواجهه با هکرها
کدهای جاوااسکریپت پس از دانلود روی سیستم کاربر، دیگر در محیط امن سرور نیستند؛ بلکه در زمین بازی هکرها اجرا میشوند. همان ابزار Chrome DevTools که روزانه برای دیباگ کدهای جاوا اسکریپت استفاده میکنید، سلاح اصلی مهاجمان برای مهندسی معکوس برنامه شماست.
یک نفوذگر در محیط مرورگر میتواند بدون هیچ مانعی اقدامات زیر را انجام دهد:
- دستکاری کدها در لحظه اجرا (Runtime): گذاشتن Breakpoint روی توابع حساس و تغییر مقادیر متغیرها.
- شنود ترافیک شبکه: بررسی دقیق Payloadها، هدرها و اندپوینتهای API.
- استخراج کلیدهای حساس: خواندن API Keyهایی که به اشتباه در فایلهای .env فرانتاند قرار گرفته و داخل باندل نهایی کامپایل شدهاند.
- دسترسی به حافظه مرورگر: سرقت اطلاعات ذخیرهشده در localStorage و sessionStorage از طریق کنسول یا تزریق اسکریپت.
رایجترین حملات امنیتی در فرانت اند و روشهای مقابله
شناخت مسیرهای نفوذ، اولین قدم برای ایمنسازی کدهای کلاینت است. هکرها به جای درگیر شدن با الگوریتمهای پیچیده سرور، از نقاط ضعف مرورگر و نحوه تعامل کاربر با رابط کاربری سوءاستفاده میکنند. در ادامه، سه تهدید اصلی سمت کلاینت و روش مهار آنها را بررسی میکنیم.

حملات XSS و روشهای جلوگیری
حمله Cross-Site Scripting زمانی رخ میدهد که مهاجم اسکریپت مخرب خود را به کدهای برنامه تزریق کند. با این کار، نفوذگر به کوکیهای غیرامن، localStorage و کل dom در جاوا اسکریپت دسترسی مییابد.
فریمورکهای مدرن مثل React و Vue به صورت پیشفرض مقادیر متغیرها را Escape میکنند؛ اما دو اشتباه رایج برنامهنویسان، این سپر دفاعی را از کار میاندازد:
- رندر مستقیم HTML خام: استفاده از dangerouslySetInnerHTML در ریاکت یا v-html در ویو (مثلاً برای نمایش کامنتها یا مقالات) بدون پاکسازی ورودی، دروازه ورود اسکریپتهای مخرب است.
- لینکهای پویای بررسینشده: قرار دادن ورودی مستقیم کاربر در تگ لینک (<a href={userUrl}>) به مهاجم اجازه میدهد تا با وارد کردن عبارتی مثل javascript:stealToken()، کد دلخواهش را با کلیک کاربر اجرا کند.
راهکار عملی: اگر مجبور به رندر کردن HTML خام هستید، حتماً قبل از نمایش، رشته مورد نظر را با کتابخانه استاندارد DOMPurify پاکسازی (Sanitize) کنید تا تگها و رویدادهای مخرب حذف شوند:
JavaScript
import DOMPurify from 'dompurify';
const cleanHTML = DOMPurify.sanitize(dirtyHTMLFromAPI);حملات CSRF و نقش Anti-CSRF Token
در حمله Cross-Site Request Forgery (جعل درخواست میانسایتی)، مهاجم مرورگرِ کاربری که قبلاً در سایت شما لاگین کرده را فریب میدهد تا بدون اطلاع او، یک درخواست ناخواسته (مثل انتقال وجه) به سرور ارسال کند. از آنجا که مرورگر به صورت خودکار کوکیهای احراز هویت را ضمیمه تمام درخواستها میکند، سرور متوجه جعلی بودن درخواست نمیشود.
برای مسدود کردن این حفره امنیتی طبق استانداردهای OWASP، ترکیب دو تکنیک زیر ضروری است:
- استفاده از Anti-CSRF Token: سرور یک توکن یکتا تولید میکند و کدهای فرانتاند باید آن را در هدر سفارشی (مثل X-CSRF-Token) قرار دهند. سایتهای مهاجم به دلیل محدودیتهای مرورگر نمیتوانند هدر سفارشی به درخواستهای Cross-Origin اضافه کنند و حمله خنثی میشود.
- تنظیم ویژگی SameSite برای کوکیها: اضافه کردن صفت SameSite=Strict یا Lax به کوکیها، مرورگر را از ارسال خودکار کوکی در درخواستهای مشکوکِ خارج از دامنه باز میدارد.
مقابله با Clickjacking
در حمله Clickjacking، مهاجم صفحه سایت شما را داخل یک تگ <iframe> کاملاً شفاف روی سایت فریبنده خود قرار میدهد. کاربر تصور میکند روی دکمه «دریافت جایزه» کلیک میکند، اما در واقع روی دکمه «حذف حساب» یا «تایید تراکنش» در سایت نامرئی شما کلیک کرده است.
برای جلوگیری از بارگذاری صفحاتتان داخل iframe سایتهای دیگر، باید یکی از این دو هدر امنیتی را در پاسخهای وبسرور (مثل Nginx) تنظیم کنید:
- هدر Content-Security-Policy: تنظیم دایرکتیو frame-ancestors ‘none’ (یا ‘self’ برای محدود کردن به دامنه خودتان) که استاندارد مدرن مرورگرهاست.
- هدر X-Frame-Options: قرار دادن مقدار DENY یا SAMEORIGIN برای پشتیبانی از مرورگرهای قدیمی.
تسلط بر این تکنیکهای دفاعی، مرز بین یک کدنویس معمولی و یک متخصص ارشد را مشخص میکند؛ مهارتی که در دوره فرانت اند کندو به صورت کاملاً پروژهمحور روی آن تمرکز میکنیم تا کدهایی ایمن و استاندارد بنویسید.
مدیریت امن احراز هویت و توکنها
مدیریت نشستهای کاربری و نگهداری توکنهای JWT، یکی از حساسترین بخشها در معماری کلاینت است. اگر مهاجم به این توکنها دست یابد، بدون نیاز به رمز عبور میتواند هویت کاربر را جعل کند.
localStorage یا HttpOnly Cookie
بسیاری از توسعهدهندگان برای راحتی کار، توکن را بلافاصله پس از لاگین در localStorage ذخیره میکنند. این کار یک ریسک امنیتی بزرگ است؛ زیرا localStorage از طریق جاوااسکریپت کاملاً قابل دسترس است و با کوچکترین رخنه XSS، تمام توکنها سرقت میشوند.
مقایسه فنی دو روش اصلی نگهداری توکن:
| ویژگی | حافظه localStorage | کوکی HttpOnly |
| دسترسی با جاوااسکریپت | دارد (localStorage.getItem) | ندارد (مسدود شده توسط مرورگر) |
| مقاومت در برابر XSS | به شدت آسیبپذیر | ایمن در برابر سرقت مستقیم توکن |
| مقاومت در برابر CSRF | ایمن | نیازمند تنظیم SameSite و توکن ضد CSRF |
استفاده از کوکیهای HttpOnly همراه با فلگهای Secure (فقط HTTPS) و SameSite=Strict بسیار امنتر است؛ چرا که هیچ اسکریپتی اجازه خواندن محتوای این کوکیها را ندارد.
ذخیرهسازی امن Access Token و Refresh Token
بر اساس استانداردهای OAuth 2.0، بهترین الگو (Best Practice) تفکیک توکنها به دو بخش است:
- توکن دسترسی (Access Token): عمر کوتاهی دارد (۵ تا ۱۵ دقیقه) و برای درخواستهای API استفاده میشود. امنترین جا برای نگهداری آن، حافظه موقت برنامه (In-Memory) یعنی داخل متغیرهای جاوااسکریپت یا State فریمورک (مثل Redux یا Zustand) است تا هیچ دادهای روی مرورگر ذخیره نشود.
- توکن بازیابی (Refresh Token): عمر طولانیتری دارد و برای دریافت Access Token جدید به کار میرود. سرور باید این توکن را مستقیماً در یک کوکی HttpOnly ذخیره کند.
با این معماری، حتی با رفرش شدن صفحه و پاک شدن State، فرانتاند در پسزمینه یک درخواست به اندپوینت /refresh میفرستد. مرورگر به صورت خودکار کوکی HttpOnly را ضمیمه کرده و یک Access Token جدید میگیرد؛ بدون اینکه دست اسکریپتهای مخرب به توکن اصلی برسد.
تنظیمات امنیتی ضروری در فرانت اند
نوشتن کدهای تمیز در React یا Vue به تنهایی کافی نیست. با تنظیم درست هدرهای امنیتی و قوانین مرورگر، میتوانید یک سپر دفاعی بسازید تا حتی در صورت وجود باگ در کدها، خودِ مرورگر جلوی اجرای دستورات مخرب را بگیرد.
CSP و جلوگیری از اجرای کدهای مخرب
سیاست امنیت محتوا یا CSP (Content Security Policy) به مرورگر اعلام میکند که فقط مجاز به بارگذاری و اجرای منابع (اسکریپتها، فونتها و تصاویر) از چه دامنههای مشخصی است.
حتی اگر مهاجمی از طریق باگ XSS یک اسکریپت مخرب را وارد صفحه کند، تنظیم یک CSP سختگیرانه مانع از اجرای آن میشود. این قانون را میتوانید در هدرهای وبسرور (مثل Nginx) یا تگ <meta> قرار دهید:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trustedscripts.com;">این کد به مرورگر دستور میدهد فقط فایلهای دامنه خودتان (‘self’) و اسکریپتهای دامنه مورد تاییدتان را اجرا کرده و سایر کدها را مسدود کند.
SOP و تنظیم صحیح CORS
قانون SOP (Same-Origin Policy) در مرورگرها اجازه نمیدهد اسکریپتهای یک سایت به دادههای سایت دیگر دسترسی پیدا کنند. برای ارتباط امن فرانتاند و APIهایی که روی دامنههای مجزا هستند، از CORS بهره میبریم.
یک اشتباه رایج در پروژهها این است که برای رفع سریع خطای CORS، هدر Access-Control-Allow-Origin در سرور روی مقدار * (Wildcard) تنظیم میشود. این کار یعنی هر سایتی میتواند به API شما درخواست بفرستد و پاسخ را بخواند.
روش اصولی: همیشه دامنههای مجاز را به صورت دقیق در تنظیمات CORS سرور مشخص کنید و در صورت ارسال کوکیهای احراز هویت، هدر Access-Control-Allow-Credentials: true را صرفاً برای همان دامنه خاص فعال نمایید.

امنیت ارتباطات و استفاده از HTTPS
انتقال داده روی پروتکل HTTP، ترافیک کاربر را در معرض شنود و حملات مرد میانی (MITM) در شبکههای عمومی قرار میدهد. علاوه بر اینکه در سمت سرور باید بدانیم چگونه https را فعال کنیم، توسعهدهندگان فرانتاند نیز باید دو مورد زیر را در کدهای خود کنترل کنند
- حذف Mixed Content: اگر سایت روی HTTPS است، هیچ فایل، تصویر یا API را با آدرس http:// فراخوانی نکنید؛ زیرا مرورگر آنها را مسدود میکند.
- فعالسازی هدر HSTS: تنظیم هدر Strict-Transport-Security در وبسرور، مرورگر را مجبور میکند که تمام درخواستها را به صورت خودکار و پیش از ارسال روی شبکه، به HTTPS تغییر دهد.
امنیت کتابخانهها و وابستگیها
بخش بزرگی از کدهای یک پروژه فرانتاند در پوشه node_modules قرار دارد. در سال ۲۰۲۶، حملات زنجیره تامین (Supply Chain Attacks) یکی از اصلیترین روشهای نفوذ به شمار میروند؛ جایی که هکر به جای حمله مستقیم به سایت شما، یکی از کتابخانههای مصرفیتان را آلوده میکند.
خطرات پکیجهای npm
اجرای npm install یعنی دعوت از کدهای صدها توسعهدهنده ناشناس به داخل پروژه. دو خطر اصلی در این بخش کمین کردهاند:
- حملات Typosquatting: انتشار پکیجهای مخرب با نامهای بسیار مشابه به کتابخانههای محبوب (مثلاً react-routr به جای react-router) برای به دام انداختن برنامهنویسانی که هنگام تایپ اشتباه میکنند.
- نفوذ به اکانت توسعهدهندگان: هکرها با سرقت حساب سازندگان پکیجهای معروف، آپدیتی حاوی کدهای جاسوسی منتشر میکنند که با یک بروزرسانی ساده وارد باندل نهایی شما میشود.
همیشه پیش از نصب پکیج، تعداد دانلودهای هفتگی و وضعیت گیتهاب آن را بررسی کنید و فایل package-lock.json را برای قفل کردن نسخههای دقیق، حتماً در گیت نگهدارید.
Subresource Integrity (SRI)
اگر اسکریپتی را از CDNهای عمومی بارگذاری میکنید، خطر دستکاری فایل در صورت هک شدن سرور CDN وجود دارد. قابلیت SRI به شما اجازه میدهد هش رمزنگاریشده فایل اصلی را در صفت integrity تگ اسکریپت قرار دهید:
<script src="https://cdn.example.com/library.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>مرورگر پس از دانلود فایل از CDN، هش آن را با مقدار integrity مقایسه میکند و اگر حتی یک کاراکتر از فایل تغییر کرده باشد، مانع از اجرای آن میشود.
ابزارهای بررسی آسیبپذیری مانند npm audit و Snyk
برای پایش خودکار امنیت صدها پکیج پروژه، از این دو ابزار استفاده کنید:
- دستور npm audit: درخت وابستگیهای پروژه را اسکن کرده و آسیبپذیریها را گزارش میدهد. با اجرای npm audit fix میتوانید بسیاری از این حفرهها را به صورت خودکار به نسخههای امن ارتقا دهید.
- ابزار Snyk و Dependabot: اتصال گیت به ابزارهایی مثل Snyk در پایپلاینهای CI/CD، هر کد جدید را اسکن میکند و در صورت کشف آسیبپذیری در پکیجها، به سرعت هشدار داده یا به صورت خودکار Pull Request اصلاحی میزند.
چکلیست امنیت در فرانت اند
برای اینکه هنگام تحویل پروژه یا بررسی کدها (Code Review) هیچ نکته امنیتی از قلم نیفتد، موارد زیر را به عنوان چکلیست نهایی پیش از انتشار بررسی کنید:
- پاکسازی ورودیها: استفاده از کتابخانه DOMPurify پیش از رندر کردن هرگونه کد HTML خام در dangerouslySetInnerHTML یا v-html.
- مدیریت امن توکنها: حذف توکنهای حساس از localStorage و نگهداری آنها در حافظه موقت برنامه (In-Memory) و کوکیهای HttpOnly.
- تنظیمات کوکی: فعالسازی فلگهای HttpOnly، Secure و SameSite برای تمام کوکیهای احراز هویت.
- هدرهای امنیتی: کانفیگ دقیق هدرهای Content-Security-Policy (مهار XSS) و X-Frame-Options (مقابله با Clickjacking) روی وبسرور.
- حذف کلیدهای محرمانه: اطمینان از نبودن Secret Keyها و توکنهای خصوصی داخل فایل .env فرانتاند و باندل نهایی.
- محدودسازی CORS: تنظیم هدر Access-Control-Allow-Origin فقط برای دامنههای مجاز و پرهیز از مقدار *.
- امنیت پکیجها: رفع آسیبپذیریهای بحرانی با اجرای npm audit و افزودن صفت integrity (قابلیت SRI) به اسکریپتهای CDN.
- کنترل دسترسی در سرور: بررسی سطح دسترسی کاربر (Authorization) در سمت API و اکتفا نکردن به مخفیسازی دکمهها در رابط کاربری.
جمع بندی
تامین امنیت در فرانت اند یک اقدام مقطعی در انتهای پروژه نیست، بلکه طرز فکری است که باید از اولین خط کدنویسی با شما همراه باشد. در بازار کار امروز، شرکتهای معتبر به دنبال توسعهدهندگانی هستند که فراتر از ظاهر زیبای رابط کاربری، مسئولیت حفاظت از دادههای کاربران و اعتبار سامانه را بر عهده بگیرند. تسلط بر این استانداردهای امنیتی، جایگاه شغلی شما را از یک کدنویس ساده به یک مهندس نرمافزار ارشد و قابل اعتماد ارتقا میدهد. اگر آمادهاید مهارتهای برنامهنویسی خود را با چالشهای واقعی صنعت هماهنگ کنید، متخصصان ما در آکادمی کندو مسیر ورود حرفهای شما به بازار کار را هموار میکنند.
سوالات متداول
۱. آیا مبهمسازی کدهای جاوااسکریپت (Code Obfuscation) امنیت را تضمین میکند؟
خیر؛ مبهمسازی فقط خواندن کدها را زمانبر میکند، اما جلوی سرقت توکنها و آسیبپذیریهای منطقی را نمیگیرد.
۲. چرا باید فایلهای Source Map را در نسخه نهایی غیرفعال کنیم؟
چون کدهای فشردهشده را به کدهای اصلی و قابل خواندن تبدیل میکنند و فعال بودنشان یعنی تقدیم کردن سورسکد خام به هکرها.
۳. آیا فریمورکهای SSR مثل Next.js امنیت پروژه را خودکار بالا میبرند؟
آنها با اجرای کدها در سمت سرور مانع لو رفتن کلیدهای خصوصی میشوند، اما همچنان در بخش مرورگر نیازمند رعایت اصول مقابله با XSS و CSRF هستید.
