Security Misconfiguration چیست؟ مهم‌ترین تنظیمات اشتباهی که امنیت سایت را تهدید می‌کنند

پاسخ کوتاه: Security Misconfiguration یا «پیکربندی نادرست امنیتی» زمانی رخ می‌دهد که سرور، وب‌سایت، CMS، پایگاه داده، سرویس ابری یا یکی دیگر از اجزای زیرساخت با تنظیماتی اجرا شود که سطح دسترسی بیش از حد ایجاد کند، اطلاعات حساس را افشا کند یا قابلیت‌های امنیتی لازم را غیرفعال نگه دارد. فعال‌بودن Debug Mode در سایت اصلی، رمزهای پیش‌فرض، Directory Listing، دسترسی فایل نامناسب، CORS بیش از حد باز، نبود Security Headers، سرویس‌های غیرضروری و Backupهای قابل دسترس از نمونه‌های رایج این مشکل هستند.

بسیاری از مدیران سایت زمانی که درباره امنیت فکر می‌کنند، ابتدا به‌دنبال یک آسیب‌پذیری پیچیده در کد، بدافزار ناشناخته یا حمله Zero-Day می‌گردند. اما در عمل گاهی مهاجم اصلاً نیازی به پیدا کردن یک باگ پیچیده ندارد؛ کافی است مدیر سیستم یک گزینه امنیتی را فراموش کرده باشد، سرویسی غیرضروری باز مانده باشد یا فایلی حساس بدون محدودیت در دسترس قرار گرفته باشد.

این همان نقطه‌ای است که Security Misconfiguration اهمیت پیدا می‌کند.

ممکن است وب‌سایت از آخرین نسخه نرم‌افزار استفاده کند و هیچ آسیب‌پذیری شناخته‌شده‌ای در کد اختصاصی آن وجود نداشته باشد، اما یک تنظیم اشتباه در Web Server، WordPress، Cloud Storage، CORS، PHP، پایگاه داده یا فایل‌های سیستم عملاً یک مسیر جدید برای نفوذ ایجاد کند.

NIST پیکربندی نادرست یا Misconfiguration را تنظیم نادرست یا غیربهینه یک سیستم یا مؤلفه آن تعریف می‌کند که می‌تواند به ایجاد آسیب‌پذیری منجر شود. این تعریف نکته مهمی دارد: برای ناامن‌شدن سیستم همیشه لازم نیست نرم‌افزار «باگ» داشته باشد؛ گاهی قابلیت سالمی که به شکل نامناسب تنظیم شده است، خود به یک مشکل امنیتی تبدیل می‌شود.

اهمیت این موضوع در سال‌های اخیر نیز بیشتر شده است. در OWASP Top 10:2025، Security Misconfiguration با عنوان A02:2025 در رتبه دوم ریسک‌های امنیتی برنامه‌های وب قرار گرفته است؛ در حالی که همین دسته در OWASP Top 10:2021 رتبه پنجم را داشت. OWASP این افزایش اهمیت را تا حدی نتیجه افزایش وابستگی نرم‌افزارهای مدرن به Configuration می‌داند.

در این مقاله از رخنه‌کاو بررسی می‌کنیم Security Misconfiguration چیست، چه تفاوتی با آسیب‌پذیری نرم‌افزاری دارد، کدام تنظیمات اشتباه بیشترین خطر را برای سایت ایجاد می‌کنند و مدیران سایت، توسعه‌دهندگان و مدیران سرور چگونه می‌توانند با یک فرآیند Hardening و Configuration Management منظم جلوی این دسته از مشکلات را بگیرند.

Security Misconfiguration چیست؟

Security Misconfiguration زمانی رخ می‌دهد که یک سیستم از نظر فنی قابلیت کارکرد صحیح داشته باشد، اما Configuration آن با اصول امنیتی سازگار نباشد.

این مشکل می‌تواند در هر لایه‌ای وجود داشته باشد:

• سیستم‌عامل
• Web Server
• PHP یا Runtime
• Database
• CMS مانند WordPress
• Plugin و Theme
• Reverse Proxy
• CDN
• WAF
• Container
• Cloud
• API
• Browser Security Headers
• Authentication
• File Storage
• Backup System
• Logging Infrastructure

بنابراین Security Misconfiguration را نباید صرفاً یک «تنظیم اشتباه سرور» دانست.

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

فعال‌بودن Debug Mode در Production، قابل مشاهده بودن Stack Trace، بازبودن Directory Listing، استفاده از رمز پیش‌فرض، Public شدن Bucket ذخیره‌سازی، بازبودن یک Database روی اینترنت، نبود Attributeهای امنیتی Cookie، CORS بیش از حد گسترده یا باقی‌ماندن یک صفحه آزمایشی روی سرور اصلی.

OWASP در دسته Security Misconfiguration دقیقاً به مواردی مانند نبود Hardening مناسب، فعال‌بودن قابلیت‌های غیرضروری، باقی‌ماندن حساب‌های پیش‌فرض، نمایش Errorهای بیش از حد، Permission اشتباه Cloud، Security Headerهای ناکافی و تنظیمات ناامن Framework، Database و Server اشاره می‌کند.

چرا Security Misconfiguration تا این اندازه مهم است؟

یکی از دلایل اهمیت این مشکل، گستردگی آن است.

یک آسیب‌پذیری خاص ممکن است تنها یک Function یا Endpoint را تحت تأثیر قرار دهد، اما Configuration اشتباه می‌تواند روی کل Application یا حتی کل Server اثر بگذارد.

برای مثال، اگر Directory Listing روی یک مسیر حساس فعال باشد، مشکل ممکن است ده‌ها فایل را افشا کند. اگر IAM Permission یک Cloud Storage اشتباه باشد، مجموعه بزرگی از اطلاعات ممکن است ناخواسته Public شوند. اگر Debug Mode روی Production فعال باشد، چندین Error مختلف می‌توانند جزئیات فنی Application را نمایش دهند.

عامل دوم این است که Misconfiguration اغلب در زمان Deployment اتفاق می‌افتد.

توسعه‌دهنده ممکن است Application را با Configuration مناسب نوشته باشد، اما هنگام انتقال از Development به Production تنظیمی جا بماند.

برای نمونه:

Development:

DEBUG = true

Production نیز ناخواسته:

DEBUG = true

