FREE RESOURCE

چک‌لیست امنیت وب سایت

54 موردی که هر سایت باید رعایت کند — شش بخش عملیاتی و شش بخش در سطح کد، بر پایه‌ی OWASP Top 10:2025 — از رمز عبور تا پایش. موارد را تیک بزنید؛ پیشرفت شما در همین مرورگر ذخیره می‌شود.

این چک‌لیست دو نیمه دارد و تفکیک‌شان مهم است. بخش‌های ۱ تا ۶ لایه‌ی عملیاتی را پوشش می‌دهند — چیزهایی که مدیر سایت، مدیر سیستم یا صاحب کسب‌وکار می‌تواند بدون دست‌زدن به کد کنترل کند. بخش‌های ۷ تا ۱۲ لایه‌ی برنامه هستند و بر پایه‌ی دسته‌های OWASP Top 10:2025 چیده شده‌اند؛ اجرای آن‌ها تقریباً همیشه نیازمند تیم توسعه است.

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

01دسترسی و احراز هویت

  • رمز یکتا و قوی برای همه‌ی حساب‌های مدیریتی
    از مدیر رمز عبور استفاده کنید؛ هیچ رمزی بین دو سرویس مشترک نباشد.
  • احراز هویت دومرحله‌ای (MFA) فعال
    روی پنل مدیریت سایت، هاست، دامنه و ایمیل مرتبط — مؤثرترین اقدام تکی.
  • حذف حساب‌های بلااستفاده
    هر کارمند یا پیمانکاری که رفته، دسترسی‌اش هم باید برود.
  • اصل حداقل دسترسی
    هیچ‌کس نباید بیش از آنچه کارش لازم دارد دسترسی داشته باشد.
  • محدودسازی تلاش ورود
    قفل موقت پس از چند تلاش ناموفق، برای مقابله با Brute Force.

02به‌روزرسانی و وصله

  • هسته‌ی CMS به‌روز است
    وردپرس، جوملا یا هر سامانه‌ی دیگر — بدون تأخیر.
  • افزونه‌ها و قالب‌ها به‌روزند
    و افزونه‌های بلااستفاده حذف (نه فقط غیرفعال) شده‌اند.
  • هیچ افزونه یا قالب نال‌شده‌ای نصب نیست
    قالب «رایگان‌شده» اغلب از پیش آلوده است.
  • نسخه‌ی PHP و پایگاه داده پشتیبانی‌شده است
    نسخه‌های منقضی دیگر وصله‌ی امنیتی نمی‌گیرند.
  • کتابخانه‌های شخص ثالث بررسی شده‌اند
    وابستگی‌های قدیمی، رایج‌ترین در ورودی مهاجم‌اند.

03ارتباط و رمزنگاری

  • گواهی SSL معتبر و فعال
    و تاریخ انقضای آن در تقویم شما یادداشت شده است.
  • انتقال کامل به HTTPS
    همه‌ی درخواست‌های HTTP به HTTPS ریدایرکت می‌شوند.
  • هدرهای امنیتی تنظیم شده‌اند
    HSTS، CSP، X-Content-Type-Options و X-Frame-Options.
  • کوکی‌ها امن پیکربندی شده‌اند
    با پرچم‌های Secure، HttpOnly و SameSite.

04داده و پشتیبان‌گیری

  • پشتیبان‌گیری خودکار روزانه
    بدون استثنا و بدون اتکا به یادآوری انسانی.
  • نسخه‌ی پشتیبان خارج از همان سرور
    باج‌افزار به پشتیبانِ روی همان هاست هم رحم نمی‌کند.
  • بازیابی پشتیبان آزمایش شده است
    پشتیبانی که تست نشده، پشتیبان نیست.
  • داده‌ی حساس رمزنگاری شده است
    رمزها با bcrypt/Argon2، نه MD5 یا متن ساده.

