امنیت سایت جدید: چک‌لیست کامل پیش از انتشار

سایت را ساخته‌اید و آماده‌ی انتشار است. این نقطه، ارزان‌ترین لحظه‌ی عمر پروژه برای انجام کارهای امنیتی است — همان کارهایی که شش ماه بعد، با کاربر واقعی و داده‌ی واقعی، به یک بازسازی پرهزینه تبدیل می‌شوند. این چک‌لیست عمداً کوتاه و اجراپذیر نوشته شده: هر مورد کاری است که امروز چند دقیقه تا چند ساعت وقت می‌گیرد و بعداً روزها. امنیت سایت جدید یک پروژه‌ی جداگانه نیست؛ ده تصمیم درست در آخرین هفته‌ی پیش از انتشار است.

چرا لحظه‌ی پیش از انتشار مهم‌ترین فرصت است

هر کنترل امنیتی دو هزینه دارد: هزینه‌ی پیاده‌سازی و هزینه‌ی عقب‌نشینی. پیش از انتشار، هزینه‌ی دوم صفر است.

• HTTPS اجباری قبل از انتشار: یک تغییر پیکربندی. بعد از انتشار: بازنویسی آدرس‌های ذخیره‌شده، ریدایرکت‌های ۳۰۱، اصلاح محتوای ترکیبی و ریسک از دست دادن اعتبار سئو.
• ساختار کنترل دسترسی درست از ابتدا: چند ساعت طراحی. بعد از انتشار: بازنویسی هر اندپوینت و آزمون مجدد کل برنامه.
• خارج کردن اسرار از مخزن قبل از اولین کامیت عمومی: تقریباً بی‌هزینه. بعد از انتشار: بازنویسی تاریخ مخزن، چرخش همه‌ی کلیدها، و فرض افشا.
• لاگ‌گیری قبل از انتشار: یک پیکربندی. بعد از حادثه: هیچ راهی برای بازسازی گذشته وجود ندارد.

OWASP در نسخه‌ی ۲۰۲۵ دسته‌ی پیکربندی نادرست را از رتبه‌ی ۵ به رتبه‌ی ۲ ارتقا داده و گزارش می‌کند این دسته در ۱۰۰٪ برنامه‌های آزموده‌شده وجود داشته. نکته‌ی امیدبخش این است که تقریباً همه‌ی موارد این دسته بدون تغییر کد قابل رفع‌اند — و اگر پیش از انتشار انجام شوند، عملاً رایگان‌اند. فهرست کامل ده دسته در OWASP Top 10:2025 آمده است.

حذف محتوای نمونه، دمو و اعتبارنامه‌ی پیش‌فرض

این اولین مورد فهرست OWASP در A02:2025 است و دلیل دارد: «برنامه‌ی نمونه روی سرور عملیاتی با اعتبارنامه‌ی پیش‌فرض تغییرنیافته» یکی از رایج‌ترین مسیرهای نفوذ است.

• محتوای دمو قالب را کامل حذف کنید. نصب دموی قالب‌های تجاری معمولاً افزونه‌های اضافی، صفحات نمونه و کاربران آزمایشی می‌آورد. همه را پاک کنید.
• حساب‌های آزمایشی را حذف کنید، نه فقط غیرفعال. حساب test با رمز test123 که «بعداً پاکش می‌کنیم» هرگز پاک نمی‌شود.
• هر اعتبارنامه‌ی پیش‌فرض را عوض کنید: پنل مدیریت، پایگاه‌داده، ابزارهای مدیریت (phpMyAdmin و مشابه)، داشبورد کش، صف پیام، و هر سرویس جانبی.
• ابزارهای توسعه را از محیط عملیاتی حذف کنید: پنل دیباگ فریم‌ورک، مستندات خودکار API که نباید عمومی باشد، ابزارهای پروفایلینگ، و صفحات وضعیت.
• محیط staging را از دسترس عمومی و از ایندکس خارج کنید. نسخه‌ی آزمایشی روی dev.example.com با داده‌ی واقعی و بدون مقاوم‌سازی، یکی از رایج‌ترین راه‌های نشت داده است. آن را با احراز هویت محافظت کنید و داده‌ی واقعی در آن نگذارید.
• پکیج‌ها و سرویس‌های بی‌استفاده را حذف کنید. اصل «پلتفرم حداقلی»: هر مؤلفه‌ای که نصب است ولی استفاده نمی‌شود، سطح حمله‌ی بدون فایده است.

