بیشتر راهنماهای «افزایش امنیت سایت» فهرستی از ۳۰ توصیه‌ی درست اما بی‌ترتیب می‌دهند و خواننده را در همان نقطه‌ای رها می‌کنند که بود: نمی‌داند از کجا شروع کند. این مقاله ترتیب دارد. هر اقدام با میزان تلاش و میزان تأثیر مشخص شده و به‌صورت دستوری نوشته شده — یعنی می‌توانید همین امشب از بند یک شروع کنید. اگر به‌دنبال فهم مفهومی لایههای امنیت هستید، راهنمای امنیت سایت آن نقش را دارد؛ این مقاله برنامهی اجرایی است.
در یک نگاه
- پنج اقدام اول این فهرست، مجموعاً کمتر از یک روز کار میبرد و پرتکرارترین مسیرهای نفوذ را می‌بندد.
- MFA روی حسابهای مدیریتی، حذف اجزای بیاستفاده و بستن فایلهای افشاشده — بالاترین نسبت تأثیر به تلاش را دارند.
- اقدامات سطح کد (کوئری پارامتری، فهرست سفید شناسهها، بازنویسی کنترل دسترسی) تلاش بیشتری می‌برند اما جای دیگری برای رفعشان نیست.
- WAF راهکار رفع آسیب‌پذیری کد نیست؛ کنترل جبرانی و خریدار زمان است.
- امنیت از راه پنهان‌کاری — تغییر مسیر پنل، مخفی کردن نسخه — تأثیر واقعی ناچیزی دارد و جایگزین کنترل نیست.
معیار اولویت‌بندی: تلاش در برابر تأثیر
هر اقدام امنیتی دو عدد دارد: چقدر کار میبرد، و چقدر ریسک واقعی را کم میکند. اشتباه رایج، شروع از کارهای پرزحمت و کم‌تأثیر است — مثل بازنویسی کل معماری احراز هویت، در حالی که همان سامانه پنل مدیریت بدون MFA دارد.
جدول زیر بیست اقدام را با هر دو معیار می‌چیند. «تأثیر» به‌معنای کاهش احتمال یا اثر یک رخنه‌ی واقعی است، نه بهبود نمره‌ی یک ابزار.
| # | اقدام | تلاش | تأثیر | مسئول |
|---|---|---|---|---|
| ۱ | MFA روی همهی حسابهای مدیریتی، هاست، دامنه و ایمیل | کم | بسیار بالا | مدیر سایت |
| ۲ | حذف حسابهای بیاستفاده و پیمانکاران قبلی | کم | بالا | مدیر سایت |
| ۳ | حذف فایل پشتیبان، .env و .git از ریشه‌ی وب | کم | بسیار بالا | DevOps |
| ۴ | بهروزرسانی CMS، افزونه‌ها، قالب و کتابخانه‌ها | متوسط | بسیار بالا | توسعه |
| ۵ | حذف (نه غیرفعال‌سازی) افزونه‌ها و اجزای بیاستفاده | کم | بالا | توسعه |
| ۶ | خاموش کردن پیام خطای پرجزئیات در محیط عملیاتی | کم | متوسط | توسعه |
| ۷ | غیرفعال‌سازی فهرست‌شدن دایرکتوری | کم | متوسط | DevOps |
| ۸ | محدودسازی نرخ ورود و تأخیر تصاعدی | کم | بالا | توسعه |
| ۹ | پشتیبان خارج از سرور با آزمون بازیابی دوره‌ای | متوسط | بسیار بالا | DevOps |
| ۱۰ | TLS 1.3، خاموشی TLS 1.0/1.1، فعال‌سازی HSTS | کم | متوسط | DevOps |
| ۱۱ | صفتهای Secure، HttpOnly و SameSite روی کوکی نشست | کم | بالا | توسعه |
| ۱۲ | ابطال نشست در سمت سرور پس از خروج و تغییر رمز | کم | بالا | توسعه |
| ۱۳ | هدرهای امنیتی پایه (nosniff، Referrer-Policy، frame-ancestors) | کم | متوسط | DevOps |
| ۱۴ | حساب پایگاه‌داده با کمترین سطح دسترسی لازم | متوسط | بالا | DevOps |
| ۱۵ | کوئری پارامتری در همهی مسیرها + فهرست سفید برای شناسهها | بالا | بسیار بالا | توسعه |
| ۱۶ | بازبینی کنترل دسترسی: بررسی مالکیت در لایه‌ی داده | بالا | بسیار بالا | توسعه |
| ۱۷ | امنسازی آپلود فایل: نوع، مسیر، نام و منع اجرا | متوسط | بالا | توسعه |
| ۱۸ | ثبت رخدادهای امنیتی + هشدار برای چند رخداد کلیدی | متوسط | بالا | DevOps |
| ۱۹ | CSP بر پایه‌ی nonce با strict-dynamic | بالا | متوسط | توسعه |
| ۲۰ | SBOM و اسکن وابستگی در خط لوله‌ی بیلد | متوسط | بالا | DevOps |
ترتیب پیشنهادی اجرا: بندهای ۱ تا ۱۳ را در دو هفته ببندید (اینها عمدتاً پیکربندی‌اند)، سپس بندهای ۱۴ تا ۲۰ را در چرخه‌های توسعه‌ی بعدی برنامه‌ریزی کنید.
هفته‌ی اول: پنج کاری که امروز انجام می‌دهید
این پنج بند بدون نیاز به چرخهی توسعه و بدون تغییر کد قابل انجاماند.
۱. MFA روی هر حساب مدیریتی
فهرست کنید: پنل مدیریت سایت، کنترل‌پنل هاست، پنل ثبت‌کننده‌ی دامنه، حساب ایمیل مرتبط، حساب مخزن کد، و حساب سرویس ابری. نکته‌ای که مدام از قلم می‌افتد: حساب ایمیل مدیر عملاً کلید بازیابی همهی حسابهای دیگر است؛ اگر آن یکی MFA ندارد، بقیه هم عملاً ندارند.
۲. بازبینی فهرست کاربران
هر حسابی که در سه ماه گذشته استفاده نشده و نمی‌دانید مال کیست را غیرفعال کنید. هر حساب با نقش مدیر که واقعاً به آن نقش نیاز ندارد را تنزل دهید. حساب مشترکی که چند نفر رمزش را می‌دانند را با حسابهای شخصی جایگزین کنید. حساب پیمانکار پروژه‌ی قبلی را حذف کنید.
۳. بستن فایلهای افشاشده
این مسیرها را روی دامنه‌ی خودتان امتحان کنید. هر پاسخ ۲۰۰ باید همین امروز بسته شود:
/.git/config
/.env
/backup.zip /db.sql /site.tar.gz
/wp-config.php.bak
/phpmyadmin/ /adminer.phpراه‌حل درست، انتقال این فایل‌ها به بیرون ریشه‌ی وب است، نه فقط مسدود کردنشان با یک قاعده‌ی وب‌سرور. اگر پوشه‌ی .git در ریشه‌ی وب دارید، فرایند استقرار خود را عوض کنید.
۴. بهروزرسانی همهی اجزا
ابتدا روی محیط آزمون، سپس عملیاتی. با اجزای رهاشده جدی برخورد کنید: کتابخانه یا افزونه‌ای که دو سال بهروزرسانی نشده، آسیب‌پذیری‌اش هم هرگز رفع نمی‌شود — CWE-1104 دقیقاً برای همین وجود دارد. اگر روی وردپرس هستید، امنیت وردپرس جزئیات این بند را میدهد.
۵. محدودسازی نرخ ورود
تأخیر تصاعدی روی تلاش‌های ناموفق، و مسدودسازی موقت بر پایه‌ی ترکیب IP و نام کاربری. بدون این، هیچ سیاست رمزی معنا ندارد. یکی از سناریوهای رسمی OWASP در دسته‌ی خطاهای احراز هویت، Credential Stuffing با جهش الگو است — مهاجم فهرست‌های فاش‌شده را با تغییرات کوچک امتحان میکند، مثلاً Winter2025 به Winter2026.
مقاوم‌سازی سرور و پیکربندی
پیکربندی نادرست در OWASP Top 10:2025 رتبه‌ی دوم را دارد و در ۱۰۰٪ برنامه‌های آزموده‌شده دیده شده است. مزیتش این است که رفعش تغییر کد لازم ندارد.
- پیام خطا: در محیط عملیاتی، حالت اشکال‌زدایی خاموش، Stack Trace خاموش، پیام عمومی به کاربر و جزئیات کامل فقط در لاگ سمت سرور.
- فهرست‌شدن دایرکتوری: در سطح وب‌سرور خاموش کنید، نه با گذاشتن فایل
index.htmlخالی در هر پوشه. - پوشه‌ی آپلود: اجرای کد را در آن مسیر کاملاً منع کنید. برای پیکربندی‌های PHP این یعنی غیرفعال کردن اجرای
.phpدر آن مسیر؛ ایمن‌ترین حالت، ذخیره‌ی فایل‌ها بیرون ریشه‌ی وب و سرو کردنشان از طریق یک کنترلر است. - مجوز فایل‌ها: مجوز نوشتن فقط روی مسیرهایی که واقعاً لازم است. فایلهای پیکربندی نباید توسط کاربر وب‌سرور قابل نوشتن باشند.
- حذف نمونه‌ها و دموها: برنامهی نمونه، محیط دمو و فایل نصب پس از راه‌اندازی باید حذف شوند. سناریوی شماره‌ی یک OWASP در دسته‌ی پیکربندی نادرست دقیقاً همین است.
- پنل‌های مدیریتی زیرساخت: phpMyAdmin و ابزارهای مشابه را از دسترس عمومی خارج کنید — محدودسازی IP، یا دسترسی فقط از طریق تونل.
- پلتفرم حداقلی: ماژول‌ها، سرویس‌ها و پورت‌هایی که استفاده نمی‌شوند را خاموش کنید.
- یکسان‌سازی محیط‌ها: فرایند مقاوم‌سازی را مکتوب و تکرارپذیر کنید تا توسعه، آزمون و عملیات یکسان پیکربندی شوند. این توصیه‌ی مستقیم OWASP در همین دسته است.
و محیط Staging را فراموش نکنید: یک نمونه‌ی آزمایشی قابل دسترسی از اینترنت با داده‌ی واقعی و بدون احراز هویت، یکی از جدی‌ترین یافته‌های تکرارشونده در تست نفوذ است. آن را با احراز هویت سطح وب‌سرور ببندید و داده را ناشناس‌سازی کنید.
لایه‌ی نشست و احراز هویت
اقدامات این بخش کوچک اما پرتأثیرند، چون کوکی نشست عملاً کلید حساب کاربر است.
- صفتهای کوکی:
Secure،HttpOnly، وSameSiteصریح. به پیشفرض مرورگر تکیه نکنید — کرومLaxرا پیشفرض اعمال میکند اما فایرفاکس این کار را نمی‌کند و موزیلا این تغییر را پس از مشاهده‌ی خرابی گسترده‌ی وب کنار گذاشت. پیشوند__Host-هم جلوی تزریق کوکی از زیردامنه را میگیرد. - توکن CSRF سمت سرور: الگوی توکن هم‌زمان‌ساز (Synchronizer Token) همچنان استاندارد طلایی است و صفت
SameSiteجانشین آن نیست. جزئیات در CSRF. - هیچ عملیات تغییردهنده‌ی وضعیت روی متد GET نباشد. این تک‌قاعده بخش بزرگی از سطح حمله‌ی CSRF را حذف میکند.
- تولید شناسه‌ی نشست جدید پس از ورود برای جلوگیری از تثبیت نشست، و ابطال کامل سمت سرور پس از خروج و پس از تغییر رمز.
- توکن احراز هویت را در
localStorageنگذارید. هر XSS آن را می‌خواند. کوکی باHttpOnlyگزینه‌ی بهتری است. اگر از JWT استفاده می‌کنید، عمر کوتاه بگذارید و ادعاهایaudوissرا اعتبارسنجی کنید. - سیاست رمز: طول را به‌جای پیچیدگی جدی بگیرید، رمزهای جدید را در برابر فهرست‌های فاش‌شده بررسی کنید، از مدیر رمز پشتیبانی کنید و اجبار به تعویض دوره‌ای را حذف کنید — هم‌راستا با NIST SP 800-63B.
اقدامات سطح کد: جایی که تلاش بیشتر میشود
این بخش به چرخهی توسعه نیاز دارد، اما هیچ کنترل محیطی جانشین آن نیست.
لایه‌ی داده
- کوئری پارامتری در همهی مسیرها. ساختار کوئری جدا از داده به پایگاه‌داده می‌رود، پس هیچ محتوایی در مقدار پارامتر نمی‌تواند معنای کوئری را تغییر دهد. این یک اصلاح ساختاری است، نه فیلترینگ — و به همین دلیل از فرار دادن کاراکترها بهتر است. جزئیات در تزریق SQL.
- فهرست سفید برای شناسهها. نام جدول، نام ستون و عبارت
ORDER BYدر SQL استاندارد قابل bind نیستند. اگر ستون مرتب‌سازی از ورودی کاربر می‌آید، آن را از یک نگاشت سفید سمت سرور بگیرید — هرگز الحاق رشته. - راههای فرار ORM را ممیزی کنید. فراخوانی‌های
raw()، الحاق رشته در HQL و متدهای خام مشابه، همان ریسک را برمیگردانند. - حساب پایگاه‌داده با کمترین دسترسی: حساب برنامه نباید مالک اسکیما باشد، نباید دسترسی نوشتن فایل داشته باشد و نباید بتواند دستور سیستم‌عامل اجرا کند. این یکی از ارزان‌ترین کنترل‌های عمق‌بخش است.
ورودی و خروجی
- اعتبارسنجی مثبت (فهرست سفید) در سمت سرور برای نوع، طول و قالب. اعتبارسنجی سمت کلاینت فقط برای تجربه‌ی کاربری است.
- کدگذاری خروجی متناسب با زمینه. فریم‌ورک‌های مدرن مثل React و Vue و Angular متن درونیابیشده را به‌صورت پیشفرض فرار می‌دهند و همین بخش عمدهی XSS ساده را حذف میکند — اما راههای فرار عمدی (
dangerouslySetInnerHTML،v-htmlو معادل‌ها) و صفتهای حاوی آدرس مثلhrefهمچنان آسیب‌پذیرند. مستندات خود React درباره‌یdangerouslySetInnerHTMLمی‌گوید با آن «به‌سادگی می‌توان یک آسیب‌پذیری XSS ایجاد کرد». - آپلود فایل: نوع را بر پایه‌ی محتوا و نه پسوند بررسی کنید، نام فایل را خودتان بسازید، فایل را بیرون ریشه‌ی وب ذخیره کنید و اجرای کد در مسیر ذخیره را منع کنید. CWE-434 (آپلود بدون محدودیت فایل با نوع خطرناک) رتبه‌ی ۱۲ فهرست CWE Top 25 سال ۲۰۲۵ را دارد.
- مدیریت شرایط استثنایی: اصل fail closed — اگر بررسی مجوز به هر دلیلی خطا داد، پاسخ باید «ممنوع» باشد نه «مجاز». دسته‌ی جدید A10:2025 دقیقاً به همین خانواده اختصاص دارد.
کنترل دسترسی
پرتأثیرترین و پرزحمت‌ترین بند فهرست. الگوی درست این است که بررسی مالکیت در لایه‌ی دسترسی به داده اعمال شود، نه به‌صورت بررسی پس از واکشی. یعنی کوئری شما ذاتاً محدود باشد:
SELECT * FROM invoices
WHERE id = ? AND owner_id = ?به‌جای اینکه رکورد خوانده شود و بعد نقش کاربر چک شود. به‌علاوه: رد پیشفرض برای هر منبع غیرعمومی، یک سازوکار مرکزی و قابل استفاده‌ی مجدد به‌جای بررسی پراکنده در هر کنترلر، و بررسی یکسان روی همهی متدها. الگوی خرابی رایج این است که بررسی روی GET هست اما روی PUT و DELETE نیست، یا روی صفحه‌ی HTML هست اما روی نسخه‌ی JSON همان اندپوینت نیست. توضیح کامل در کنترل دسترسی شکسته و IDOR.
لایه‌ی پایش، پشتیبان و آمادگی
این لایه از حمله جلوگیری نمی‌کند؛ زمان کشف و زمان بازیابی را کوتاه میکند — و در عمل همین دو عدد تفاوت «یک روز اختلال» و «یک فاجعه» را می‌سازد.
- ثبت رخدادهای امنیتی: ورود موفق و ناموفق، تغییر رمز و نقش، عملیات حساس، و شکست‌های کنترل دسترسی؛ موج ناگهانی پاسخ‌های ۴۰۳ یکی از قوی‌ترین نشانه‌های شمارش خودکار است.
- لاگ خارج از سرور برنامه و مسیر ممیزی فقط-افزودنی — اولین کار مهاجم پس از دسترسی، پاک کردن رد پاست. داده‌ی حساس را در لاگ ننویسید (CWE-532) و خروجی لاگ را کدگذاری کنید (CWE-117).
- هشدار برای چند رخداد کلیدی، نه برای همه‌چیز. تغییر نام دسته‌ی A09 از «پایش» به «هشداردهی» در نسخه‌ی ۲۰۲۵ دقیقاً همین را می‌گوید.
- پشتیبان: خارج از سرور، حداقل یک نسخه‌ی غیرقابل بازنویسی، فایل و پایگاه‌داده هم‌زمان، و آزمون بازیابی دو بار در سال. جزئیات این لایه در راهنمای امنیت سایت و آمادگی پس از رخداد در جلوگیری از هک سایت آمده است.
چهار اشتباه رایج در «افزایش امنیت»
«WAF می‌گذاریم تا آسیب‌پذیری برنامه پوشش داده شود.» WAF یک کنترل جبرانی و خریدار زمان است — مثلاً وصلهی مجازی تا زمان انتشار اصلاح واقعی، یا مسدودسازی اسکن انبوه. اما نسبت به چند دسته ساختاراً نابیناست: کنترل دسترسی شکسته و IDOR (رتبه‌ی یک فهرست OWASP؛ فایروال نمی‌داند کاربر شماره‌ی ۵ مجاز است رکورد ۷ را ببیند یا نه)، منطق کسبوکار، شرایط مسابقه، بخش عمدهی DOM XSS (بار حمله اغلب در بخش fragment آدرس است که هیچ‌وقت به سرور نمی‌رسد) و SSRF. مؤثرترین راه دور زدن WAF ابری هم پیدا کردن IP اصلی سرور و اتصال مستقیم به آن است. WAF هرگز نباید به‌عنوان راهکار رفع یک آسیب‌پذیری کد ثبت شود؛ راهکار رفع، تغییر کد است و قاعده‌ی WAF حداکثر یک کاهنده‌ی موقت.
۲. امنیت از راه پنهان‌کاری
تغییر مسیر پنل مدیریت از /admin به /panel-x7، حذف شماره‌ی نسخه از هدرها، یا غیرفعال کردن راست‌کلیک، هیچ‌کدام کنترل امنیتی نیستند. مسیر پنل با یک اسکن مسیر یا از دل فایلهای جاوااسکریپت پیدا میشود. این کارها نوفهی حملات خودکار را کم می‌کنند — که ارزش کوچکی دارد — اما نباید در فهرست کنترل‌های شما جای اقدام واقعی را بگیرند.
۳. اعتماد به شناسه‌های غیرقابل حدس
«از UUID استفاده می‌کنیم پس IDOR نداریم» نادرست است. شناسه‌ی تصادفی فقط هزینه‌ی کشف را بالا میبرد و هیچ بررسی مجوزی اضافه نمی‌کند. UUIDها از مسیرهای دیگر نشت می‌کنند: پاسخ سایر اندپوینت‌ها، خروجی گزارش‌ها، هدر Referer، و پروفایل‌های عمومی.
۴. تکیه بر فریمورک به‌عنوان تضمین
«از فریمورک مدرن استفاده می‌کنیم پس XSS نداریم» نادرست است. فرار دادن پیشفرض فقط متن درونیابیشده را پوشش میدهد. راههای فرار عمدی، صفتهای حاوی آدرس با طرح javascript:، تزریق قالب سمت کلاینت، رندر سمت سرور با وضعیت فرارنداده، و زنجیره‌های آلودگی پروتوتایپ همه باقی میمانند. توضیح دقیق در XSS چیست.
و یک نکته‌ی مثبت در پایان: CSP و Trusted Types ارزش دارند، اما جای خود را دارند. CSP کاهنده‌ی اثر است نه اصلاح آسیب‌پذیری؛ اگر XSS دارید، شدت آن باید مستقل از وجود CSP گزارش شود. سیاست بر پایه‌ی فهرست دامنه هم تقریباً همیشه دور زده میشود — پژوهش گوگل روی سیاست‌های واقعی نشان داد ۱۴ دامنه از ۱۵ دامنه‌ی پرکاربرد در این فهرست‌ها اندپوینت ناامن داشتند. شکل مؤثر، nonce تازه در هر پاسخ همراه با strict-dynamic است.
بعد از فهرست: چطور بفهمیم کار کرده است؟
پس از اجرای فهرست بالا، سه سنجه‌ی معنادار وجود دارد:
- خودارزیابی مجدد. گام‌های بررسی امنیت سایت را دوباره اجرا کنید. اگر مسیرهای افشاشده بسته شده‌اند، اعتبارنامه‌ی پیش‌فرضی باقی نمانده و هدرها و TLS در وضعیت مطلوب‌اند، لایه‌ی اول کارش را کرده است.
- زمان پاسخ به یک CVE فرضی. از تیم بپرسید: «اگر امروز یک آسیب‌پذیری بحرانی در فریمورک ما منتشر شود، چند ساعت طول می‌کشد تا بدانیم متأثر هستیم و چند روز تا وصله را روی عملیات ببریم؟» اگر پاسخ روشن نیست، بند SBOM و اسکن وابستگی هنوز واقعاً انجام نشده.
- ارزیابی مستقل. برای دسته‌هایی که خودارزیابی به آن‌ها دسترسی ندارد — کنترل دسترسی، منطق کسبوکار، شرایط مسابقه — تنها سنجه، آزمون دستی است.
فهرست عملیاتی و قابل چاپ همین اقدامات در چک‌لیست امنیتی در دسترس است. برای فهم ساختار هزینه پیش از سفارش ارزیابی، هزینه‌ی امنیت سایت را ببینید. و اگر میخواهید بدانید پس از اجرای این فهرست چه چیزی باقی مانده، تست نفوذ وب پی‌هانتر با پوشش WSTG، امتیازدهی CVSS و آزمون مجدد پس از رفع، همان پاسخ را میدهد. اگر تیم توسعه‌ی داخلی دارید، دوره‌ی سازمانی توسعه‌ی امن راهی برای تبدیل بندهای سطح کد این فهرست به عادت تیمی است.
پرسش‌های متداول
چگونه امنیت سایت را بالا ببریم؟ از کدام کار شروع کنیم؟
از این پنج کار که همگی امروز قابل انجاماند: فعال کردن MFA روی همهی حسابهای مدیریتی و هاست و دامنه و ایمیل، حذف حسابهای بیاستفاده، بستن فایلهای افشاشده مثل پشتیبان و .git و .env، بهروزرسانی همهی اجزا و حذف افزونههای بیاستفاده، و فعال کردن محدودسازی نرخ ورود. اینها بالاترین نسبت تأثیر به تلاش را دارند.
آیا خرید WAF امنیت سایت را بالا میبرد؟
تا حدی و در محدودهی مشخصی: مسدودسازی اسکن انبوه و بهرهجویی خودکار، محدودسازی نرخ، و خریدن زمان در برابر یک CVE تازه تا اعمال وصلهی واقعی. اما WAF نسبت به کنترل دسترسی شکسته، منطق کسبوکار، شرایط مسابقه و بخش عمدهی DOM XSS نابیناست و اگر IP اصلی سرور از بیرون قابل دسترسی بماند کاملاً دور زده میشود. جانشین امنسازی کد نیست.
تفاوت این مقاله با راهنمای امنیت سایت چیست؟
راهنمای امنیت سایت لایههای امنیت را مفهومی توضیح میدهد: هر لایه چه چیزی را پوشش میدهد و چرا. این مقاله فهرست دستوری و اولویتدار اقدامات با رتبهبندی تلاش و تأثیر است. اگر میخواهید بفهمید، اولی را بخوانید؛ اگر میخواهید اجرا کنید، این یکی را.
تغییر آدرس پنل مدیریت امنیت را بالا میبرد؟
تأثیر واقعی ناچیزی دارد. مسیر پنل با اسکن مسیر، از دل فایلهای جاوااسکریپت، یا از فایلهای متا پیدا میشود. این کار نوفهی حملات خودکار را کم میکند که ارزش کوچکی است، اما کنترل امنیتی نیست و نباید جای MFA و محدودسازی نرخ را بگیرد.
چقدر زمان میبرد تا امنیت سایت را در وضعیت قابل قبول قرار دهیم؟
بندهای پیکربندی — که حدود دو سوم فهرست این مقالهاند — در یک تا دو هفته کاری قابل انجاماند. بندهای سطح کد مثل بازبینی کنترل دسترسی و کوئری پارامتری در همهی مسیرها، به یک یا چند چرخهی توسعه نیاز دارند و باید در برنامهی محصول جای بگیرند. امنیت وضعیت پایدار نیست؛ بهروزرسانی و پایش کار پیوسته است.
آیا استفاده از فریمورک مدرن جلوی XSS و SQL Injection را میگیرد؟
بخش بزرگی از حالتهای ساده را بله، اما تضمین نیست. فرار دادن پیشفرض فریمورکها فقط متن درونیابیشده را پوشش میدهد و راههای فرار عمدی مثل dangerouslySetInnerHTML و v-html، صفتهای حاوی آدرس، و تزریق قالب باقی میمانند. در سمت داده هم کوئری پارامتری شناسهها (نام جدول و ستون و ORDER BY) را پوشش نمیدهد و راههای خام ORM ریسک را برمیگردانند.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.