Security Headers در وردپرس چطور سایت را نجات می‌دهند؟

Security Headers در وردپرس مجموعه‌ای از هدرهای HTTP هستند که با تنظیم سیاست‌های امنیتی در سطح مرورگر، سایت را از حملات رایج مثل XSS، Clickjacking، MIME Sniffing، SSL Stripping و Data Injection نجات می‌دهند. این هدرها شامل Content-Security-Policy (CSP)، X-Frame-Options، Strict-Transport-Security (HSTS)، X-Content-Type-Options، Referrer-Policy، Permissions-Policy و Cross-Origin-* هستند. هر هدر یک لایه دفاعی مستقل فراهم می‌کند و ترکیب آن‌ها، یک معماری امنیتی چندلایه می‌سازد که حتی اگر یک لایه شکسته شود، لایه‌های دیگر از سایت محافظت می‌کنند. برخلاف فایروال یا افزونه امنیتی که روی سرور اجرا می‌شوند، Security Headers در مرورگر کاربر اجرا می‌شوند و به همین دلیل، بار سرور را افزایش نمی‌دهند و در برابر حملات سمت کلاینت مؤثرترند. این مقاله چارچوب کامل پیاده‌سازی Security Headers در وردپرس، از هر هدر تا استراتژی ترکیبی، را ارائه می‌دهد.

در یک پروژه، سایت وردپرسی بعد از یک هک، تحلیل امنیتی نشان داد که مهاجم از طریق XSS Session کاربران را سرقت کرده بود. بعد از پیاده‌سازی CSP، X-Frame-Options و Referrer-Policy، همان حمله خنثی شد. این تجربه، اهمیت Security Headers را در یک کلمه خلاصه می‌کند: پیشگیری.

Security Headers چیست و چرا حیاتی است؟

Security Headers (هدرهای امنیتی) مجموعه‌ای از هدرهای HTTP هستند که به مرورگر می‌گویند چگونه با محتوای سایت رفتار کند. این هدرها در پاسخ سرور به مرورگر ارسال می‌شوند و سیاست‌های امنیتی را تعریف می‌کنند. اگر با List of HTTP Header Fields آشنا شده باشید، می‌دانید که Security Headers بخشی از این فیلدها هستند.

حیاتی بودن Security Headers از چند جهت قابل تحلیل است. اول، دفاع در عمق: هر هدر یک لایه دفاعی مستقل است و ترکیب آن‌ها، امنیت چندلایه می‌سازد. دوم، اجرا در مرورگر: برخلاف فایروال که روی سرور اجرا می‌شود، Security Headers در مرورگر کاربر اجرا می‌شوند و بار سرور را افزایش نمی‌دهند. سوم، پوشش حملات سمت کلاینت: Security Headers در برابر حملاتی که در سمت کلاینت اجرا می‌شوند (مثل XSS و Clickjacking) مؤثرترند. چهارم، انطباق با استانداردها: بسیاری از استانداردهای امنیتی، Security Headers را الزامی می‌دانند. پنجم، بهبود SEO: گوگل امنیت را به‌عنوان سیگنال رتبه‌بندی استفاده می‌کند.

«Security Headers یک قرارداد است بین سایت و مرورگر: اگر سایت بگوید چه چیزی مجاز است، مرورگر آن را اجرا می‌کند.»

اگر با استانداردهای امنیت وب آشنا شده باشید، می‌دانید که Security Headers بخشی از این استانداردهاست. اگر با هدرهای امنیتی HTTP و کاربرد آن‌ها آشنا شده باشید، این مقاله جزئیات بیشتری ارائه می‌دهد.

هدر	محافظت از	سطح اهمیت
Content-Security-Policy	XSS، Data Injection	بسیار بالا
X-Frame-Options	Clickjacking	بالا
Strict-Transport-Security	SSL Stripping، MITM	بسیار بالا
X-Content-Type-Options	MIME Sniffing	متوسط
Referrer-Policy	Information Leakage	متوسط
Permissions-Policy	Access to Device Features	متوسط
COOP، COEP، CORP	Side-Channel Attacks	بالا

لیست کامل Security Headers

Security Headers در وردپرس شامل هشت هدر اصلی است که هرکدام یک جنبه از امنیت را پوشش می‌دهد:

Content-Security-Policy (CSP): کنترل منابع مجاز بارگذاری
X-Frame-Options: کنترل iframeها
Strict-Transport-Security (HSTS): اجبار HTTPS
X-Content-Type-Options: جلوگیری از MIME Sniffing
Referrer-Policy: کنترل اطلاعات Referrer
Permissions-Policy: کنترل قابلیت‌های مرورگر
Cross-Origin-Opener-Policy (COOP): ایزوله‌سازی Window
Cross-Origin-Embedder-Policy (COEP): ایزوله‌سازی Embedding
Cross-Origin-Resource-Policy (CORP): کنترل دسترسی به منابع

Content-Security-Policy (CSP)