05پیکربندی سرور

  • صفحات دیباگ در محیط عملیاتی خاموش‌اند
    پیام خطای پرجزئیات، نقشه‌ی راه مهاجم است.
  • فهرست‌شدن دایرکتوری‌ها غیرفعال است
    و فایل‌های پشتیبان یا .git از دسترس عمومی خارج‌اند.
  • سرویس‌ها و پورت‌های غیرضروری بسته‌اند
    هر سرویس باز، یک سطح حمله‌ی اضافه است.
  • فایروال برنامه (WAF) فعال است
    لایه‌ی دفاعی مفید در برابر حملات خودکار و شناخته‌شده.
  • دسترسی فایل‌ها درست تنظیم شده است
    مجوز ۷۷۷ روی هیچ فایل یا پوشه‌ای نباشد.

06پایش و واکنش

  • ثبت رخدادهای امنیتی فعال است
    ورود ناموفق، تغییر دسترسی و ویرایش فایل‌های حساس.
  • اسکن دوره‌ای بدافزار انجام می‌شود
    و هشدارها واقعاً توسط کسی دیده می‌شوند.
  • Search Console متصل و پایش می‌شود
    گوگل معمولاً زودتر از شما متوجه آلودگی می‌شود.
  • برنامه‌ی مکتوب واکنش به حادثه دارید
    چه کسی، چه کاری، به چه ترتیبی — پیش از بحران.
  • ارزیابی امنیتی سالانه انجام می‌شود
    تست نفوذ دوره‌ای توسط متخصص مستقل.

07کنترل دسترسی در سطح برنامه

  • هر اندپوینت سمت سرور مجوز را دوباره بررسی می‌کند
    پنهان‌کردن دکمه در رابط کاربری کنترل دسترسی نیست؛ همان درخواست را می‌توان مستقیم فرستاد.
  • دسترسی افقی آزموده شده است
    کاربر A نباید بتواند با تغییر شناسه در آدرس یا بدنه‌ی درخواست، داده‌ی کاربر B را ببیند — همان الگوی IDOR.
  • پیش‌فرض «انکار» است، نه «اجازه»
    هر منبع جدید تا وقتی صریحاً مجاز نشده، باید بسته باشد.
  • شناسه‌ی تصادفی جای کنترل دسترسی را نگرفته است
    UUID فقط حدس‌زدن را سخت می‌کند؛ بررسی مالکیت رکورد همچنان لازم است.
  • درخواست‌های خروجی سرور محدود شده‌اند
    آدرسی که کاربر می‌دهد نباید آزادانه از سمت سرور فراخوانی شود — پیشگیری از SSRF با فهرست مجاز مقصد.

08زنجیره تأمین نرم‌افزار

  • فهرست مؤلفه‌های نرم‌افزاری (SBOM) وجود دارد و به‌روز است
    بدون آن، هنگام انتشار یک CVE مهم نمی‌دانید کجا را باید وصله کنید.
  • وابستگی‌ها فقط از منبع رسمی نصب می‌شوند
    و در صورت وجود، امضای بسته راستی‌آزمایی می‌شود.
  • هشدار آسیب‌پذیری وابستگی‌ها به کسی می‌رسد
    خروجی ابزار بررسی وابستگی باید در مسیر روزمره‌ی تیم باشد، نه در یک گزارش فصلی.
  • دسترسی به مخزن و خط لوله‌ی CI/CD تفکیک و چندعاملی است
    مهاجم برای آلوده‌کردن محصول لازم نیست به سرور شما برسد؛ رسیدن به خط لوله کافی است.

09اعتبارسنجی ورودی و تزریق

  • همه‌ی کوئری‌ها پارامتری هستند
    داده هرگز با الحاق رشته وارد دستور پایگاه داده نمی‌شود.
  • نام جدول و ستون از فهرست مجاز می‌آید
    کوئری پارامتری، شناسه‌ها و ORDER BY را پوشش نمی‌دهد؛ آنجا فقط فهرست مجاز جواب می‌دهد.
  • خروجی متناسب با بافت کدگذاری می‌شود
    HTML، صفت، جاوااسکریپت و URL هرکدام قاعده‌ی خودشان را دارند — پایه‌ی پیشگیری از XSS.
  • فریم‌ورک را ضدXSS فرض نکرده‌اید
    مسیرهایی مثل درج مستقیم HTML یا آدرس کنترل‌شده توسط کاربر همچنان خطرناک‌اند.
  • ورودی کاربر هرگز به فرمان سیستم‌عامل نمی‌رسد
    و اگر ناگزیرید، آرگومان‌ها جداگانه و بدون پوسته اجرا می‌شوند.

10احراز هویت و نشست

  • شناسه‌ی نشست پس از ورود عوض می‌شود
    جلوگیری از تثبیت نشست (Session Fixation).
  • خروج، نشست را سمت سرور باطل می‌کند
    پاک‌کردن کوکی در مرورگر کافی نیست.
  • توکن ضدCSRF سمت سرور بررسی می‌شود
    به رفتار پیش‌فرض مرورگرها تکیه نکنید؛ در همه‌ی مرورگرها یکسان نیست.
  • رمزهای جدید با فهرست رمزهای فاش‌شده مقایسه می‌شوند
    مؤثرتر از قواعد پیچیدگی و تعویض اجباری دوره‌ای.

11ثبت رخداد و هشدار

  • رخدادهای امنیتی با زمینه‌ی کافی ثبت می‌شوند
    ورود ناموفق، رد شدن مجوز، تغییر نقش و تغییر تنظیمات حساس.
  • داده‌ی حساس وارد لاگ نمی‌شود
    رمز، توکن و شماره کارت نباید در لاگ بنشیند.
  • ورودی کاربر پیش از نوشتن در لاگ کدگذاری می‌شود
    وگرنه لاگ خودش قابل جعل و تزریق می‌شود.
  • برای الگوهای مشکوک هشدار تعریف شده و کسی آن را می‌بیند
    لاگی که هیچ‌کس نمی‌خواندش، فقط فضای دیسک است.

12مدیریت خطا و شرایط استثنایی

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

این چک‌لیست چه چیزی را نمی‌گیرد

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

محدودیت دوم، عمق است. «کنترل دسترسی سمت سرور بررسی می‌شود» یک جمله است، اما اثباتش یعنی آزمودن هر اندپوینت با هر نقش. سازمانی که همه‌ی موارد این فهرست را تیک زده باشد وضعیت خیلی بهتری از میانگین دارد، ولی هنوز نمی‌داند در عمل چه چیزی قابل بهره‌برداری است.

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

چند اشتباه رایج هنگام پرکردن چک‌لیست

  • «WAF داریم، پس ورودی‌ها امن‌اند.» فایروال برنامه لایه‌ی مفیدی در برابر حملات خودکار است، اما نسبت به نقص کنترل دسترسی، منطق کسب‌وکار و شرط رقابتی نابیناست و قابل دور زدن است. هیچ‌وقت راهکار رفع یک باگ در کد نیست.
  • «HTTPS داریم، پس داده امن است.» TLS داده را در مسیر محافظت می‌کند، نه در پایگاه داده و نه در لاگ. رمزنگاری در حالت سکون و هش‌کردن نمکدار رمزها بحث جداگانه‌ای است.
  • «فریم‌ورک مدرن استفاده می‌کنیم، پس XSS نداریم.» فرار خودکار فقط درج متن را پوشش می‌دهد؛ درج مستقیم HTML، آدرس کنترل‌شده توسط کاربر و قالب‌سازی سمت کلاینت همچنان مسیر باز می‌گذارند.
  • «پشتیبان داریم.» پشتیبانی که بازیابی‌اش آزمایش نشده، پشتیبان نیست؛ و پشتیبانی که روی همان سرور است، در برابر باج‌افزار بی‌فایده است.
GO DEEPER

چک‌لیست شروع است،
نه پایان کار

برای دیدن آنچه چک‌لیست نمی‌بیند، سایت خود را با دید یک مهاجم واقعی ارزیابی کنید.