دیباگ، پیام خطا و افشای اطلاعات

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

• حالت دیباگ فریم‌ورک را خاموش کنید و مطمئن شوید متغیر محیطی مربوطه در سرور عملیاتی روی مقدار تولید تنظیم شده.
• صفحات خطای سفارشی بگذارید. کاربر باید یک پیام خطای عمومی ببیند؛ جزئیات فقط در لاگ سمت سرور. Stack trace، مسیر فایل‌ها، نام و نسخه‌ی کامپوننت‌ها و کوئری SQL هرگز نباید در پاسخ HTTP باشند.
• خطاهای پایگاه‌داده را در خروجی نمایش ندهید. پیام خطای پایگاه‌داده به مهاجم ساختار اسکیما را می‌دهد و ساخت تزریق SQL را ساده می‌کند — این دقیقاً یکی از سناریوهای A10:2025 مدیریت نادرست شرایط استثنایی است.
• هدرهای افشاکننده را حذف کنید: نسخه‌ی وب‌سرور، نسخه‌ی زبان، و هدرهای اختصاصی فریم‌ورک. این کار حمله را غیرممکن نمی‌کند اما کار شناسایی خودکار را سخت‌تر می‌کند.
• اصل «شکست بسته» را رعایت کنید: اگر بررسی مجوز به خطا خورد، پاسخ باید رد باشد نه اجازه. «Failing open» یکی از خطرناک‌ترین الگوهای مدیریت خطاست.
• در پاسخ‌های خطای احراز هویت پیام یکسان بدهید تا وجود یا نبود یک حساب لو نرود.

HTTPS، HSTS و هدرهای امنیتی

HTTPS و پیکربندی TLS

• گواهی معتبر با زنجیره‌ی کامل (شامل گواهی‌های میانی) نصب کنید و با یک کلاینت مستقل — نه فقط مرورگر خودتان — آزمایش کنید. علت اهمیت این نکته در خطای گواهی امنیتی سایت توضیح داده شده.
• ریدایرکت کامل HTTP به HTTPS، و سپس فعال‌سازی HSTS با max-age طولانی. اگر همه‌ی زیردامنه‌ها HTTPS دارند، includeSubDomains را اضافه کنید.
• TLS 1.3 را فعال کنید. TLS 1.2 را فقط برای سازگاری و فقط با مجموعه‌سایفرهای ECDHE + AEAD نگه دارید — طبق RFC 10015 (جولای ۲۰۲۶) مجموعه‌سایفرهای RSA ایستا و همه‌ی FFDH/FFDHE در TLS 1.2 منسوخ شده‌اند. TLS 1.0 و 1.1 طبق RFC 8996 باید کامل غیرفعال باشند.
• کوکی‌ها را با Secure، HttpOnly و SameSite صریح تنظیم کنید. به مقدار پیش‌فرض مرورگر تکیه نکنید: کروم به‌صورت پیش‌فرض Lax اعمال می‌کند اما فایرفاکس این کار را نمی‌کند، پس تنظیم صریح تنها راه رفتار یکسان است.
• رکورد CAA در DNS تعریف کنید و پایش انقضای گواهی راه بیندازید. HPKP را پیاده نکنید — از مرورگرها حذف شده است.

هدرهای امنیتی

درباره‌ی CSP یک نکته‌ی مهم: سیاست‌های مبتنی بر فهرست سفید دامنه در عمل دور زده می‌شوند. پژوهش گوگل نشان داد اکثریت قاطع سیاست‌های CSP بررسی‌شده قابل دور زدن بودند و ۱۴ از ۱۵ دامنه‌ی پرکاربرد در فهرست‌های سفید، نقطه‌ی ناامن داشتند. رویکرد درست: script-src 'nonce-{RANDOM}' 'strict-dynamic'; object-src 'none'; base-uri 'none' با nonce تازه در هر پاسخ. توضیح کامل در دانشنامه‌ی CSP.