CSP یکی از قوی‌ترین Security Headers است که منابع مجاز بارگذاری را تعریف می‌کند. اگر با Content Security Policy در وردپرس و پیچیدگی‌های آن آشنا شده باشید، می‌دانید که CSP در وردپرس نیازمند مدیریت Nonce و Hash است.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-abc123'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; frame-ancestors 'self'

X-Frame-Options

X-Frame-Options از سایت در برابر Clickjacking محافظت می‌کند. اگر با X-Frame-Options در وردپرس و اهمیت آن آشنا شده باشید، می‌دانید که این هدر سه مقدار دارد: DENY، SAMEORIGIN و ALLOW-FROM (منسوخ).

X-Frame-Options: SAMEORIGIN

Strict-Transport-Security (HSTS)

HSTS از سایت در برابر SSL Stripping و MITM محافظت می‌کند. اگر با HSTS در وردپرس و نحوه راه‌اندازی آن آشنا شده باشید، می‌دانید که HSTS سه پارامتر دارد: max-age، includeSubDomains و preload.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

X-Content-Type-Options

X-Content-Type-Options از سایت در برابر MIME Sniffing محافظت می‌کند. MIME Sniffing یک آسیب‌پذیری است که در آن، مرورگر نوع فایل را بر پایه محتوا تشخیص می‌دهد، نه بر پایه هدر Content-Type. این می‌تواند منجر به اجرای فایل‌های مخرب شود.

X-Content-Type-Options: nosniff

مقدار nosniff تنها مقدار معتبر است و مرورگر را از MIME Sniffing منع می‌کند.

Referrer-Policy

Referrer-Policy کنترل می‌کند که چه اطلاعاتی در هدر Referrer ارسال شود. این هدر، از نشت اطلاعات حساس (مثل URLهای داخلی) به سایت‌های خارجی جلوگیری می‌کند.

Referrer-Policy: strict-origin-when-cross-origin

مقادیر رایج Referrer-Policy:

مقدار	توضیح
`no-referrer`	هیچ Referrer ارسال نمی‌شود
`same-origin`	Referrer فقط برای Same-Origin
`strict-origin`	فقط Origin (بدون Path)
`strict-origin-when-cross-origin`	Origin برای Cross-Origin
`no-referrer-when-downgrade`	Referrer به‌جز در HTTPS به HTTP

Permissions-Policy

Permissions-Policy کنترل دسترسی به قابلیت‌های مرورگر را فراهم می‌کند. اگر با Permissions-Policy در وردپرس آشنا شده باشید، می‌دانید که این هدر جایگزین Feature-Policy شده است.

Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(self)

Cross-Origin Headers (COOP, COEP, CORP)

این سه هدر، امنیت Cross-Origin را تقویت می‌کنند. اگر با COOP، COEP و CORP در وردپرس آشنا شده باشید، می‌دانید که این هدرها برای Cross-Origin Isolation ضروری هستند.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

پیاده‌سازی در وردپرس

پیاده‌سازی Security Headers در وردپرس در چند گام انجام می‌شود:

گام اول: افزودن هدرها با header() در PHP.

add_action( 'send_headers', function() {
    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'Permissions-Policy: geolocation=(), camera=(), microphone=()' );
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
} );

گام دوم: افزودن هدرها با Nginx.

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

گام سوم: افزودن هدرها با Apache.

<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

گام چهارم: تست. از ابزارهایی مثل securityheaders.com برای بررسی هدرها استفاده کنید.

تست و پایش

تست Security Headers در چند سطح انجام می‌شود:

سطح اول: Security Headers. ابزار securityheaders.com یک نمره از A تا F می‌دهد و پیشنهادهای اصلاحی ارائه می‌کند.

سطح دوم: Mozilla Observatory. ابزار observatory.mozilla.org تحلیل عمیق‌تری ارائه می‌دهد.

سطح سوم: Chrome DevTools. در Network → Headers، تمام هدرها را بررسی کنید.

سطح چهارم: Lighthouse. Lighthouse یک Audit امنیتی دارد که هدرها را بررسی می‌کند.

اگر با تست امنیت وب‌سایت آشنا شده باشید، این ابزارها برای شما آشناست.

اشتباهات رایج

اشتباه اول: فعال‌سازی CSP بدون Report-Only. CSP می‌تواند سایت را از کار بیندازد. راه‌حل: شروع با Report-Only.

اشتباه دوم: تنظیم HSTS بدون SSL. اگر SSL نباشد، HSTS سایت را از کار می‌اندازد. راه‌حل: اول SSL را تست کنید.

اشتباه سوم: مسدود کردن iframeهای داخلی با X-Frame-Options DENY. راه‌حل: SAMEORIGIN.

اشتباه چهارم: Whitelist کردن unsafe-inline به‌صورت دائمی. راه‌حل: Nonce یا Hash.