کد Application تغییر نکرده است؛ مشکل فقط Configuration است.

جایگاه Security Misconfiguration در OWASP Top 10:2025

OWASP در نسخه 2025، Security Misconfiguration را به رتبه دوم منتقل کرده است.

طبق داده‌های منتشرشده برای این دسته، ۱۶ CWE به Security Misconfiguration نگاشت شده‌اند و بیش از ۷۱۹ هزار occurrence مرتبط در داده‌های بررسی‌شده وجود داشته است. OWASP همچنین اعلام می‌کند تمام Applicationهای موجود در مجموعه داده برای نوعی Misconfiguration بررسی شده‌اند.

این آمار نباید به این شکل تفسیر شود که «همه سایت‌های دنیا آسیب‌پذیرند»، اما نشان می‌دهد Configuration Security یکی از بخش‌های جدی AppSec مدرن است.

تفاوت Security Misconfiguration با Vulnerability چیست؟

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

اما تفاوت مفهومی مهمی وجود دارد.

یک Software Vulnerability معمولاً ضعف موجود در طراحی یا Implementation نرم‌افزار است.

در مقابل، Security Misconfiguration معمولاً زمانی شکل می‌گیرد که نرم‌افزار یا زیرساخت با گزینه‌های نادرست اجرا شود.

مثال:

فرض کنید نرم‌افزار امکان فعال و غیرفعال کردن Directory Listing را دارد.

وجود این قابلیت لزوماً آسیب‌پذیری نیست.

اما اگر Directory Listing روی مسیری فعال شود که فایل‌های حساس در آن قرار گرفته‌اند، Configuration ناامن ایجاد شده است.

یا فرض کنید یک Framework قابلیت Debugging دارد.

وجود Debug Mode برای Development مفید و حتی ضروری است.

مشکل زمانی ایجاد می‌شود که همان تنظیم در Production باقی بماند.

بنابراین یک ویژگی کاملاً قانونی و سالم می‌تواند به دلیل استفاده نادرست، Security Risk ایجاد کند.

Security Misconfiguration در کدام بخش‌های سایت رخ می‌دهد؟

برای درک بهتر موضوع، بهتر است وب‌سایت را یک Application مستقل نبینیم.

یک سایت مدرن معمولاً زنجیره‌ای از اجزاست:

Internet ↓ CDN / DNS ↓ WAF / Reverse Proxy ↓ Web Server ↓ Runtime ↓ CMS / Application ↓ Database ↓ Storage ↓ Cloud Services / APIs

اگر هرکدام از این لایه‌ها Configuration ضعیفی داشته باشند، امنیت کل سیستم تحت تأثیر قرار می‌گیرد.

به همین دلیل Security Hardening باید کل Stack را پوشش دهد.

1. فعال بودن Debug Mode در سایت اصلی

Debug Mode یکی از مفیدترین ابزارهای توسعه است و یکی از بدترین گزینه‌هایی است که می‌تواند بدون کنترل روی Production باقی بماند.

در Development، نمایش مواردی مثل:

• Stack Trace
• Warning
• Exception
• Database Error
• File Path
• Variable
• Query Error

می‌تواند به توسعه‌دهنده کمک زیادی کند.

اما بازدیدکننده سایت اصلی نباید این اطلاعات را مشاهده کند.

OWASP هشدار می‌دهد Errorهای کنترل‌نشده می‌توانند اطلاعات فنی مفیدی درباره Framework، Server، Library و معماری Application در اختیار مهاجم قرار دهند.

Debug Mode چه اطلاعاتی ممکن است افشا کند؟

بسته به Application، Error Message ممکن است مواردی مانند این را نشان دهد:

/var/www/example.com/public_html/

نام Database Table

نسخه Framework

نام Library

ساختار Directory

نام Function

SQL Query

Internal IP

مسیر Configuration File

این اطلاعات شاید مستقیماً باعث نفوذ نشوند، اما برای Reconnaissance بسیار ارزشمند هستند.

Debug Mode در WordPress

WordPress تنظیم معروف زیر را دارد:

WP_DEBUG

برای محیط Development می‌توان Debugging را فعال کرد، اما روی سایت Production نمایش Error عمومی معمولاً نباید فعال باشد.

مستندات رسمی WordPress برای محیط Production توصیه می‌کنند تنظیماتی مانند WP_DEBUG و WP_DEBUG_DISPLAY غیرفعال باشند. WordPress همچنین هشدار می‌دهد قرارگرفتن debug.log در مسیر Public می‌تواند یک Security Risk ایجاد کند.

نکته مهم این است که فقط:

WP_DEBUG_DISPLAY = false

همیشه کافی نیست.

تنظیم display_errors در PHP نیز باید بررسی شود.

2. نمایش Stack Trace و پیام خطای بیش از حد

Debug Mode تنها منبع Information Disclosure نیست.

حتی Applicationی که Debug آن خاموش است ممکن است Error Handling ضعیفی داشته باشد.

کاربر نهایی معمولاً باید پیام ساده‌ای مانند:

«خطایی رخ داده است. لطفاً دوباره تلاش کنید.»

دریافت کند.

در مقابل، جزئیات فنی باید داخل سیستم Logging ثبت شوند.

نمایش خطاهایی مانند:

Database Connection Failed

SQL Syntax Error

Absolute File Path

Framework Exception

Internal Service URL

می‌تواند اطلاعات غیرضروری در اختیار بازدیدکننده قرار دهد.

OWASP پیشنهاد می‌کند Error Handling به شکل مرکزی طراحی شود تا پاسخ‌های بیش از حد اطلاعاتی کنترل شوند.

3. استفاده از Username و Password پیش‌فرض

یکی از کلاسیک‌ترین Misconfigurationها باقی‌ماندن Credential پیش‌فرض است.

سیستم‌های مختلف ممکن است با حساب‌هایی مانند:

admin

administrator

root

test

demo

نصب شوند.

گاهی نیز Vendor یک Password اولیه مشخص در نظر می‌گیرد.

اگر Credential پیش‌فرض تغییر نکند، مهاجم ممکن است اصلاً نیازی به Exploit پیچیده نداشته باشد.

OWASP به‌طور مشخص فعال‌بودن Default Account و Password را یکی از نشانه‌های Security Misconfiguration معرفی می‌کند.

این مسئله فقط مربوط به WordPress نیست و می‌تواند در موارد زیر دیده شود:

