ESC را فشار دهید تا بسته شود

هدرهای امنیتی HTTP چیست؟ آموزش تنظیم روی NGINX و Apache

هدرهای امنیتی HTTP چیست؟ آموزش تنظیم روی NGINX و Apache

فهرست

هدرهای امنیتی HTTP دستورهایی هستند که وب‌سرور همراه پاسخ HTTP برای مرورگر می‌فرستد تا رفتارهای پرریسک را محدود کند. اگر سرور NGINX یا Apache دارید، چند هدر درست می‌تواند سطح حمله‌هایی مثل XSS، MIME sniffing، clickjacking و نشت Referrer را کاهش دهد؛ اما هدر اشتباه—به‌خصوص CSP و HSTS—ممکن است بخشی از سایت را از کار بیندازد. بنابراین تنظیم را مرحله‌ای و همراه تست انجام دهید.

هدرهای امنیتی HTTP چیست؟ آموزش تنظیم روی NGINX و Apache

هدر امنیتی HTTP دقیقاً چه کاری انجام می‌دهد؟

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

کدام هدرها برای بیشتر سایت‌ها مهم‌اند؟

Content-Security-Policy (CSP)

CSP مشخص می‌کند اسکریپت، استایل، تصویر، فونت و سایر منابع از چه مبداهایی بارگذاری شوند. این هدر در کاهش اثر XSS بسیار مهم است، اما نباید یک Policy عمومی را بدون بررسی روی همه سایت‌ها کپی کرد.

Content-Security-Policy: default-src 'self'; img-src 'self' https: data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self';

برای شروع، می‌توانید ابتدا از Content-Security-Policy-Report-Only استفاده کنید تا ناسازگاری‌ها را قبل از Enforce شدن پیدا کنید.

Strict-Transport-Security (HSTS)

HSTS به مرورگر می‌گوید دامنه را فقط از HTTPS باز کند. آن را فقط وقتی فعال کنید که HTTPS روی دامنه و زیر‌دامنه‌های موردنظر پایدار است.

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

گزینه preload تعهد جدی‌تری ایجاد می‌کند و بدون بررسی شرایط Preload نباید صرفاً برای گرفتن امتیاز ابزارهای تست اضافه شود. همچنین HSTS را فقط روی پاسخ HTTPS ارسال کنید؛ قرار دادن آن روی VirtualHost یا Server Block مربوط به HTTP کاربردی ندارد.

برای جزئیات بیشتر درباره زمان مناسب استفاده از includeSubDomains و preload، راهنمای HSTS چیست و چگونه امنیت وب‌سایت را افزایش می‌دهد را هم ببینید.

X-Content-Type-Options

مقدار nosniff مانع می‌شود مرورگر نوع بعضی محتواها را برخلاف Content-Type اعلام‌شده حدس بزند.

X-Content-Type-Options: nosniff

Referrer-Policy

این هدر مقدار اطلاعات URL که هنگام رفتن کاربر به مقصد دیگر ارسال می‌شود را کنترل می‌کند. برای بسیاری از سایت‌ها strict-origin-when-cross-origin نقطه شروع مناسبی است.

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

Permissions-Policy

با Permissions-Policy می‌توان دسترسی صفحه به قابلیت‌هایی مثل دوربین، میکروفون و موقعیت مکانی را محدود کرد. Policy باید بر اساس نیاز واقعی سایت نوشته شود.

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

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

در NGINX معمولاً هدرها با دستور add_header در بلاک مناسب Server یا Location اضافه می‌شوند. نمونه زیر یک نقطه شروع است و CSP آن باید با منابع واقعی سایت تطبیق داده شود:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

بعد از تغییر، ابتدا صحت کانفیگ را بررسی و سپس Reload کنید:

sudo nginx -t
sudo systemctl reload nginx

نکته مهم NGINX: دستورهای add_header می‌توانند در سطوح server و location رفتار ارث‌بری متفاوتی داشته باشند؛ اگر در یک Location هدر جدیدی تعریف کنید، هدرهای سطح بالاتر ممکن است مطابق نسخه و ساختار کانفیگ به شکل مورد انتظار به آن Location نرسند. بعد از هر تغییر، Response Headers همان مسیرهای واقعی را جداگانه تست کنید.

اگر NGINX را روی یک سرور مجازی مناسب برای میزبانی وب و سرویس‌های لینوکسی مدیریت می‌کنید، قبل از اعمال CSP سخت‌گیرانه از کانفیگ فعلی نسخه پشتیبان داشته باشید. برای آشنایی بیشتر با قابلیت‌های جدید این وب‌سرور نیز مقاله NGINX 1.30 و HTTP 103 Early Hints را ببینید.

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

در Apache با فعال بودن mod_headers می‌توانید هدرها را در VirtualHost یا در شرایط مناسب در .htaccess تنظیم کنید:

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"