اشتباه پنجم: فراموش کردن Pages Admin. توصیه می‌شود Security Headers برای Pages Admin تنظیم نشوند.

اشتباه ششم: عدم پایش مستمر. Security Headers نیازمند پایش مستمر هستند چون افزونه‌های جدید می‌توانند تخلف ایجاد کنند.

اشتباه هفتم: Whitelist کردن دامنه‌های عمومی. اگر https: را Whitelist کنید، امنیت CSP کاهش می‌یابد.

پرسش‌های پرتکرار

Security Headers چیست و چرا حیاتی است؟

Security Headers مجموعه‌ای از هدرهای HTTP هستند که سیاست‌های امنیتی را در مرورگر تعریف می‌کنند. حیاتی است چون از حملات XSS، Clickjacking، SSL Stripping و MIME Sniffing جلوگیری می‌کند و بار سرور را افزایش نمی‌دهد.

چگونه Security Headers را در وردپرس پیاده‌سازی کنم؟

از Hook send_headers و تابع header() استفاده کنید یا از Nginx/Apache. مثال: X-Frame-Options: SAMEORIGIN.

چند Security Headers وجود دارد؟

هشت هدر اصلی: CSP، X-Frame-Options، HSTS، X-Content-Type-Options، Referrer-Policy، Permissions-Policy، COOP، COEP و CORP.

آیا Security Headers بر سرعت سایت تأثیر می‌گذارد؟

خیر، تأثیر منفی ندارد. Security Headers فقط سیاست‌های امنیتی هستند که در مرورگر اعمال می‌شوند.

آیا Security Headers با ویرایشگر گوتنبرگ سازگار است؟

بیشتر هدرها سازگارند، اما CSP نیازمند Whitelist کردن iframe و REST API است. توصیه می‌شود هدرها را برای صفحات Admin تنظیم نکنید.

کدام Security Headers برای وردپرس حیاتی است؟

پنج هدر حیاتی: CSP، X-Frame-Options، HSTS، X-Content-Type-Options و Referrer-Policy. سایر هدرها توصیه می‌شوند.

آیا Security Headers جایگزین فایروال است؟

خیر، مکمل هستند. Security Headers در مرورگر اجرا می‌شوند و فایروال روی سرور. برای امنیت کامل، باید هر دو را ترکیب کنید.

چگونه Security Headers را تست کنم؟

از Security Headers، Mozilla Observatory، Chrome DevTools و Lighthouse استفاده کنید. این ابزارها نمره و پیشنهادهای اصلاحی ارائه می‌دهند.

آیا Security Headers بر SEO تأثیر می‌گذارد؟

تأثیر مستقیمی دارد چون گوگل امنیت را به‌عنوان سیگنال رتبه‌بندی استفاده می‌کند.

آیا Security Headers برای همه سایت‌ها ضروری است؟

بله، برای همه سایت‌ها توصیه می‌شود. حتی سایت‌های ساده می‌توانند هدف حملات خودکار باشند.

تحلیل معمارانه سطح ارشد

از منظر معماری نرم‌افزار، Security Headers یک نمونه از Browser-Level Security Enforcement است: به‌جای اعتماد به کد اپلیکیشن، مرورگر سیاست‌های امنیتی را اجرا می‌کند. این رویکرد، در معماری‌های مدرن به یک اصل تبدیل شده: از Defense in Depth تا Zero-Trust.

چالش اصلی، Backward Compatibility است: بعضی هدرها در مرورگرهای قدیمی پشتیبانی نمی‌شوند. راه‌حل، ترکیب هدرها با سایر لایه‌های امنیتی.

چالش دوم، Ecosystem Compatibility است: هر افزونه جدید می‌تواند هدرها را بشکند. راه‌حل، پایش مستمر و تنظیم.

چالش سوم، Trade-off بین امنیت و قابلیت است: هدرهای سخت‌گیرانه، امنیت بالاتر اما قابلیت کمتر. راه‌حل، تنظیم دقیق بر پایه نیازها.

چالش چهارم، Observability است: اگر هدری منبعی را مسدود کند، چگونه می‌توان فهمید؟ راه‌حل، استفاده از Reporting API و RUM.

در نهایت، Security Headers یک Evolution است، نه یک Revolution. این هدرها، تکامل طبیعی معماری امنیتی وب هستند: از کنترل متمرکز به کنترل توزیع‌شده، از اعتماد کامل به کد به تأیید هر منبع. تیم‌هایی که این رویکرد را در فرهنگ خود نهادینه می‌کنند، سیستم‌هایی می‌سازند که در برابر طیف گسترده‌ای از حملات مقاوم هستند. اگر با طراحی معماری وب مقیاس‌پذیر آشنا شده باشید، این رویکرد را به‌عنوان یک اصل مهندسی می‌شناسید.

اگر این تجربه را در یک پروژه واقعی داشته‌اید، جالب است بدانید کدام Security Header بیشترین تأثیر را در افزایش امنیت داشت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🛡️