هدرهای امنیتی HTTP: راهنمای جامع

چرا هدرهای امنیتی HTTP برای وب‌سایت شما حیاتی هستند؟

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

بدون پیکربندی صحیح این هدرها، وب‌سایت شما می‌تواند به راحتی مورد هدف حملاتی نظیر **Cross-Site Scripting (XSS)**، **Clickjacking**، **Man-in-the-Middle (MitM)** و حملات افشای اطلاعات قرار گیرد. پیاده‌سازی موثر این لایه‌های دفاعی نه تنها تجربه کاربری ایمن‌تری را فراهم می‌کند و **اعتماد کاربران** را جلب می‌نماید، بلکه به طور مستقیم بر **رتبه SEO** و جایگاه وب‌سایت شما در نتایج موتورهای جستجو تأثیر مثبت می‌گذارد. موتورهای جستجو، وب‌سایت‌های امن را در اولویت قرار می‌دهند.

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

در ادامه، به بررسی دقیق هر یک از این هدرهای امنیتی مهم، کاربرد آن‌ها در جلوگیری از حملات خاص و نحوه پیکربندی آن‌ها برای پرکاربردترین سرورهای وب یعنی **Apache** و **Nginx** می‌پردازیم.

Strict-Transport-Security (HSTS)

خوب

این هدر به مرورگر وب کاربر دستور می‌دهد که وب‌سایت شما را تنها از طریق **اتصالات رمزگذاری شده HTTPS** بارگذاری کند و هرگز از HTTP استفاده نکند. این عمل از چندین نوع حمله جلوگیری می‌کند:

پارامتر `max-age` مدت زمانی (به ثانیه) را تعیین می‌کند که مرورگر باید این سیاست را به خاطر بسپارد. `includeSubDomains` این سیاست را به تمامی زیردامنه‌ها نیز گسترش می‌دهد. `preload` نیز به مرورگرها اجازه می‌دهد قبل از اولین بازدید، وب‌سایت شما را به لیست preload HSTS اضافه کنند، که بالاترین سطح محافظت را فراهم می‌آورد.

نمونه کد در Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

نمونه کد در Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
بیشتر بدانید

X-Frame-Options

خوب

این هدر برای کنترل اینکه آیا صفحه وب شما می‌تواند در یک `iframe`, `frame` یا `object` (تگ‌هایی که برای جاسازی محتوا استفاده می‌شوند) بارگذاری شود، به کار می‌رود. هدف اصلی آن **جلوگیری از حملات Clickjacking** است. در یک حمله Clickjacking، مهاجم یک صفحه مخرب را روی صفحه قانونی شما قرار می‌دهد و کاربر را فریب می‌دهد تا روی یک عنصر ظاهراً بی‌ضرر در صفحه مخرب کلیک کند، در حالی که در واقع روی یک عنصر حساس در صفحه شما کلیک می‌کند.

مقادیر رایج:

استفاده از `SAMEORIGIN` یا `DENY` برای اکثر وب‌سایت‌ها توصیه می‌شود.

نمونه کد در Apache:

Header always set X-Frame-Options "SAMEORIGIN"

نمونه کد در Nginx:

add_header X-Frame-Options "SAMEORIGIN";
بیشتر بدانید

X-Content-Type-Options

خوب

این هدر از قابلیت **MIME Sniffing** (تغییر نوع محتوا) مرورگر جلوگیری می‌کند. مرورگرها معمولاً سعی می‌کنند نوع واقعی یک فایل را حدس بزنند، حتی اگر سرور یک نوع MIME خاص را ارسال کرده باشد. این می‌تواند منجر به مشکلات امنیتی شود، برای مثال، اگر مهاجم یک فایل مخرب را با پسوند `jpg` آپلود کند، اما محتوای آن یک اسکریپت قابل اجرا باشد، مرورگر ممکن است آن را به عنوان یک اسکریپت اجرا کند.

مقدار `nosniff` به مرورگر دستور می‌دهد که هرگز نوع MIME محتوای دریافتی را تغییر ندهد و همیشه از نوع MIME مشخص شده توسط سرور استفاده کند. این هدر یک لایه محافظتی مهم در برابر حملات تزریق اسکریپت (Injection Attacks) و اجرای کدهای ناخواسته فراهم می‌آورد.

نمونه کد در Apache:

Header always set X-Content-Type-Options "nosniff"

نمونه کد در Nginx:

add_header X-Content-Type-Options "nosniff";
بیشتر بدانید

Content-Security-Policy (CSP)

خوب

**CSP** یکی از قدرتمندترین و پیچیده‌ترین هدرهای امنیتی است که به شما امکان می‌دهد تا تمام منابعی (مانند اسکریپت‌ها، استایل‌ها، تصاویر، فونت‌ها و...) که یک صفحه وب می‌تواند از آن‌ها بارگذاری کند را با جزئیات دقیق کنترل کنید. هدف اصلی آن **جلوگیری از حملات Cross-Site Scripting (XSS)** و حملات تزریق داده (Data Injection) است. با تعریف یک لیست سفید از منابع قابل اعتماد، CSP می‌تواند به طور موثری اجرای کدهای مخرب را بلاک کند.

پیکربندی CSP نیازمند دانش دقیق از تمامی منابع داخلی و خارجی است که وب‌سایت شما استفاده می‌کند. استفاده از آن در حالت `report-only` در ابتدا توصیه می‌شود تا گزارش نقض‌ها را بدون بلاک کردن محتوا دریافت کنید و سپس پس از اطمینان از صحت پیکربندی، آن را به حالت `enforce` تغییر دهید.

مثال بالا یک سیاست پایه را نشان می‌دهد: `default-src 'self'` به این معنی است که تمامی منابع باید از همان دامنه (خود سایت) بارگذاری شوند. `script-src 'self' https://trusted-scripts.com` فقط اسکریپت‌ها را از دامنه خودی و `trusted-scripts.com` مجاز می‌داند. `object-src 'none'` بارگذاری پلاگین‌هایی مانند Flash را کاملاً ممنوع می‌کند.

نمونه کد در Apache:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-scripts.com; object-src 'none'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"

نمونه کد در Nginx:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-scripts.com; object-src 'none'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;" always;
بیشتر بدانید

Referrer-Policy

خوب

این هدر مشخص می‌کند که چه مقدار اطلاعات از آدرس ارجاع‌دهنده (URL صفحه قبلی که کاربر از آن به صفحه فعلی آمده است) باید در درخواست‌های HTTP ارسال شود. این هدر نقش مهمی در **حفظ حریم خصوصی کاربران** دارد و از افشای اطلاعات حساس (مانند توکن‌های سشن، شناسه‌های کاربری یا سایر داده‌های حساس در URL) جلوگیری می‌کند. تنظیمات نادرست می‌توانند منجر به نشت اطلاعات شوند.

مقدار `strict-origin-when-cross-origin` به عنوان یک گزینه متعادل و امن توصیه می‌شود: این مقدار تمام مسیر (path) را برای درخواست‌های هم‌مبدا ارسال می‌کند و تنها مبدأ (origin) را برای درخواست‌های cross-origin ارسال می‌کند و در صورت استفاده از HTTP به HTTPS، هیچ چیزی ارسال نمی‌کند.

نمونه کد در Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

نمونه کد در Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin";
بیشتر بدانید

Permissions-Policy (جایگزین Feature-Policy)

جدید

این هدر (که قبلاً با نام **Feature-Policy** شناخته می‌شد) به شما کنترل دقیقی بر روی مجوزهای استفاده از ویژگی‌های خاص مرورگر برای صفحه خود می‌دهد. این ویژگی‌ها می‌توانند شامل دسترسی به **دوربین، میکروفون، موقعیت جغرافیایی، قابلیت تمام صفحه (fullscreen)** و بسیاری موارد دیگر باشند. با تعریف صریح این سیاست‌ها، می‌توانید از سوءاستفاده توسط اسکریپت‌های مخرب یا تبلیغات ناخواسته که سعی در دسترسی به این قابلیت‌ها دارند، جلوگیری کنید.

به عنوان مثال، `geolocation=(self)` به این معنی است که فقط کد از همان دامنه می‌تواند به موقعیت جغرافیایی دسترسی داشته باشد، در حالی که `microphone=()` و `camera=()` دسترسی به میکروفون و دوربین را به طور کامل مسدود می‌کنند.

نمونه کد در Apache:

Header always set Permissions-Policy "geolocation=(self), microphone=(), camera=()"

نمونه کد در Nginx:

add_header Permissions-Policy "geolocation=(self), microphone=(), camera=()";
بیشتر بدانید

X-XSS-Protection

منسوخ

این هدر برای فعال‌سازی فیلتر XSS داخلی مرورگرهای قدیمی (مانند Internet Explorer و Safari) طراحی شده بود. هدف آن جلوگیری از حملات **Cross-Site Scripting (XSS)** بود. با این حال، مرورگرهای مدرن قابلیت‌های داخلی و پیشرفته‌تری برای مقابله با XSS دارند و استفاده از آن می‌تواند منجر به مشکلات امنیتی جدیدی (مانند دور زدن فیلترها و یا بلاک کردن محتوای مشروع) شود.

به دلیل این محدودیت‌ها و ظهور راه‌حل‌های جامع‌تر مانند **Content-Security-Policy (CSP)**، این هدر اکنون **منسوخ شده** و **توصیه نمی‌شود**. بهتر است تمرکز خود را بر پیاده‌سازی صحیح CSP برای محافظت در برابر XSS قرار دهید.

نمونه کد در Apache:

Header always set X-XSS-Protection "1; mode=block"

نمونه کد در Nginx:

add_header X-XSS-Protection "1; mode=block";
بیشتر بدانید

Expect-CT

خوب

این هدر به مرورگرها امکان می‌دهد تا از شفافیت گواهی (**Certificate Transparency - CT**) برای شناسایی گواهی‌نامه‌های SSL/TLS نامعتبر یا نادرست صادر شده برای دامنه شما استفاده کنند. **شفافیت گواهی** یک سیستم عمومی است که تمامی گواهی‌نامه‌های صادر شده را ثبت می‌کند و امکان بررسی آن‌ها را فراهم می‌سازد. این هدر به طور خاص به جلوگیری از حملات **Man-in-the-Middle (MitM)** که از گواهی‌نامه‌های جعلی یا نامشروع استفاده می‌کنند، کمک می‌کند.