در Debian/Ubuntu در صورت نیاز:

sudo a2enmod headers
sudo apachectl configtest
sudo systemctl reload apache2

برای HSTS در Apache: این هدر را داخل VirtualHost مربوط به HTTPS (معمولاً پورت 443) قرار دهید و قبل از استفاده از includeSubDomains مطمئن شوید تمام زیردامنه‌های مشمول، HTTPS معتبر و پایدار دارند.

چرا CSP را نباید کورکورانه کپی کنیم؟

سایت‌های وردپرسی، فروشگاهی و اپلیکیشن‌های مدرن ممکن است اسکریپت پرداخت، CDN، فونت، آنالیتیکس، iframe یا API خارجی داشته باشند. CSP بیش‌ازحد محدود می‌تواند این منابع را مسدود کند. ابتدا Console مرورگر و گزارش‌های Report-Only را بررسی کنید و فقط مبداهای واقعاً لازم را مجاز کنید.

هدرهای قدیمی یا کم‌کاربرد را چه کنیم؟

هدف این نیست که تعداد هدرها را زیاد کنیم. برای مثال X-XSS-Protection دیگر کنترل امنیتی قابل اتکایی برای مرورگرهای مدرن نیست و نباید صرفاً برای کامل شدن یک چک‌لیست اضافه شود. برای مقابله با Clickjacking، دستور frame-ancestors در CSP کنترل مدرن‌تر و منعطف‌تری است؛ X-Frame-Options را می‌توان فقط در سناریوهایی که به سازگاری با کلاینت‌های قدیمی‌تر نیاز دارید به‌عنوان لایه تکمیلی در نظر گرفت. به‌جای کپی یک فهرست بلند، روی هدرهای پشتیبانی‌شده و Policy متناسب با اپلیکیشن تمرکز کنید و وضعیت روز را با مرجع OWASP بررسی کنید.

چطور هدرهای سایت را تست کنیم؟

از خط فرمان می‌توانید هدرهای پاسخ را بررسی کنید:

curl -I https://example.com
curl -s -D - -o /dev/null https://example.com

دستور دوم یک درخواست GET واقعی می‌فرستد و فقط Headerهای پاسخ را نمایش می‌دهد؛ این روش برای اپلیکیشن‌هایی که به درخواست HEAD متفاوت پاسخ می‌دهند مفیدتر است. در مرورگر نیز DevTools → Network → Response Headers را بررسی کنید. تست را روی صفحه اصلی، لاگین، پرداخت، API و مسیرهای مهم دیگر انجام دهید، چون CDN، Reverse Proxy یا خود اپلیکیشن ممکن است هدرها را تغییر دهد یا دوباره بنویسد.

ترتیب پیشنهادی برای اعمال امن

  1. HTTPS و Redirectها را بررسی کنید.
  2. X-Content-Type-Options و Referrer-Policy را اضافه کنید.
  3. Permissions-Policy را مطابق قابلیت‌های واقعی سایت محدود کنید.
  4. CSP را ابتدا در Report-Only تست کنید.
  5. پس از اطمینان از HTTPS، HSTS را فعال کنید.
  6. هدر نهایی را هم از مبدا و هم پشت CDN/Proxy تست کنید.

سؤالات متداول

آیا هدرهای امنیتی جلوی هک شدن سایت را می‌گیرند؟

به‌تنهایی خیر. آن‌ها یک لایه دفاعی مرورگر هستند و باید در کنار Patch، کنترل دسترسی، فایروال، بکاپ و کدنویسی امن استفاده شوند.

بهترین CSP برای وردپرس چیست؟

یک CSP واحد برای همه سایت‌های وردپرسی وجود ندارد. افزونه‌ها، CDN، درگاه پرداخت، فونت و سرویس‌های خارجی هر سایت متفاوت‌اند؛ CSP باید با مشاهده منابع واقعی ساخته و ابتدا Report-Only تست شود.

آیا HSTS را روی همه دامنه‌ها فعال کنیم؟

فقط وقتی HTTPS پایدار است و اثر includeSubDomains را روی همه زیردامنه‌ها می‌دانید. فعال‌سازی عجولانه HSTS می‌تواند دسترسی به زیردامنه‌ای که HTTPS صحیح ندارد را مختل کند.

هدرها را در CDN تنظیم کنیم یا وب‌سرور؟

هر دو ممکن است درست باشند، اما باید یک نقطه مرجع مشخص داشته باشید و پاسخ نهایی کاربر را تست کنید. CDN یا Reverse Proxy می‌تواند هدر مبدا را بازنویسی یا حذف کند.

منابع

5/5 - (2 امتیاز)
Post Views: 7
اشتراک گذاری نوشته در:

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *