امنیت نرم‌افزارهای تحت وب (Web Application Security) معمولاً با تصویر دیوار آتش، سرور محافظت‌شده و چند قاعده شبکه گره می‌خورد؛ در حالی که در عمل، بیشتر رخدادهای واقعی از همان مسیری وارد می‌شوند که کاربران و سرویس‌ها هر روز از آن استفاده می‌کنند: خودِ برنامه. همین جابه‌جایی نقطه توجه — از مرز شبکه به مرز اعتماد (Trust Boundary) درون برنامه — تعیین می‌کند کدام فناوری‌های امنیتی امروز ارزش سرمایه‌گذاری دارند و کدام‌ها فقط آرامش خیال می‌آورند.
چرا مرز شبکه دیگر کافی نیست
برنامه وب امروزی فقط یک صفحه HTML نیست. مجموعه‌ای از رابط‌های برنامه‌نویسی (Application Programming Interface – API)، کلاینت موبایل، اسکریپت‌های شخص ثالث، صف پیام و سرویس‌های ابری همگی به یک هسته داده وصل‌اند. هر یک از این اجزا یک «فرد مورد اعتماد» تازه است و هر فرد مورد اعتماد، یک نقطه شکست تازه.
نکته مهم این است که درخواست مهاجم از دید شبکه، دقیقاً همان درخواست سالم است؛ فقط شناسه‌ای در آن عوض شده. اگر خودِ برنامه تصمیم نگیرد چه کسی به کدام داده دسترسی دارد، هیچ لایه شبکه‌ای این خلأ را پر نمی‌کند. رویکرد درست، دفاع لایه‌ای (Defense in Depth) است: شبکه، سرور، برنامه و داده هر کدام سهم خود را می‌گیرند، اما لایه تعیین‌کننده همان لایه‌ای است که داده را تفسیر و تحویل می‌دهد.
استاندارد به‌جای چک‌لیست: ساختن زبان مشترک
رایج‌ترین اشتباه این است که امنیت را فهرستی ببینیم که یک بار پر می‌شود و بایگانی می‌گردد. فهرست‌های پرخطر پروژه امنیت برنامه‌های وب OWASP دقیقاً برای همین ساخته شده‌اند: نه به‌عنوان فرم بازرسی، بلکه به‌عنوان واژگان مشترک میان تیم محصول، تیم توسعه و تیم امنیت.
وقتی همه از «خرابی کنترل دسترسی» یا «پیکربندی نادرست امنیتی» حرف می‌زنند، بحث از «این کد ناامن است» به «این دسته ریسک در محصول ما کجاست و چه کسی مالک رفع آن است» تغییر می‌کند. خروجی این تغییر زبان، یک فهرست ریسک زنده است با مالک مشخص، معیار پذیرش روشن و بازه بازبینی — نه سندی که سالی یک بار از قفسه بیرون بیاید.
فناوری‌هایی که واقعاً ریسک را کم می‌کنند
احراز هویت و مدیریت نشست
رمز عبور تنها، دیگر یک عامل قابل اتکا نیست؛ نه به این دلیل که شکستن آن غیرممکن است، بلکه چون درز آن تقریباً همیشه از سمت کاربر و خارج از کنترل شما رخ می‌دهد. ورود چندعاملی (Multi-Factor Authentication – MFA) سطح حمله را به‌طور محسوس بالا می‌برد و کلید عبور (Passkey) بر پایه استاندارد WebAuthn گام بعدی است: رمز با یک کلید رمزنگاری‌شده در دستگاه کاربر جایگزین می‌شود و سرور هیچ رمزی برای دزدیدن نگه نمی‌دارد.
در سمت نشست، چند تنظیم ساده اثر بزرگی دارند: کوکی‌های HttpOnly و SameSite، عمر کوتاه توکن دسترسی، چرخش توکن تازه‌سازی (Refresh Token) و مهم‌تر از همه، امکان ابطال نشست در لحظه. اگر نتوانید نشست یک کاربر را فوراً باطل کنید، هر بازیابی رمز و هر خروج سراسری نیمه‌کاره می‌ماند.
کنترل دسترسی در سطح شیء
بسیاری از حفره‌های واقعی برنامه‌های وب از نبود بررسی مالکیت داده می‌آیند؛ الگویی که با نام دسترسی مستقیم و ناامن به شیء (Insecure Direct Object Reference – IDOR) شناخته می‌شود. نمونه عملی: در یک فروشگاه اینترنتی، کاربر برای دیدن سفارش خود مسیر /api/orders/۱۲۳ را باز می‌کند و سپس فقط عدد را در نوار نشانی به ۱۲۴ تغییر می‌دهد. اگر سرور تنها بررسی کرده باشد که «کاربر وارد شده است» و نه اینکه «این سفارش متعلق به همین کاربر است»، پاسخ کامل سفارش بعدی را تحویل می‌دهد.
راه‌حل فناورانه پیچیده نیست: هر پرس‌وجو باید از ابتدا با محدوده‌ای از داده که کاربر مجاز به دیدن آن است قید شود، نه اینکه پس از خواندن داده، نتیجه در حافظه فیلتر شود. این کار معمولاً با ترکیب سطح دسترسی (Role) و یک قاعده مالکیت (Ownership) در لایه دسترسی به داده انجام می‌شود.
امنیت زنجیره تأمین نرم‌افزار
بخش بزرگی از کد یک برنامه وب، کدی است که خودتان ننوشته‌اید: کتابخانه‌ها، بسته‌ها و ایمیج‌های پایه. امنیت زنجیره تأمین نرم‌افزار (Software Supply Chain Security) یعنی همین اجزا را جدی بگیریم. چند اقدام عملی: قفل‌کردن نسخه بسته‌ها، اجرای خودکار تحلیل ترکیب نرم‌افزار (Software Composition Analysis – SCA) در خط لوله ساخت، تولید فهرست اقلام نرم‌افزاری (Software Bill of Materials – SBOM) برای هر انتشار، مدیریت متمرکز کلیدها و رمزها به‌جای نگه‌داشتن آن‌ها در فایل پیکربندی، و دادن کمترین دسترسی لازم به توکن‌های یکپارچه‌سازی و انتشار پیوسته (CI/CD).
مقابله با سوءاستفاده خودکار
هر رابط ورود، ثبت‌نام یا ارسال فرم، مقصدی برای تلاش‌های خودکار است. ترتیب درست دفاع این است: محدودسازی نرخ درخواست، تشخیص الگوهای غیرعادی و تنها در آخرین لایه، آزمون تشخیص انسان. کپچا ابزار بدی نیست، اما اگر جای منطق امنیتی را بگیرد، هم تجربه کاربر را خراب می‌کند و هم به‌تنهایی مانع مهاجم مصمم نمی‌شود؛ چون مرز قانونی و فنی خودکارسازی حل کپچا روشن است. پیش از آن هم بهتر است بدانید کدام ربات مفید است و کدام مخرب، و برای هرکدام سیاست جدا تعریف کنید؛ تفکیک ربات‌ها و کراولرها و سیاست‌گذاری برای آن‌ها همین کار را ساده‌تر می‌کند.
راهنمای تصمیم‌گیری: از کجا شروع کنیم؟
اگر بودجه و زمان محدود است، این ترتیب معمولاً بیشترین بازده امنیتی را دارد:
- مالکیت و احراز هویت را ببندید: ورود چندعاملی برای حساب‌های مدیریتی، نشست کوتاه و قابل ابطال.
- کنترل دسترسی را در لایه داده پیاده کنید: هیچ پرس‌وجویی بدون قید مالکیت یا سطح دسترسی اجرا نشود.
- ورودی را در مرز سرور اعتبارسنجی کنید: اعتبارسنجی سمت کلاینت فقط برای تجربه کاربری است، نه برای امنیت.
- خط لوله ساخت را امن کنید: اسکن وابستگی‌ها، مدیریت رمزها و کمترین دسترسی برای توکن‌های انتشار.
- رخدادنگاری و پایش را جدی بگیرید: بدون گزارش قابل جست‌وجو، تشخیص نفوذ به حدس و گمان تبدیل می‌شود.
- آزمون را تکرارپذیر کنید: آزمون ایستای کد و آزمون پویا در هر انتشار، به‌جای یک بازبینی سالانه.
جمع‌بندی
امنیت نرم‌افزارهای تحت وب امروز کمتر در خرید تجهیزات خلاصه می‌شود و بیشتر در تصمیم‌های طراحی: چه کسی چه داده‌ای را می‌بیند، نشست‌ها چه‌قدر عمر می‌کنند و کدی که نمی‌نویسیم از کجا می‌آید. استانداردها و فناوری‌ها فقط زمانی اثر دارند که به فرایند روزمره تیم تبدیل شوند — در قالب بازبینی کد، خط لوله ساخت و معیار پذیرش انتشار. با همین نگاه می‌توانید سطح امنیت را نه یک‌بار، بلکه در هر انتشار کمی بالاتر ببرید.