• Router
• Database
• Control Panel
• NAS
• IoT
• Monitoring Dashboard
• CMS
• Application Server
• Development Tool

بعد از نصب هر سرویس باید Accountهای پیش‌فرض بررسی شوند و حساب‌های غیرضروری Disable یا حذف شوند.

4. باز بودن Directory Listing

Directory Listing زمانی رخ می‌دهد که Web Server در نبود فایل Index، فهرست فایل‌های داخل Directory را به بازدیدکننده نمایش دهد.

برای مثال، اگر Directory حاوی این موارد باشد:

Backup

Log

Archive

Old Version

Export

Configuration

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

OWASP در Security Misconfiguration صریحاً Directory Listing فعال را به‌عنوان یک سناریوی ریسک مطرح می‌کند.

Directory Listing لزوماً در تمام مسیرها خطر یکسانی ندارد، اما روی Production معمولاً باید فقط زمانی فعال باشد که نیاز مشخص و کنترل‌شده‌ای وجود دارد.

5. فعال بودن سرویس‌ها و پورت‌های غیرضروری

هر Service اضافه یک Attack Surface جدید ایجاد می‌کند.

فرض کنید یک Web Server صرفاً به HTTPS نیاز دارد، اما موارد زیر نیز روی اینترنت باز هستند:

• Database Port
• Development Server
• Remote Debugger
• Monitoring UI
• Management Interface
• Testing Service

هرکدام نیازمند Update، Authentication و Security Configuration مستقل هستند.

اصل مهم Hardening این است:

هر چیزی که موردنیاز نیست، بهتر است فعال نباشد.

OWASP نیز حذف Feature، Port، Service، Page و Account غیرضروری را بخشی از پیشگیری از Security Misconfiguration می‌داند.

این رویکرد با اصل Attack Surface Reduction هماهنگ است.

6. Permission اشتباه فایل‌ها و Directoryها

File Permission بیش از حد باز یکی از مشکلات مهم مخصوصاً در هاست و WordPress است.

اگر Process وب‌سرور بتواند بدون نیاز روی تمام فایل‌ها Write داشته باشد، در صورت Compromise شدن Application دامنه خسارت می‌تواند افزایش پیدا کند.

اصل مناسب این است:

فقط همان دسترسی لازم، نه بیشتر.

مستندات WordPress نیز توصیه می‌کنند Permissionها تا حد ممکن محدود باشند و فایل‌هایی که نیاز واقعی به Write توسط Web Server ندارند، Writable نباشند.

چرا Permission 777 معمولاً انتخاب بدی است؟

گاهی برای رفع سریع مشکل Upload یا Install، مدیر سایت Permission را بیش از حد باز می‌کند.

ممکن است مشکل موقتاً حل شود، اما امنیت کاهش پیدا کند.

راه صحیح این است که ابتدا مشخص شود:

• Owner چه Userی است؟
• Web Server با چه Userی اجرا می‌شود؟
• کدام Directory واقعاً Write نیاز دارد؟
• آیا Group Permission کافی است؟
• آیا ACL مناسب‌تر است؟

Permission نباید صرفاً برای «کارکردن سایت» تا بیشترین سطح افزایش پیدا کند.

7. فایل‌های Backup داخل Public Web Root

یکی از خطرناک‌ترین اشتباهات عملی، قرار دادن Backup در مسیر قابل دسترس سایت است.

نمونه:

/backup/

/old/

/site-backup.zip

/database.sql

/public_html/backup.tar.gz

Backup ممکن است شامل تمام موارد زیر باشد:

• Source Code
• Database
• Email
• User Data
• API Key
• Configuration
• Password Hash
• Secret

بنابراین Backup باید در Storage مناسب، با Access Control مشخص و ترجیحاً خارج از Public Web Root نگهداری شود.

نکته مهم:

داشتن Backup امنیت است؛

اما Backup ناامن خودش می‌تواند منبع Data Breach باشد.

8. باقی ماندن فایل‌های قدیمی و نسخه‌های موقت

فایل‌هایی با نام‌هایی مانند:

config.php.old

index.php.bak

backup.zip

test.php

phpinfo.php

database.sql

ممکن است از طریق Application عادی استفاده نشوند، اما Web Server همچنان آن‌ها را Serve کند.

این مشکل زمانی خطرناک‌تر می‌شود که فایل قدیمی Configuration حاوی Credential باشد.

فرآیند Deployment باید طوری طراحی شود که Artifactهای موقت به Production منتقل نشوند.

9. صفحه phpinfo روی سرور اصلی

phpinfo() ابزار خوبی برای بررسی Environment است.

اما خروجی آن می‌تواند حجم زیادی از اطلاعات Runtime را نمایش دهد.

بسته به Configuration، اطلاعاتی مانند این موارد قابل مشاهده هستند:

• PHP Version
• Extensions
• Server Variables
• Paths
• Environment
• Configuration Values

بنابراین صفحه تست phpinfo نباید بدون کنترل روی Production باقی بماند.

مشکل خود phpinfo نیست؛ مشکل Public Exposure آن است.

10. تنظیم اشتباه CORS

Cross-Origin Resource Sharing یا CORS یکی از بخش‌هایی است که Configuration اشتباه آن می‌تواند امنیت API را کاهش دهد.

Browserها به‌طور پیش‌فرض Same-Origin Policy دارند.

CORS به Server اجازه می‌دهد مشخص کند کدام Originهای دیگر مجاز هستند از طریق Browser به Resource دسترسی داشته باشند.

MDN توصیه می‌کند Access-Control-Allow-Origin فقط حداقل Originهای لازم برای عملکرد سرویس را مجاز کند.

CORS بیش از حد باز

برای یک API عمومی ممکن است:

Access-Control-Allow-Origin: *

کاملاً منطقی باشد.

اما همین تنظیم روی Endpoint حاوی اطلاعات خصوصی می‌تواند نامناسب باشد.

بنابراین نباید صرفاً به این دلیل که Frontend با CORS Error مواجه شده است، Policy را برای همه Originها باز کرد.

راه صحیح:

1. مشخص‌کردن Originهای موردنیاز
2. بررسی Endpointهای دارای Credential
3. محدودکردن Methodها
4. محدودکردن Headerها
5. تست رفتار Browser

CORS یک Access Control عمومی برای Server نیست؛ بلکه Mechanism مربوط به رفتار Cross-Origin در Browser است.

11. نبود یا تنظیم اشتباه Security Headers

Security Headerها یکی از لایه‌های ساده اما مهم دفاعی هستند.

OWASP اشاره می‌کند HTTP Security Response Headerها می‌توانند در کاهش خطرهایی مانند XSS، Clickjacking و Information Disclosure نقش داشته باشند.

Headerهای مهم بسته به معماری سایت می‌توانند شامل موارد زیر باشند.

Content-Security-Policy

CSP مشخص می‌کند Browser چه منابعی را مجاز است Load یا Execute کند.

MDN توضیح می‌دهد CSP می‌تواند در کنترل Sourceهای Script و کاهش خطر XSS و Clickjacking نقش داشته باشد.

اما CSP پیچیده است.

یک Policy اشتباه ممکن است سایت را خراب کند یا آن‌قدر باز باشد که ارزش امنیتی کمی داشته باشد.

بهتر است ابتدا Policy در حالت Report-Only بررسی و سپس با تحلیل دقیق اعمال شود.

Strict-Transport-Security

HSTS به Browser اعلام می‌کند Host باید از طریق HTTPS باز شود.

MDN توضیح می‌دهد Browser پس از دریافت HSTS در Requestهای آینده HTTP را به HTTPS Upgrade می‌کند و روی Host دارای HSTS اجازه Bypass ساده خطای Certificate را نمی‌دهد.

اما گزینه:

includeSubDomains

باید با احتیاط فعال شود.

اگر Subdomainی HTTPS مناسب نداشته باشد، ممکن است دسترسی به آن دچار مشکل شود.

X-Content-Type-Options

مقدار شناخته‌شده:

nosniff

به Browser اعلام می‌کند MIME Type اعلام‌شده را رعایت کند و از برخی رفتارهای MIME Sniffing جلوگیری کند.

Referrer-Policy

این Header مشخص می‌کند چه مقدار اطلاعات Referer هنگام Navigation یا بارگذاری Resourceهای Cross-Origin ارسال شود.

MDN توصیه می‌کند Policy متناسب با نیاز و Privacy انتخاب شود.

frame-ancestors و X-Frame-Options

برای مقابله با Clickjacking می‌توان Embedding سایت در iframe را محدود کرد.

MDN frame-ancestors در CSP را گزینه انعطاف‌پذیرتر معرفی می‌کند.

Permissions-Policy

این Header می‌تواند قابلیت‌هایی مانند Camera، Microphone و Geolocation را برای Document و iframeها محدود کند.

البته برخی Directiveهای Permissions Policy هنوز پشتیبانی Browser یکسانی ندارند و Compatibility باید بررسی شود.

12. HTTPS ناقص یا پیکربندی اشتباه TLS

وجود SSL Certificate به‌تنهایی به این معنی نیست که HTTPS به‌درستی پیاده‌سازی شده است.

مشکلات احتمالی:

• بخشی از سایت هنوز HTTP است.
• Login روی HTTP قابل دسترسی است.
• Mixed Content وجود دارد.
• Redirect درست انجام نمی‌شود.
• Cookie حساس بدون Secure است.
• Reverse Proxy Scheme را اشتباه تشخیص می‌دهد.
• Certificate Chain مشکل دارد.

در WordPress می‌توان برای بخش مدیریت از FORCE_SSL_ADMIN استفاده کرد و مستندات رسمی WordPress نیز آن را برای اجبار SSL روی Login و Admin توضیح می‌دهند.

با این حال در معماری مدرن بهتر است کل سایت روی HTTPS ارائه شود.

13. تنظیم اشتباه Cookieهای احراز هویت

Cookieهای Authentication باید بر اساس Risk و معماری سایت تنظیم شوند.

Attributeهای مهم عبارت‌اند از:

Secure

HttpOnly

SameSite

Domain مناسب

Path مناسب

Expiration مناسب

برای مثال، Cookie احراز هویت روی HTTPS معمولاً نباید بدون Secure باشد.

یا Session Cookie حساس معمولاً نباید بی‌دلیل از طریق JavaScript قابل خواندن باشد.

OWASP نیز Cookie بدون Secure و Cookie حساس بدون HttpOnly را در CWEهای نگاشت‌شده به Security Misconfiguration قرار داده است.

14. دسترسی عمومی به Database

Database معمولاً نباید بدون نیاز واقعی از کل اینترنت قابل دسترسی باشد.

برای یک معماری ساده:

Web Server → Database

اگر فقط Web Server باید به Database متصل شود، بازکردن پورت Database برای تمام اینترنت Attack Surface را افزایش می‌دهد.

راهکارهای رایج دفاعی:

• Private Network
• Firewall
• Security Group
• محدودکردن Source IP
• Authentication قوی
• TLS در صورت نیاز
• عدم استفاده از Root برای Application

Application نیز باید Database User مخصوص خود با حداقل Privilege لازم داشته باشد.

15. Public شدن Cloud Storage

با گسترش Cloud، Misconfiguration دیگر فقط مربوط به Apache و PHP نیست.

Storageهای ابری، Object Storage، Database Cloud و IAM نیز می‌توانند اشتباه تنظیم شوند.

مثلاً Bucketی که قرار بوده فقط Backend به آن دسترسی داشته باشد، ممکن است Public شود.

یا Permissionی مانند Read/Write به Scope بسیار گسترده داده شود.

OWASP در تعریف Security Misconfiguration به Permission اشتباه سرویس‌های Cloud نیز اشاره می‌کند.

اصل مهم:

Public Access باید انتخاب آگاهانه باشد، نه حالت حاصل از اشتباه.

16. استفاده بیش از حد از Wildcard در Permissionها

Wildcard راه سریعی برای حل Permission Error است.

اما مثال مفهومی:

«اجازه همه عملیات روی همه Resourceها»

معمولاً با اصل Least Privilege سازگار نیست.

Permission باید بر اساس Need-to-Know و Need-to-Use تعریف شود.

این موضوع برای:

• IAM
• API
• Cloud
• Kubernetes
• Database
• File System

اهمیت دارد.

17. باقی ماندن Environmentهای Test و Staging در دسترس عموم

گاهی تیم توسعه Production را کاملاً امن می‌کند، اما Staging فراموش می‌شود.

مشکلات رایج Staging:

• Password ساده
• Debug فعال
• Database Copy واقعی
• Authentication ضعیف
• Search Engine Indexing
• Test Account
• Plugin قدیمی

مهاجم اهمیتی نمی‌دهد Data Leak از Production اتفاق بیفتد یا Staging.

اگر Staging حاوی نسخه‌ای از اطلاعات واقعی کاربران باشد، باید با همان حساسیت محافظت شود.

بهتر است داده Production بدون ضرورت به Development و Staging منتقل نشود.

18. اشتراک Credential بین Development و Production

این یکی از Misconfigurationهای خطرناک DevOps است.

Production نباید همان موارد زیر را با محیط Development به اشتراک بگذارد:

• Database Password
• API Key
• SSH Key
• Cloud Credential
• Encryption Secret
• Admin Password

در صورت Compromise شدن محیط Development، مهاجم نباید Credential لازم برای Production را نیز به دست آورد.

Environmentها باید جداسازی امنیتی داشته باشند.

19. قرار دادن Secret داخل Source Code یا Configuration عمومی

API Key و Password نباید در Repository عمومی یا فایل‌هایی که از طریق Web قابل دسترسی هستند قرار بگیرند.

OWASP در Security Misconfiguration جدید نیز استفاده از Credentialهای کوتاه‌عمر یا Role-Based Access را به‌جای Embedded Static Secret توصیه می‌کند.

Secrets باید:

• قابل Rotation باشند.
• Access Control داشته باشند.
• Log نشوند.
• در Build Artifact عمومی قرار نگیرند.
• بین Environmentها جدا باشند.

20. Logهای قابل دسترس از وب

Logging یک کنترل امنیتی مهم است، اما Log در صورت Exposure می‌تواند خودش منبع Information Disclosure باشد.

Log ممکن است شامل موارد زیر باشد:

• IP
• Email
• File Path
• Error
• Token
• URL
• Internal Endpoint

بنابراین Log نباید بی‌دلیل زیر Web Root قرار گیرد.

این مسئله در WordPress با debug.log نیز اهمیت دارد. WordPress Developer Documentation هشدار می‌دهد فایل Debug Log در محل Public می‌تواند خطر امنیتی ایجاد کند و بهتر است Log خارج از Public Root نگهداری شود یا حداقل دسترسی HTTP به آن محدود شود.

21. فعال بودن ابزارهای مدیریتی بدون محدودیت

پنل‌هایی مانند:

Database Admin

Server Dashboard

Monitoring UI

Queue Dashboard

Container Management

نباید صرفاً به دلیل راحتی روی اینترنت Public شوند.

یک Management Interface می‌تواند امکاناتی بسیار فراتر از Application اصلی داشته باشد.

راهکارهای مناسب بسته به شرایط:

• VPN
• Zero Trust Access
• IP Allowlist
• MFA
• SSO
• Separate Management Network

هدف این است که Administrative Plane تا حد امکان از Public Application جدا باشد.

22. تنظیم نادرست Reverse Proxy و Trusted Proxy

وقتی Application پشت:

CDN

Load Balancer

Reverse Proxy

WAF

قرار دارد، تشخیص IP واقعی Client و Scheme درخواست ممکن است به Headerهایی مانند X-Forwarded-For و X-Forwarded-Proto وابسته شود.

اگر Application هر Header ورودی را بدون مشخص‌کردن Trusted Proxy معتبر بپذیرد، ممکن است Security Logic اشتباه عمل کند.

برای مثال:

• IP-based Rate Limit
• HTTPS Detection
• Audit Log
• Redirect
• Access Control

می‌توانند داده نادرست دریافت کنند.

بنابراین Trusted Proxy باید صریحاً Configuration شود.

23. اعتماد بیش از حد به WAF

فعال‌بودن WAF به این معنی نیست که Configuration داخلی Application اهمیتی ندارد.

WAF ممکن است بخشی از Requestهای مخرب را تشخیص دهد، اما مواردی مانند:

• Public Backup
• Permission اشتباه
• Credential پیش‌فرض
• Open Database
• Debug Mode
• Public Bucket

را الزاماً حل نمی‌کند.

WAF یک Defense Layer است، نه جایگزین Hardening.

24. WordPress و Security Misconfiguration

WordPress به‌خودی‌خود الزاماً ناامن نیست؛ اما انعطاف زیاد آن باعث می‌شود Configuration اهمیت زیادی داشته باشد.

مستندات رسمی WordPress یک Hardening Guide مستقل دارد و موضوعاتی مانند:

• File Permissions
• Database Security
• wp-admin
• wp-config.php
• File Editing
• Pluginها
• Backup
• Logging
• Monitoring

را پوشش می‌دهد.

مهم‌ترین Misconfigurationهای WordPress

موارد رایج عبارت‌اند از:

• WP_DEBUG فعال در Production
• debug.log قابل دسترس
• HTTPS ناقص
• Permission بیش از حد باز
• Administratorهای غیرضروری
• Plugin و Theme بلااستفاده
• Editor فایل فعال در محیط حساس
• Backup داخل public_html
• wp-config.php با Permission نامناسب
• Staging عمومی
• Passwordهای ضعیف حساب‌های مدیریتی

غیرفعال کردن File Editor در WordPress

WordPress به Administrator اجازه می‌دهد فایل Theme و Plugin را از Dashboard ویرایش کند.

در محیط‌هایی که به این قابلیت نیازی ندارند می‌توان با:

DISALLOW_FILE_EDIT

آن را غیرفعال کرد.

مستندات Hardening رسمی WordPress نیز این گزینه را به‌عنوان یک اقدام دفاعی معرفی می‌کند؛ هرچند تأکید می‌کند این کنترل به‌تنهایی جلوی تمام روش‌های Upload یا تغییر فایل را نمی‌گیرد.

یعنی این گزینه یک لایه دفاعی است، نه راه‌حل کامل.

25. Plugin و Themeهای بلااستفاده

اگر Plugin واقعاً استفاده نمی‌شود، نگهداری آن معمولاً مزیت امنیتی ندارد.

هر Component اضافه:

• نیاز به Update دارد.
• Attack Surface را افزایش می‌دهد.
• Configuration بیشتری ایجاد می‌کند.
• ممکن است بعداً فراموش شود.