پاکسازی ریشه‌ی وب: فایل‌هایی که نباید آنجا باشند

این مورد ساده است و اثرش نامتناسب با سادگی‌اش. ابزارهای شناسایی و فازینگ محتوا اولین کاری که می‌کنند همین است.

• پوشه‌ی .git — اگر در ریشه‌ی وب قابل دسترسی باشد، کل تاریخ مخزن، سورس کامل، و هر اسراری که تا حالا کامیت شده قابل بازسازی است. این یکی از پرتکرارترین یافته‌های جدی در سایت‌های تازه‌منتشرشده است. همین نکته برای .svn و .hg هم صادق است.
• فایل‌های بکاپ: backup.zip، site.tar.gz، db.sql، dump.sql و هر فایل با پسوند .bak، .old، .orig، ~.
• فایل‌های پیکربندی و محیطی: .env، config.php.bak، docker-compose.yml، .htpasswd.
• سورس‌مپ‌های تولیدی (.map) که تمام درخت سورس اصلی جاوااسکریپت شما را بازسازی می‌کنند.
• فایل‌های ابزار توسعه: composer.json و package.json با فهرست دقیق نسخه‌ی وابستگی‌ها، فایل‌های CI، و اسکریپت‌های استقرار.
• فهرست‌شدن دایرکتوری را ببندید. بدون آن، حتی فایل‌های بی‌نام هم قابل کشف‌اند.

راستی‌آزمایی سریع: چند مسیر معمول را از بیرون درخواست کنید و مطمئن شوید پاسخ ۴۰۳ یا ۴۰۴ است، نه محتوا.

for p in .git/config .env backup.zip db.sql composer.json; do
  echo -n "$p -> "; curl -s -o /dev/null -w "%{http_code}\n" https://example.com/$p
done

اسرار، متغیرهای محیطی و سورس سمت کلاینت

یک قاعده‌ی ساده که مشکلات زیادی را حذف می‌کند: هر چیزی که به مرورگر می‌رسد، عمومی است. بدون استثنا.

اسرار در سمت کلاینت

• کلید API در جاوااسکریپت، یعنی کلید عمومی. مبهم‌سازی، کدگذاری base64 و مینیفای‌کردن هیچ محافظتی نیستند. اگر یک کلید باید محرمانه بماند، فراخوانی باید از سمت سرور انجام شود.
• سورس باندل‌شده را قبل از انتشار بخوانید. در فایل‌های جاوااسکریپت نهایی به دنبال این‌ها بگردید: کلیدهای سرویس، آدرس اندپوینت‌های داخلی، نام محیط‌های staging، توکن‌های تست، و کامنت‌های توسعه‌دهنده.
• سورس‌مپ‌ها را در تولید منتشر نکنید یا دسترسی به آن‌ها را محدود کنید.
• پرچم‌های ویژگی و منطق مجوز را در کلاینت پیاده نکنید. مخفی کردن یک دکمه، کنترل دسترسی نیست؛ همان درخواست را می‌توان مستقیماً ارسال کرد. کنترل دسترسی همیشه در سمت سرور.

اسرار در مخزن کد

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

این حوزه در OWASP زیر A04:2025 خطاهای رمزنگاری و A06:2025 طراحی ناامن (CWE-256 و CWE-522، ذخیره‌سازی و محافظت ناکافی اعتبارنامه) قرار می‌گیرد. ملاحظات کامل‌تر در حفاظت از اطلاعات سایت آمده است.

مسیر مدیریت، کنترل دسترسی و مجوز فایل‌ها

پنل مدیریت

• MFA را برای همه‌ی حساب‌های اداری از روز اول اجباری کنید. اضافه کردنش بعداً به یک پروژه‌ی تغییر رفتار سازمانی تبدیل می‌شود.
• اگر IP ثابت دارید، دسترسی به مسیر مدیریت را محدود کنید. این مؤثرترین کنترل در این دسته است.
• محدودسازی نرخ ورود با تأخیر تصاعدی، نه قفل دائم که خودش به منع سرویس تبدیل می‌شود.
• مسیر مدیریت را از ایندکس خارج کنید و در صفحات عمومی به آن لینک ندهید. این ابهام است نه امنیت، اما نویز حملات خودکار را کم می‌کند.