پارامتر `report-uri` به شما اجازه می‌دهد تا گزارش‌های مربوط به نقض شفافیت گواهی را به یک endpoint مشخص ارسال کنید تا بتوانید سریعاً از مشکلات احتمالی مطلع شوید و واکنش نشان دهید. پارامتر `enforce` نیز مرورگر را وادار می‌کند تا اتصال را در صورت عدم رعایت الزامات CT بلاک کند.

نمونه کد در Apache:

Header always set Expect-CT "max-age=86400, enforce, report-uri='https://your-domain.com/report-ct'"

نمونه کد در Nginx:

add_header Expect-CT "max-age=86400, enforce, report-uri='https://your-domain.com/report-ct'" always;
بیشتر بدانید

NEL (Network Error Logging)

جدید

این هدر به شما اجازه می‌دهد تا **گزارش خطاهای شبکه** را که کاربران در هنگام دسترسی به وب‌سایت شما تجربه می‌کنند (مانند مشکلات اتصال، خطاهای DNS، خطاهای TLS، یا قطعی سرور) جمع‌آوری کنید. این اطلاعات برای **عیب‌یابی فعال و بهبود عملکرد و دسترسی وب‌سایت** بسیار ارزشمند هستند. با جمع‌آوری این داده‌ها، می‌توانید مشکلات پنهان زیرساختی را شناسایی و قبل از آنکه بر تعداد زیادی از کاربران تأثیر بگذارند، آن‌ها را رفع کنید.

این هدر با هدر `Report-To` همکاری می‌کند تا گزارش‌ها به یک endpoint مشخص ارسال شوند. پارامتر `max_age` مدت زمانی است که مرورگر باید این سیاست را به خاطر بسپارد و `include_subdomains` نیز آن را به زیردامنه‌ها گسترش می‌دهد.

نمونه کد در Apache:

Header always set NEL "{ \"report_to\": \"default\", \"max_age\": 2592000, \"include_subdomains\": true }"

نمونه کد در Nginx:

add_header NEL "{ \"report_to\": \"default\", \"max_age\": 2592000, \"include_subdomains\": true }" always;
بیشتر بدانید

Report-To

جدید

این هدر یک **مکانیسم واحد و استاندارد** برای جمع‌آوری انواع مختلف **گزارش‌های مرورگر** فراهم می‌کند. این گزارش‌ها می‌توانند شامل نقض‌های **Content-Security-Policy (CSP)**، خطاهای شبکه از طریق **NEL (Network Error Logging)**، خطاهای Credential Management API و سایر مشکلات امنیتی یا عملکردی باشند. با تعریف یک گروه (group) و یک یا چند Endpoint URL، می‌توانید تمامی این گزارش‌ها را به یک سرور مرکزی برای تحلیل ارسال کنید.

این هدر به شما امکان می‌دهد تا به صورت فعال بر سلامت و امنیت وب‌سایت خود نظارت داشته باشید و به سرعت به هرگونه رویداد ناخواسته یا حمله واکنش نشان دهید. این یک جزء کلیدی برای **مشاهده‌پذیری (Observability)** و **واکنش به حوادث (Incident Response)** در محیط وب است.

نمونه کد در Apache:

Header always set Report-To "{ \"group\": \"default\", \"max_age\": 2592000, \"endpoints\": [ { \"url\": \"https://your-domain.com/report\" } ] }"

نمونه کد در Nginx:

add_header Report-To "{ \"group\": \"default\", \"max_age\": 2592000, \"endpoints\": [ { \"url\": \"https://your-domain.com/report\" } ] }" always;
بیشتر بدانید

Feature-Policy (منسوخ شده)

منسوخ

این هدر، همانطور که قبلاً ذکر شد، با هدر **Permissions-Policy** جایگزین شده است. Feature-Policy به توسعه‌دهندگان اجازه می‌داد تا رفتار خاصی از APIهای مرورگر و ویژگی‌های وب را فعال یا غیرفعال کنند، مانند جلوگیری از استفاده از دوربین، میکروفون، یا geolocation در یک صفحه وب یا iframe. دلیل منسوخ شدن آن، تغییر نام و گسترش قابلیت‌ها به Permissions-Policy است که رویکردی جامع‌تر و کنترل‌کننده‌تر را ارائه می‌دهد. اگرچه هنوز ممکن است در برخی مرورگرهای قدیمی‌تر کار کند، اما برای مطابقت با استانداردهای فعلی و امنیت بهینه، **استفاده از Permissions-Policy اکیداً توصیه می‌شود.**

نمونه کد در Apache:

Header always set Feature-Policy "geolocation 'none'; camera 'none'"

نمونه کد در Nginx:

add_header Feature-Policy "geolocation 'none'; camera 'none'";
بیشتر بدانید