WordPress Hardening Guide نیز توصیه می‌کند Pluginهای استفاده‌نشده حذف شوند.

Deactivate با Delete یکی نیست.

اگر Plugin دیگر لازم نیست، حذف کامل آن معمولاً منطقی‌تر است.

26. تنظیمات اشتباه Upload

File Upload یکی دیگر از نقاطی است که Configuration نقش مهمی دارد.

حتی اگر Upload Validation مناسب باشد، Directory Upload باید با Policy درست اداره شود.

برای مثال باید بررسی شود:

• آیا فایل Uploadشده می‌تواند به‌عنوان Script اجرا شود؟
• آیا فایل Private مستقیماً Public URL دارد؟
• آیا حجم Upload محدود است؟
• آیا MIME Type بررسی می‌شود؟
• آیا Extension Allowlist وجود دارد؟
• آیا نام فایل امن‌سازی می‌شود؟

اصل مهم این است که Storage User Content تا حد امکان از Code Execution جدا باشد.

27. قابلیت‌های پیش‌فرض و Sample Applicationها

بعضی Serverها و Frameworkها همراه مواردی مانند:

• Demo
• Example App
• Test Endpoint
• Documentation
• Default Console

نصب می‌شوند.

اگر در Production نیازی به آن‌ها وجود ندارد، باید حذف شوند.

OWASP در سناریوی Security Misconfiguration مثال می‌زند که باقی‌ماندن Sample Application یا Admin Console با Default Account می‌تواند مسیر Compromise ایجاد کند.

این مسئله نمونه واضح اصل:

Minimal Platform

است.

چگونه Security Misconfiguration را پیدا کنیم؟

هیچ ابزار واحدی نمی‌تواند تمام Misconfigurationها را تشخیص دهد.

بررسی باید چندلایه باشد.

Configuration Review

فایل‌ها و تنظیمات مهم بررسی شوند:

Web Server

PHP

Database

CMS

Firewall

Cloud IAM

Storage

CDN

WAF

Header Review

Response Headerهای سایت بررسی شوند.

Port Review

مشخص شود کدام Serviceها روی Network قابل دسترسی هستند.

Permission Review

File Permission، Database Privilege و IAM Policy بررسی شوند.

Environment Review

Production، Staging و Development از نظر Configuration مقایسه شوند.

External Attack Surface Review

بررسی شود چه Subdomain، Service، Panel و Endpointهایی از اینترنت دیده می‌شوند.

Automated Configuration Scanning

در زیرساخت بزرگ می‌توان Configuration Policy را به شکل خودکار بررسی کرد.

اما Scanner نباید جای Manual Review را کاملاً بگیرد.

Security Hardening چیست؟

Security Hardening یعنی کاهش سطح حمله از طریق حذف قابلیت‌های غیرضروری و اعمال Configuration امن.

Hardening خوب معمولاً شامل این موارد است:

• حذف Service غیرضروری
• حذف Account غیرضروری
• تغییر Default Credential
• محدودکردن Permission
• بستن Port غیرضروری
• فعال‌سازی HTTPS
• تنظیم Security Header
• محدودکردن Management Access
• غیرفعال‌کردن Debug
• امن‌سازی Logging
• Update
• Monitoring

هدف Hardening این نیست که تمام Featureها خاموش شوند.

هدف این است که:

فقط قابلیت‌هایی که Application واقعاً نیاز دارد فعال بمانند.

چرا Hardening باید قابل تکرار باشد؟

یکی از نکات مهم OWASP این است که فرآیند Hardening باید Repeatable باشد.

فرض کنید شرکت ۲۰ Server دارد.

اگر هر Server به‌صورت دستی و بر اساس حافظه Administrator تنظیم شود، احتمال Drift بالا می‌رود.

Server 1:

Secure

Server 2:

یک گزینه فراموش شده

Server 3:

Debug فعال

Server 4:

Port اضافه

راه بهتر تعریف Baseline مشخص است.

NIST SP 800-128 نیز Configuration Management امنیت‌محور را فرآیندی برای مدیریت و Monitoring Configuration سیستم‌ها با هدف کاهش Risk معرفی می‌کند.

Configuration Baseline چیست؟

Baseline مجموعه‌ای از تنظیمات تأییدشده برای یک نوع سیستم است.

برای مثال Baseline سرور WordPress می‌تواند تعیین کند:

• فقط Portهای مشخص باز باشند.
• HTTPS اجباری باشد.
• Debug خاموش باشد.
• File Permission مطابق Policy باشد.
• Backup خارج از Web Root باشد.
• Database Public نباشد.
• Logging فعال باشد.
• Security Update انجام شود.

هر Server جدید باید بر اساس همین Baseline ساخته شود.

این روش Configuration Drift را کاهش می‌دهد.

Configuration Drift چیست؟

Configuration Drift زمانی رخ می‌دهد که وضعیت واقعی Server به‌تدریج از Configuration تأییدشده فاصله بگیرد.

برای مثال:

روز اول:

Port 3306 بسته است.

شش ماه بعد برای تست موقت باز می‌شود.

تست تمام می‌شود.

اما Port فراموش می‌شود.

این دقیقاً نوعی Configuration Drift است.

یا:

Debug برای پیدا کردن Bug فعال می‌شود.

Bug حل می‌شود.

Debug فعال باقی می‌ماند.

بنابراین تغییرات موقت نیز باید Change Management داشته باشند.

Infrastructure as Code چه کمکی می‌کند؟

در زیرساخت‌های مدرن می‌توان بخشی از Configuration را به Code تبدیل کرد.

مزایا:

• Version Control
• Peer Review
• Repeatability
• Auditability
• Automated Testing
• Rollback

اما Infrastructure as Code خودبه‌خود امن نیست.

اگر Template ناامن باشد، همان Misconfiguration می‌تواند به ده‌ها Server تکثیر شود.

بنابراین Automation هم قدرت دفاع دارد و هم قدرت تکثیر اشتباه.

Dev، Staging و Production باید جدا باشند

یکی از اصول مهم Secure Deployment این است که محیط‌ها Identity و Secret مستقل داشته باشند.

مثلاً:

Development Database Credential

نباید همان:

Production Database Credential

باشد.

همچنین Developer Account نباید الزاماً Administrator Production باشد.

جداسازی محیط‌ها باعث می‌شود Compromise یک Environment مستقیماً به Environment دیگر سرایت نکند.