کنترل دسترسی

این مهم‌ترین بخش ساختاری است و رتبه‌ی اول OWASP (A01:2025) را دارد. سه اصل که اگر از ابتدا رعایت شوند، بازنویسی بعدی لازم نمی‌شود:

• رد پیش‌فرض. هر مسیر و هر عملیات به‌طور پیش‌فرض ممنوع است، مگر صریحاً مجاز شود.
• یک سازوکار مرکزی برای بررسی مجوز، نه بررسی پراکنده در هر کنترلر. بررسی‌های پراکنده جایی جا می‌افتند.
• اعمال مالکیت در لایه‌ی داده. کوئری را WHERE id = ? AND owner_id = ? بنویسید، نه اینکه رکورد را بخوانید و بعد مالکیت را بررسی کنید. این کار IDOR را ساختاراً حذف می‌کند.

پیش از انتشار، آزمون ساده‌ای انجام دهید: دو حساب با سطوح مختلف بسازید و درخواست‌های حساب پرقدرت را با نشست حساب کم‌قدرت بازپخش کنید. هر پاسخ موفقی یک یافته است.

مجوز فایل و ایزوله‌سازی

• فایل‌ها 644 و پوشه‌ها 755 به‌عنوان قاعده‌ی عمومی؛ هرگز 777.
• کاربر سرویس وب نباید مالک فایل‌هایی باشد که لازم نیست بنویسد.
• اجرای اسکریپت در پوشه‌ی آپلود را غیرفعال کنید. اگر سایت شما آپلود دارد، این مورد اختیاری نیست.
• کاربر پایگاه‌داده باید حداقل دسترسی داشته باشد: بدون سطح ریشه، بدون DDL در تولید، و محدود به همان پایگاه‌داده.

بکاپ، لاگ و هشدار پیش از انتشار

بکاپ

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

لاگ و هشدار

این بند از A09:2025 نقص ثبت رخداد و هشداردهی امنیتی می‌آید و دلیل تغییر نامش از «پایش» به «هشداردهی» همین است: جمع‌آوری لاگ بدون هشدار، در لحظه‌ی حادثه بی‌فایده است.

• چه چیزی را لاگ کنید: ورود موفق و ناموفق، تغییر رمز و ایمیل، ایجاد و تغییر نقش کاربران، شکست کنترل دسترسی، تغییر تنظیمات حساس، عملیات مالی، و خطاهای سرور.
• چه چیزی را لاگ نکنید: رمز عبور، توکن نشست، شماره‌ی کارت، کد یک‌بارمصرف. درج داده‌ی حساس در لاگ خودش یک آسیب‌پذیری است (CWE-532) و لاگ معمولاً کنترل دسترسی ضعیف‌تری از پایگاه‌داده دارد.
• خروجی لاگ را کدگذاری کنید تا تزریق به لاگ (CWE-117) ممکن نشود؛ ورودی کاربر که خام در لاگ می‌نشیند می‌تواند رکوردهای جعلی بسازد و تحلیل را گمراه کند.
• هشدار تعریف کنید برای موارد پرسیگنال: ایجاد کاربر مدیر، تغییر فایل هسته، خطای انبوه ۵xx، جهش نرخ ورود ناموفق.
• عمق نگهداری کافی — لاگی که هفت روزه چرخش می‌کند، برای حادثه‌ای که سه هفته پیش شروع شده بی‌فایده است.

چک‌لیست نهایی پیش از انتشار

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

پرسش‌های متداول

WRITTEN BY

محمدرضا مقدم

توسعه‌دهنده ابزار

مغز خودکارسازی تیم؛ ابزارها و زیرساخت داخلی پی‌هانتر را می‌سازد تا اسکن و گزارش‌گیری سریع‌تر و دقیق‌تر انجام شود.

LinkedIn ↗درباره تیم ←