مهم‌ترین تنظیمات اشتباهی که باید سریع بررسی شوند

اولویت دقیق همیشه باید بر اساس Context و Risk واقعی سیستم تعیین شود.

اشتباهات رایج هنگام رفع Security Misconfiguration

کپی کردن Configuration اینترنتی بدون بررسی

یک Header یا Server Config ممکن است برای یک سایت عالی و برای سایت دیگر نامناسب باشد.

برای مثال CSP باید بر اساس Resourceهای واقعی سایت ساخته شود.

باز کردن Permission برای حل Error

اگر Application Permission Error دارد، راه‌حل حرفه‌ای بررسی Ownership و Need واقعی است؛ نه افزایش بی‌هدف Permission.

استفاده از Wildcard برای حل CORS

CORS Error یک نشانه است که Policy باید درست تنظیم شود، نه اینکه الزاماً همه Originها مجاز شوند.

فعال کردن HSTS بدون بررسی Subdomainها

includeSubDomains می‌تواند روی تمام Subdomainها اثر بگذارد.

قبل از فعال‌کردن باید HTTPS همه آن‌ها بررسی شود.

اعتماد به Scanner

Scanner ممکن است Header را ببیند، اما نمی‌داند Business Logic سایت چیست.

مثلاً ممکن است Access-Control-Allow-Origin: * روی API عمومی کاملاً صحیح باشد.

Configuration همیشه باید در Context بررسی شود.

تغییر Production بدون Backup و Rollback

Security Hardening نیز می‌تواند Application را خراب کند.

قبل از تغییر Configuration حساس:

• Backup
• Test
• Change Record
• Rollback Plan

لازم است.

اگر Security Misconfiguration پیدا کردیم چه کنیم؟

اولین اقدام نباید همیشه «سریعاً تغییر همه چیز» باشد.

فرآیند منطقی‌تر:

1. Risk را مشخص کنید

آیا Configuration واقعاً Exploitable است؟

چه Data یا Functionی تحت تأثیر است؟

2. Exposure را بررسی کنید

آیا این Configuration از Internet قابل دسترسی بوده است؟

3. Logها را بررسی کنید

آیا شواهدی از استفاده غیرمجاز وجود دارد؟

4. Configuration را اصلاح کنید

با کمترین اختلال و بر اساس Baseline امن.

5. Credentialها را Rotate کنید

اگر احتمال Exposure Secret وجود دارد، صرف بستن مسیر کافی نیست.

Credential افشاشده باید Invalid و جایگزین شود.

6. Root Cause را پیدا کنید

چرا Misconfiguration ایجاد شد؟

اشتباه انسانی؟

Deployment Script؟

Documentation ناقص؟

Configuration Drift؟

7. جلوی تکرار را بگیرید

Policy یا Automation باید اصلاح شود.

چک‌لیست Security Misconfiguration برای مدیر سایت

موارد زیر را به‌صورت دوره‌ای بررسی کنید:

• آیا HTTPS روی تمام سایت فعال است؟
• آیا HTTP به HTTPS Redirect می‌شود؟
• آیا Debug Mode خاموش است؟
• آیا Errorهای فنی به کاربران نمایش داده نمی‌شوند؟
• آیا Backup خارج از Public Web Root است؟
• آیا Directory Listing غیرضروری غیرفعال است؟
• آیا فایل‌های .bak، .old، .sql و .zip عمومی وجود ندارند؟
• آیا Serviceهای غیرضروری بسته‌اند؟
• آیا Database از اینترنت Public نیست؟
• آیا Permission فایل‌ها حداقلی است؟
• آیا حساب‌های Default حذف یا امن شده‌اند؟
• آیا Administrator غیرضروری وجود ندارد؟
• آیا Cloud Storage Public نیست مگر با نیاز مشخص؟
• آیا CORS محدود است؟
• آیا Security Headerها بررسی شده‌اند؟
• آیا Cookieهای حساس Configuration مناسب دارند؟
• آیا Management Panel محدود شده است؟
• آیا Logها Public نیستند؟
• آیا Staging محافظت شده است؟
• آیا Environment Secretها جدا هستند؟
• آیا Plugin و Theme بلااستفاده حذف شده‌اند؟
• آیا Configuration Changeها ثبت می‌شوند؟
• آیا Security Baseline مشخص دارید؟
• آیا Configuration Drift پایش می‌شود؟

چک‌لیست ویژه WordPress

برای سایت WordPress علاوه بر چک‌لیست عمومی، این موارد اهمیت بیشتری دارند:

• WP_DEBUG روی Production غیرفعال باشد.
• WP_DEBUG_DISPLAY بررسی شود.
• PHP display_errors بررسی شود.
• debug.log Public نباشد.
• HTTPS روی Login و Admin اجباری باشد.
• Permissionهای WordPress بررسی شوند.
• wp-config.php محافظت شود.
• Pluginهای غیرضروری حذف شوند.
• Themeهای بلااستفاده حذف شوند.
• Administratorها حداقل باشند.
• 2FA برای Administratorها فعال باشد.
• File Editor در صورت عدم نیاز غیرفعال شود.
• Backup خارج از public_html باشد.
• Database Public نباشد.
• Staging با Production Secret مشترک نداشته باشد.
• Security Logging و Monitoring فعال باشد.

مستندات رسمی WordPress نیز بر Hardening، File Permissions، محافظت از wp-config.php، حذف Pluginهای بلااستفاده، Logging و Monitoring تأکید دارند.

Security Misconfiguration و اصل Least Privilege

یکی از مفاهیمی که تقریباً در تمام این مقاله تکرار می‌شود، Least Privilege است.

User باید فقط Permission موردنیاز خود را داشته باشد.

Application باید فقط Permission موردنیاز خود را داشته باشد.

Database User باید فقط Queryهای موردنیاز را انجام دهد.

Cloud Role باید فقط Resourceهای ضروری را ببیند.

Server باید فقط Portهای ضروری را باز کند.

Cookie باید فقط Domain لازم را پوشش دهد.

CORS باید فقط Originهای لازم را مجاز کند.

هرچه Scope کمتر باشد، Blast Radius یک Incident نیز کاهش پیدا می‌کند.

آیا Security Misconfiguration فقط مشکل مدیر سرور است؟

خیر.

مسئولیت Configuration Security بین چند نقش تقسیم می‌شود:

Developer

DevOps

SysAdmin

Cloud Engineer

Security Team

WordPress Administrator

Hosting Provider

گاهی Developer گزینه Debug را فعال می‌گذارد.

گاهی DevOps Secret را اشتباه Deploy می‌کند.

گاهی SysAdmin پورت غیرضروری باز می‌گذارد.

گاهی مدیر WordPress Plugin بلااستفاده را حذف نمی‌کند.

به همین دلیل Configuration Security یک فرآیند تیمی است.

آیا به‌روزرسانی نرم‌افزار Security Misconfiguration را حل می‌کند؟

نه الزاماً.

Update بسیار مهم است، اما Update و Configuration دو مسئله متفاوت‌اند.

ممکن است آخرین نسخه Nginx، PHP و WordPress را داشته باشید و همچنان:

Debug فعال باشد.

Backup Public باشد.

Database باز باشد.

Permission اشتباه باشد.

بنابراین Patch Management و Configuration Management باید در کنار یکدیگر اجرا شوند.

آیا WAF می‌تواند Security Misconfiguration را جبران کند؟

در بعضی موارد WAF می‌تواند Risk را کاهش دهد، اما معمولاً جایگزین اصلاح Configuration نیست.

اگر یک Backup عمومی وجود دارد، بهترین اقدام محافظت یا انتقال همان Backup است.

اگر Database Public است، باید Network Access اصلاح شود.

اگر Debug فعال است، باید Debug خاموش شود.

Defense in Depth یعنی:

WAF + Hardening + Secure Configuration + Monitoring

نه:

WAF به‌جای همه چیز.

سؤال‌های متداول درباره Security Misconfiguration

Security Misconfiguration چیست؟

Security Misconfiguration یا پیکربندی نادرست امنیتی زمانی ایجاد می‌شود که Server، Application، CMS، Cloud Service یا یکی از اجزای زیرساخت با تنظیمات ناامن اجرا شود. فعال بودن Debug، Permission بیش از حد، رمز پیش‌فرض و سرویس‌های غیرضروری نمونه‌های آن هستند.

آیا Security Misconfiguration در OWASP Top 10 قرار دارد؟

بله. در OWASP Top 10:2025، Security Misconfiguration با عنوان A02:2025 در رتبه دوم قرار گرفته است و نسبت به جایگاه پنجم در نسخه 2021 بالاتر آمده است.

رایج‌ترین Security Misconfiguration در WordPress چیست؟

یک مورد واحد برای همه سایت‌ها وجود ندارد، اما Debug فعال، Permission نامناسب، Backup Public، Pluginهای غیرضروری، HTTPS ناقص و دسترسی مدیریتی بیش از حد از موارد مهمی هستند که باید بررسی شوند.

آیا نبود Security Header به معنی هک شدن سایت است؟

خیر. نبود یک Header به‌تنهایی به معنی Compromise شدن سایت نیست. Security Headerها بخشی از Defense in Depth هستند و اهمیت هر Header به معماری و رفتار سایت بستگی دارد.

آیا CORS با مقدار Wildcard همیشه ناامن است؟

خیر. روی Resource کاملاً Public ممکن است Wildcard کاملاً منطقی باشد. مشکل زمانی ایجاد می‌شود که Policy بیش از نیاز واقعی باز باشد یا Resource حساس بدون تحلیل صحیح Cross-Origin در دسترس قرار گیرد.

بهترین راه جلوگیری از Security Misconfiguration چیست؟

استفاده از Security Baseline، Hardening تکرارپذیر، Least Privilege، جداسازی Environmentها، Configuration Review، Automation، Monitoring و مدیریت تغییرات از مؤثرترین روش‌ها هستند.

جمع‌بندی؛ برای جلوگیری از Security Misconfiguration چه کنیم؟

Security Misconfiguration نشان می‌دهد برای ناامن شدن یک سایت همیشه لازم نیست مهاجم یک Zero-Day یا آسیب‌پذیری پیچیده پیدا کند.

گاهی یک Debug Mode فعال، Backup فراموش‌شده، Permission اشتباه، CORS بیش از حد باز یا Service غیرضروری می‌تواند سطح حمله را به شکل قابل‌توجهی افزایش دهد.

مشکل اصلی Security Misconfiguration این است که در تمام لایه‌های سیستم ممکن است رخ دهد:

Application، WordPress، Server، Database، Cloud، API، CDN و حتی Browser Security Policy.

به همین دلیل دفاع مؤثر نیازمند یک فرآیند منظم است، نه چند تنظیم پراکنده.

مدیران سایت و توسعه‌دهندگان باید برای سیستم‌های خود یک Security Baseline مشخص داشته باشند و Configurationها را به‌صورت دوره‌ای با آن مقایسه کنند.

اصول کلیدی عبارت‌اند از:

حداقل‌سازی سطح حمله، حذف قابلیت‌های غیرضروری، Least Privilege، جداسازی Environmentها، خاموش کردن Debug در Production، محافظت از Secretها، HTTPS سراسری، تنظیم صحیح Security Headerها، محدودکردن CORS، محافظت از Backup و Logging و Monitoring مداوم Configuration.

همچنین نباید تصور کرد Configuration یک‌بار انجام می‌شود و برای همیشه امن باقی می‌ماند.

Server تغییر می‌کند.

Plugin نصب می‌شود.

Developer تنظیمی را موقتاً تغییر می‌دهد.

Infrastructure گسترش پیدا می‌کند.

Feature جدید اضافه می‌شود.

به همین دلیل Configuration Drift باید بخشی از فرآیند امنیتی سازمان در نظر گرفته شود.

NIST نیز Security-Focused Configuration Management را یک فرآیند مستمر برای مدیریت و پایش Configuration سیستم‌ها با هدف کاهش Risk می‌داند.

در نهایت یک قاعده ساده وجود دارد:

تنظیمی که برای کارکرد سیستم لازم نیست، نباید بدون دلیل فعال باشد؛ و دسترسی‌ای که یک Component به آن نیاز ندارد، نباید به آن داده شود.

همین اصل ساده، اگر به شکل منظم در تمام Stack اجرا شود، می‌تواند تعداد زیادی از Security Misconfigurationهای رایج را پیش از تبدیل شدن به Incident حذف کند.