هدرهای امنیتی سایت چیست؟ بررسی CSP، HSTS و مهم‌ترین Security Headerها

هدرهای امنیتی سایت یا HTTP Security Headers مجموعه‌ای از دستورالعمل‌های امنیتی هستند که سرور همراه پاسخ HTTP برای مرورگر ارسال می‌کند تا رفتار مرورگر در برابر تهدیدهایی مانند XSS، Clickjacking، نشت اطلاعات، بارگذاری منابع ناامن و سوءاستفاده از قابلیت‌های حساس محدود شود. از مهم‌ترین آن‌ها می‌توان به CSP، HSTS، X-Content-Type-Options، Referrer-Policy و Permissions-Policy اشاره کرد.

امنیت یک وب‌سایت فقط به نصب SSL، استفاده از افزونه امنیتی یا انتخاب رمز عبور قوی محدود نمی‌شود. بخش مهمی از امنیت در نقطه‌ای اتفاق می‌افتد که سرور و مرورگر درباره نحوه نمایش و اجرای محتوای صفحه با یکدیگر ارتباط برقرار می‌کنند. HTTP Security Headers دقیقاً در همین نقطه وارد عمل می‌شوند.

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

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

برای مثال Content-Security-Policy یا CSP مشخص می‌کند مرورگر اسکریپت، تصویر، فونت و سایر منابع صفحه را از چه مبداهایی بارگذاری کند. HSTS به مرورگر می‌گوید سایت باید فقط از طریق HTTPS در دسترس قرار گیرد. X-Content-Type-Options مانع از حدس زدن نوع فایل توسط مرورگر می‌شود و Referrer-Policy میزان اطلاعاتی را که هنگام مراجعه کاربر به سایت دیگر منتقل می‌شود محدود می‌کند.

با این حال، باید یک نکته مهم را از همان ابتدا روشن کرد: Security Headerها جایگزین برنامه‌نویسی امن، اعتبارسنجی ورودی‌ها، Encoding خروجی، WAF، مدیریت صحیح Session یا رفع آسیب‌پذیری‌های نرم‌افزاری نیستند. آن‌ها بخشی از معماری Defense in Depth یا «دفاع چندلایه» هستند.

OWASP نیز HTTP Security Response Headerها را به‌عنوان یکی از روش‌های مؤثر برای افزایش سطح امنیت وب معرفی می‌کند و به نقش آن‌ها در کاهش ریسک‌هایی مانند XSS، Clickjacking و Information Disclosure اشاره دارد.

در ادامه به‌صورت دقیق بررسی می‌کنیم هدرهای امنیتی سایت چیست، هر Security Header چه کاری انجام می‌دهد، CSP و HSTS چگونه کار می‌کنند، چه هدرهایی دیگر توصیه نمی‌شوند و چگونه می‌توان یک سیاست امنیتی منطقی برای سایت طراحی کرد.

هدر HTTP چیست و Security Header در کجای ارتباط قرار می‌گیرد؟

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

وقتی کاربر آدرس سایتی را باز می‌کند، مرورگر یک HTTP Request برای سرور ارسال می‌کند. سرور نیز پس از پردازش درخواست، یک HTTP Response برمی‌گرداند.

این پاسخ تنها شامل HTML صفحه نیست. بخشی از آن شامل Headerها است.

برای مثال پاسخ یک سرور ممکن است از نظر مفهومی شامل موارد زیر باشد:

HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Content-Security-Policy: ...
Strict-Transport-Security: ...
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

پس از این بخش، محتوای HTML قرار می‌گیرد.

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

بنابراین بسیاری از Security Headerها عملاً مجموعه‌ای از دستورها برای مرورگر هستند.

چرا هدرهای امنیتی سایت مهم هستند؟

فرض کنید وب‌سایتی دارای یک آسیب‌پذیری Cross-Site Scripting یا XSS باشد.

اگر هیچ محدودیتی برای اجرای JavaScript وجود نداشته باشد، کد تزریق‌شده ممکن است بتواند در Context صفحه اجرا شود.

حالا فرض کنید همان وب‌سایت یک Content Security Policy اصولی هم داشته باشد که اجرای اسکریپت تنها از منابع مشخص را مجاز بداند و از سازوکارهایی مانند nonce یا hash استفاده کند.

CSP لزوماً آسیب‌پذیری اصلی را برطرف نمی‌کند، اما می‌تواند مسیر سوءاستفاده را محدود کند.

به همین دلیل است که در امنیت مدرن وب، مفهوم Defense in Depth اهمیت زیادی دارد.

امنیت مطلوب معمولاً حاصل ترکیب چند کنترل است:

• کدنویسی امن
• Input Validation
• Output Encoding
• Sanitization
• احراز هویت مناسب
• مدیریت صحیح Session
• HTTPS
• WAF
• Security Headers
• مانیتورینگ و Logging
• به‌روزرسانی نرم‌افزارها
• مدیریت دسترسی

MDN نیز تأکید می‌کند که CSP تنها بخشی از راهبرد مقابله با XSS است و روش‌هایی مانند Sanitization و Output Encoding همچنان ضروری هستند.

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

هدرهایی که باید بررسی شوند به معماری، نوع سایت و امکانات آن بستگی دارند، اما مهم‌ترین Security Headerهای امروزی معمولاً شامل موارد زیر هستند:

علاوه بر این‌ها، تنظیمات امنیتی Cookie مانند Secure، HttpOnly و SameSite نیز اهمیت بسیار زیادی دارند، هرچند Cookie Attributeها را نباید دقیقاً هم‌رده تمام Security Headerهای این فهرست در نظر گرفت.

Content Security Policy یا CSP چیست؟

Content Security Policy یکی از مهم‌ترین و در عین حال پیچیده‌ترین هدرهای امنیتی سایت است.

CSP به مدیر سایت اجازه می‌دهد مشخص کند مرورگر چه منابعی را از چه Originهایی دریافت و اجرا کند.

فرض کنید صفحه شما برای عملکرد خود به موارد زیر نیاز دارد:

• فایل JavaScript داخلی
• یک فونت از CDN
• تصاویر سایت
• API مشخص
• فایل CSS
• iframe از یک سرویس مشخص

بدون CSP، مرورگر معمولاً براساس HTML تصمیم می‌گیرد منابع تعریف‌شده را دریافت کند.

اما با Content-Security-Policy می‌توان یک Allowlist یا سیاست دقیق‌تر تعریف کرد.

MDN کاربرد اصلی CSP را کنترل منابعی، به‌ویژه JavaScript، می‌داند که یک Document اجازه بارگذاری آن‌ها را دارد. یکی از مهم‌ترین کاربردهای آن نیز کاهش ریسک Cross-Site Scripting است.

CSP چگونه به جلوگیری از XSS کمک می‌کند؟

XSS زمانی اتفاق می‌افتد که مهاجم بتواند محتوایی را وارد صفحه کند که مرورگر آن را به‌عنوان کد قابل اجرا تفسیر کند.

راه‌حل اصلی مقابله با XSS همچنان رفع ریشه آسیب‌پذیری است.

یعنی توسعه‌دهنده باید داده‌های غیرقابل اعتماد را به‌درستی مدیریت کند، Context مناسب Encoding را در نظر بگیرد و از قرار دادن ورودی خام کاربر در نقاط حساس جلوگیری کند.

اما CSP یک خط دفاع اضافه ایجاد می‌کند.

برای مثال می‌توان اجرای Scriptهای نامعتبر را محدود کرد یا فقط Scriptهایی با nonce معتبر را اجرا کرد.

این یعنی حتی اگر یک آسیب‌پذیری Injection در بخشی از سایت باقی مانده باشد، مهاجم ممکن است برای تبدیل آن به اجرای JavaScript با محدودیت بیشتری روبه‌رو شود.

OWASP نیز CSP را یک لایه Defense in Depth در سمت Client معرفی می‌کند که می‌تواند در برابر تهدیدهایی مانند XSS و Clickjacking مفید باشد.

ساختار کلی CSP

یک CSP معمولاً از مجموعه‌ای Directive تشکیل می‌شود.

برای مثال:

Content-Security-Policy: default-src 'self'; img-src 'self' https:; object-src 'none'

در اینجا سه Directive وجود دارد.

default-src سیاست پیش‌فرض منابع را مشخص می‌کند.

img-src مشخص می‌کند تصاویر از چه منابعی قابل دریافت باشند.

object-src می‌تواند بارگذاری Objectهای خاص را محدود کند.

این مثال صرفاً آموزشی است و نباید آن را بدون بررسی روی تمام سایت‌ها کپی کرد.

هر وب‌سایت باید CSP اختصاصی متناسب با منابع واقعی خود داشته باشد.

مهم‌ترین Directiveهای CSP

default-src

default-src معمولاً سیاست پایه برای انواع مختلف منابع است.

مثلاً:

default-src 'self'

به‌صورت کلی بیان می‌کند منابعی که Directive جداگانه‌ای برایشان تعریف نشده است، از همان Origin سایت بارگذاری شوند.

اما یکی از اشتباهات رایج این است که مدیر سایت تصور کند default-src روی تمام Directiveهای CSP اثر جایگزین دارد.

همه Directiveها از default-src fallback نمی‌گیرند.

برای مثال base-uri و frame-ancestors رفتار مستقل خود را دارند.

script-src

script-src از مهم‌ترین بخش‌های CSP است؛ زیرا مستقیماً روی JavaScript اثر می‌گذارد.

سیاست‌های ضعیفی که منابع Script بسیار زیادی را مجاز می‌کنند یا از گزینه‌های ناامن استفاده می‌کنند، می‌توانند بخشی از مزیت CSP را از بین ببرند.

در CSPهای پیشرفته معمولاً از روش‌های nonce-based یا hash-based استفاده می‌شود.

Nonce یک مقدار تصادفی و غیرقابل پیش‌بینی است که برای درخواست مربوطه تولید می‌شود و Scriptهای مجاز باید nonce مرتبط داشته باشند.

این روش به سایت اجازه می‌دهد بدون مجاز کردن عمومی Inline JavaScript، Scriptهای موردنظر خودش را اجرا کند.

style-src

style-src منابع CSS را کنترل می‌کند.

سایت‌هایی که Themeها، Page Builderها یا Pluginهای متعدد دارند ممکن است حجم زیادی Inline Style داشته باشند و همین موضوع اعمال CSP سخت‌گیرانه را دشوار کند.

به همین دلیل پیاده‌سازی CSP در سایت‌های قدیمی معمولاً باید مرحله‌ای انجام شود.

img-src

با img-src می‌توان منابعی را که تصاویر اجازه دارند از آن‌ها دریافت شوند مشخص کرد.

برای سایت‌هایی که تصاویر را از CDN، سرویس بهینه‌سازی تصویر یا Object Storage دریافت می‌کنند، این منابع باید در سیاست لحاظ شوند.

font-src

font-src برای کنترل منابع Font استفاده می‌شود.

اگر سایت از فونت‌های Self-hosted استفاده می‌کند، سیاست می‌تواند بسیار محدود باشد.

اگر از CDN خارجی استفاده شود، دامنه مربوطه باید بررسی شود.

connect-src

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

connect-src می‌تواند ارتباطاتی مانند Fetch، XHR و WebSocket را محدود کند.

در سایت‌های دارای SPA، Dashboard، API یا Analytics، این Directive اهمیت بیشتری پیدا می‌کند.

object-src

در بسیاری از سایت‌های مدرن نیازی به Objectهای Legacy وجود ندارد.

بنابراین محدودسازی شدید object-src در بسیاری از معماری‌ها منطقی است.

frame-ancestors

یکی از مهم‌ترین Directiveها برای مقابله با Clickjacking است.

frame-ancestors مشخص می‌کند چه Originهایی اجازه دارند صفحه شما را داخل iframe یا ساختار مشابه Embed کنند.

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

MDN frame-ancestors را روش انعطاف‌پذیرتر و مدرن‌تری نسبت به X-Frame-Options معرفی می‌کند و توضیح می‌دهد که این Directive می‌تواند از Embed شدن صفحه توسط Originهای غیرمجاز جلوگیری کند.

base-uri

تگ <base> می‌تواند نحوه Resolve شدن URLهای Relative در صفحه را تغییر دهد.

Directive مربوط به base-uri اجازه می‌دهد استفاده از URLهای مجاز در <base> محدود شود.

نکته قابل توجه این است که base-uri از default-src fallback نمی‌گیرد؛ بنابراین اگر این کنترل برای معماری شما مهم است، باید به‌صورت مستقل درباره آن تصمیم گرفته شود.

form-action

form-action تعیین می‌کند فرم‌های صفحه اجازه ارسال اطلاعات به چه مقصدهایی را دارند.

در سایت‌هایی که فرم Login، ثبت‌نام، تماس با ما یا Checkout دارند، این Directive می‌تواند بخشی از سیاست دفاعی باشد.

آیا استفاده از unsafe-inline در CSP مناسب است؟

یکی از مشکلات CSP در سایت‌های قدیمی، وجود مقدار زیادی Inline JavaScript و Inline CSS است.

مدیر سایت Policy را فعال می‌کند، بخش‌هایی از سایت از کار می‌افتد و سپس برای رفع سریع مشکل unsafe-inline را اضافه می‌کند.

این کار ممکن است باعث شود بخشی از کنترل مورد انتظار روی Inline Script از بین برود.

در معماری‌های جدیدتر، روش‌های nonce یا hash معمولاً انتخاب دقیق‌تری هستند.

هدف نباید صرفاً این باشد که مرورگر نشان دهد CSP وجود دارد.

هدف باید طراحی Policy مؤثر باشد.

داشتن CSP ضعیف ممکن است در یک اسکن ساده امتیاز ایجاد کند، اما ارزش امنیتی آن با یک CSP محدود و مهندسی‌شده یکسان نیست.

CSP Report-Only چیست؟

یکی از بهترین روش‌ها برای استقرار CSP استفاده از:

Content-Security-Policy-Report-Only

است.

در این حالت Policy هنوز به‌صورت Blocking اعمال نمی‌شود.

مرورگر می‌تواند تخلف‌های احتمالی را گزارش کند و تیم فنی بررسی کند که اگر Policy فعال شود کدام قسمت‌های سایت دچار مشکل خواهند شد.

این قابلیت برای سایت‌های Production بسیار ارزشمند است.

فرض کنید فروشگاه شما از چند سرویس استفاده می‌کند:

• درگاه پرداخت
• سیستم Analytics
• CDN
• چت آنلاین
• ویدئو
• Tag Manager
• فونت خارجی
• API

اگر یک CSP سخت‌گیرانه را ناگهان فعال کنید، ممکن است یکی از این سرویس‌های Legitimate مسدود شود.

روش منطقی‌تر:

1. شناسایی تمام منابع
2. ساخت Policy اولیه
3. فعال‌سازی Report-Only
4. جمع‌آوری Violationها
5. حذف موارد غیرضروری
6. اصلاح Policy
7. تست مجدد
8. فعال‌سازی Enforcement

OWASP و MDN هر دو به استفاده از Report-Only به‌عنوان ابزار مهم برای آزمایش سیاست CSP پیش از Enforcement اشاره می‌کنند.

CSP چه چیزهایی را حل نمی‌کند؟

این سؤال بسیار مهم است.

CSP:

• کد آسیب‌پذیر Backend را اصلاح نمی‌کند.
• SQL Injection را برطرف نمی‌کند.
• Authentication ضعیف را اصلاح نمی‌کند.
• رمز عبور ضعیف را قوی نمی‌کند.
• افزونه آسیب‌پذیر وردپرس را Patch نمی‌کند.
• جای WAF را نمی‌گیرد.
• جای Sanitization و Output Encoding را نمی‌گیرد.
• مانع تمام انواع XSS نمی‌شود.
• به‌تنهایی سایت را «امن» نمی‌کند.

CSP باید آخرین لایه یا یکی از لایه‌های دفاع در Client-Side باشد، نه پوششی برای مشکلات ساختاری.

HSTS چیست؟

HSTS مخفف HTTP Strict Transport Security است.

هدر اصلی آن:

Strict-Transport-Security

است.

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

ممکن است این سؤال مطرح شود که وقتی روی سایت Redirect از HTTP به HTTPS وجود دارد، دیگر چه نیازی به HSTS داریم؟

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

در یک Redirect معمولی، مرورگر ممکن است ابتدا درخواست HTTP را ارسال کند و سپس سرور آن را به HTTPS هدایت کند.

اما پس از اینکه مرورگر HSTS معتبر دامنه را دریافت و ذخیره کرده باشد، می‌تواند درخواست‌های بعدی HTTP را در سمت Client به HTTPS ارتقا دهد و اصلاً درخواست ناامن معمول را به سرور ارسال نکند.

MDN و OWASP هر دو HSTS را مکانیزمی معرفی می‌کنند که مرورگر را به استفاده از HTTPS برای دامنه ملزم می‌کند.

ساختار HSTS چگونه است؟

نمونه رایج:

Strict-Transport-Security: max-age=31536000

max-age مشخص می‌کند مرورگر تا چه مدت این دامنه را HTTPS-only در نظر بگیرد.

اما دو گزینه مهم دیگر نیز وجود دارند:

includeSubDomains

و:

preload

max-age چیست؟

max-age مدت زمانی است که مرورگر سیاست HSTS را به خاطر می‌سپارد.

عدد برحسب ثانیه است.

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

فعال کردن مستقیم یک max-age بسیار طولانی بدون شناخت معماری می‌تواند ریسک عملیاتی ایجاد کند.

includeSubDomains چیست؟

اگر includeSubDomains اضافه شود، سیاست HSTS روی Subdomainها نیز اثر خواهد داشت.

این گزینه از نظر امنیتی مفید است، اما پیش از فعال‌سازی باید مطمئن شوید تمام Subdomainهای فعلی و موردنیاز واقعاً از HTTPS صحیح پشتیبانی می‌کنند.

برای مثال ممکن است سازمانی چنین Subdomainهایی داشته باشد:

panel.example.com
api.example.com
old.example.com
files.example.com

اگر یکی از آن‌ها HTTPS نداشته باشد و شما HSTS را با includeSubDomains و زمان طولانی فعال کنید، دسترسی کاربران به آن سرویس می‌تواند مختل شود.

preload چیست؟

HSTS یک محدودیت اولیه دارد.

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

Preload برای حل بخشی از این مسئله طراحی شده است.

دامنه‌هایی که شرایط لازم را رعایت می‌کنند می‌توانند در فهرست HSTS Preload قرار بگیرند تا مرورگر حتی در اولین مراجعه بداند دامنه باید فقط از طریق HTTPS باز شود.

اما Preload تصمیمی نیست که بدون بررسی گرفته شود.

خارج شدن از رفتار Preload فوراً در اختیار مدیر سرور نیست و تغییرات List نیز نیازمند فرایند خود است.

بنابراین پیش از استفاده باید همه Subdomainها و سیاست بلندمدت دامنه بررسی شوند.

OWASP درباره تنظیم HSTS با مدت طولانی نیز هشدار می‌دهد؛ زیرا مشکلات Certificate یا تنظیمات HTTPS می‌توانند کاربران Legitimate را از دسترسی به سایت بازدارند.

آیا HSTS جای SSL را می‌گیرد؟

خیر.

HSTS فقط زمانی معنا دارد که HTTPS صحیح از قبل وجود داشته باشد.

شما همچنان به موارد زیر نیاز دارید:

• Certificate معتبر
• TLS Configuration صحیح
• تمدید منظم Certificate
• Redirect درست HTTP به HTTPS
• جلوگیری از Mixed Content
• HTTPS برای تمام Subdomainهای مرتبط
• امن بودن منابع Third-party

HSTS مکمل HTTPS است، نه جایگزین آن.

تفاوت CSP و HSTS چیست؟

CSP و HSTS دو هدف کاملاً متفاوت دارند.

بنابراین انتخاب میان CSP و HSTS مطرح نیست.

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

X-Content-Type-Options چیست؟

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

X-Content-Type-Options: nosniff

است.

مرورگرها در برخی شرایط می‌توانند تلاش کنند نوع واقعی محتوای یک Resource را حدس بزنند؛ رفتاری که به MIME Sniffing معروف است.

مشکل زمانی ایجاد می‌شود که Browser محتوایی را متفاوت از Content-Type اعلام‌شده تفسیر کند.

nosniff به مرورگر می‌گوید MIME Type اعلام‌شده توسط سرور را رعایت کند و از حدس زدن آن خودداری کند.

OWASP استفاده از X-Content-Type-Options: nosniff را توصیه می‌کند و MDN نیز هدف آن را جلوگیری از MIME Sniffing توضیح می‌دهد.

البته وجود این Header به این معنی نیست که مدیر سایت دیگر نیازی به تنظیم درست Content-Type ندارد.

هر Resource همچنان باید MIME Type صحیح داشته باشد.

Referrer-Policy چیست؟

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

این اطلاعات در برخی شرایط می‌تواند شامل بخش‌هایی از URL باشد.

اگر URL سایت شامل شناسه، مسیرهای داخلی یا پارامترهای حساس باشد، ارسال اطلاعات بیش از حد می‌تواند یک مسئله Privacy یا Security ایجاد کند.

Referrer-Policy تعیین می‌کند چه مقدار از این اطلاعات منتقل شود.

یکی از Policyهای رایج:

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

است.

در این حالت برای Requestهای Same-Origin اطلاعات بیشتری قابل ارسال است، اما در Cross-Origin معمولاً Origin ارسال می‌شود و Path کامل منتقل نمی‌شود.

MDN گزینه strict-origin-when-cross-origin را یکی از Policyهای کاربردی معرفی می‌کند و OWASP نیز تنظیم صریح آن را توصیه می‌کند.

no-referrer چه می‌کند؟

Policy زیر:

Referrer-Policy: no-referrer

به‌صورت بسیار محدودکننده عمل می‌کند و Referer را ارسال نمی‌کند.

اما آیا همیشه بهترین انتخاب است؟

خیر.

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

ممکن است Analytics، Attribution یا بخشی از جریان سایت به Referrer نیاز داشته باشد.

هدف همیشه «سخت‌گیرانه‌ترین مقدار ممکن» نیست؛ بلکه «سخت‌گیرانه‌ترین مقدار سازگار با عملکرد موردنیاز» است.

Permissions-Policy چیست؟

مرورگرهای مدرن قابلیت‌های زیادی در اختیار صفحات وب قرار می‌دهند:

• Camera
• Microphone
• Geolocation
• Fullscreen
• Autoplay
• Payment
• Sensorها
• Screen Capture
• قابلیت‌های سخت‌افزاری مختلف

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

Permissions-Policy به وب‌سایت اجازه می‌دهد مشخص کند چه قابلیت‌هایی برای صفحه و بعضی Frameها مجاز باشند.

برای مثال سایتی که هیچ نیازی به Camera و Microphone ندارد می‌تواند دسترسی آن‌ها را در سطح Policy محدود کند.

مثال مفهومی:

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

این Policy بیان می‌کند قابلیت‌های مشخص‌شده برای Context مربوطه مجاز نباشند.

MDN توضیح می‌دهد Permissions Policy برای کنترل قابلیت‌هایی استفاده می‌شود که ممکن است آثار Security یا Privacy داشته باشند. همچنین Feature Policy نام قدیمی‌تر این سازوکار بوده و Syntax جدید باید هنگام پیاده‌سازی بررسی شود.

آیا Permissions-Policy در همه مرورگرها یکسان است؟

خیر.

پشتیبانی Directiveهای مختلف می‌تواند متفاوت باشد و بعضی قابلیت‌ها هنوز در تمام مرورگرهای پرکاربرد وضعیت یکسانی ندارند.

به همین دلیل نباید لیستی طولانی را از اینترنت کپی و بدون تست وارد Production کرد.

MDN برای برخی Directiveهای Permissions Policy وضعیت Limited Availability یا Experimental ذکر می‌کند؛ بنابراین Compatibility باید برای قابلیت‌های مورد استفاده بررسی شود.

X-Frame-Options چیست؟

X-Frame-Options یکی از هدرهای قدیمی‌تر و شناخته‌شده برای کاهش Clickjacking است.

دو مقدار رایج آن:

X-Frame-Options: DENY

و:

X-Frame-Options: SAMEORIGIN

هستند.

DENY یعنی صفحه اجازه نمایش در Frame را ندارد.

SAMEORIGIN اجازه Frame شدن را به شرایط Same-Origin محدود می‌کند.

اما امروزه CSP با Directive مربوط به:

frame-ancestors

گزینه انعطاف‌پذیرتر و مدرن‌تری محسوب می‌شود.

OWASP توصیه می‌کند در صورت امکان از frame-ancestors استفاده شود. MDN نیز اعلام می‌کند گزینه قدیمی ALLOW-FROM منسوخ شده است.

Clickjacking چیست و Security Headerها چگونه کمک می‌کنند؟

Clickjacking حمله‌ای است که در آن مهاجم تلاش می‌کند رابط کاربری سایت قربانی را به شکلی گمراه‌کننده در صفحه دیگری قرار دهد تا کاربر بدون آگاهی روی عنصر موردنظر مهاجم کلیک کند.

یکی از پیش‌نیازهای رایج چنین سناریویی امکان Embed شدن صفحه داخل Frame است.

برای مقابله با آن می‌توان از:

Content-Security-Policy: frame-ancestors ...

استفاده کرد.

و برای Compatibility برخی ساختارها ممکن است X-Frame-Options نیز همچنان حفظ شود.

نکته مهم این است که Policy باید با نیاز سایت هماهنگ باشد.

اگر سایت شما عمداً باید داخل iframe سیستم دیگری نمایش داده شود، استفاده از DENY می‌تواند عملکرد را خراب کند.

Cross-Origin-Opener-Policy یا COOP چیست؟

Cross-Origin-Opener-Policy یا COOP مشخص می‌کند اسناد Top-Level که از Contextهای مختلف باز می‌شوند چگونه از نظر Browsing Context Group جدا شوند.

این موضوع می‌تواند به کاهش برخی کلاس‌های Cross-Origin Attack و XS-Leak کمک کند.

برای برنامه‌های معمولی شاید COOP به اندازه CSP یا HSTS شناخته‌شده نباشد، اما در Web Applicationهای مدرن اهمیت بیشتری پیدا می‌کند.

MDN توضیح می‌دهد COOP می‌تواند رابطه میان Window و Opener را تحت شرایط مختلف کنترل کند و جداسازی Contextها را افزایش دهد.

Cross-Origin-Embedder-Policy یا COEP چیست؟

COEP سیاست Embed شدن Resourceهای Cross-Origin را کنترل می‌کند.

یکی از مقادیر مهم آن:

Cross-Origin-Embedder-Policy: require-corp

است.

در چنین سیاستی Resourceهای Cross-Origin باید شرایط موردنیاز مانند CORP یا CORS مناسب را رعایت کنند.

این Header بیشتر برای Applicationهایی مهم است که به Cross-Origin Isolation نیاز دارند.

فعال کردن آن بدون بررسی می‌تواند Load شدن برخی CDNها، Imageها یا Resourceهای خارجی را متوقف کند.

Cross-Origin-Resource-Policy یا CORP چیست؟

CORP به صاحب یک Resource امکان می‌دهد تعیین کند چه Origin یا Siteهایی اجازه دارند Resource را در Requestهای مربوطه مصرف کنند.

مقادیر متداول:

same-origin
same-site
cross-origin

هستند.

برای مثال:

Cross-Origin-Resource-Policy: same-origin

می‌تواند دسترسی Cross-Origin به Resource را محدود کند.

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

جالب است که MDN درباره یک مشکل Compatibility در برخی سناریوهای PDF با CORP هشدار داده است؛ بنابراین حتی Security Headerهای مفید نیز باید در محیط واقعی تست شوند.

Cookieهای امن چه ارتباطی با Security Headerها دارند؟

اگر سایت Login، پنل کاربری یا Session دارد، امنیت Cookieها به اندازه بسیاری از Headerها مهم است.

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

Secure
HttpOnly
SameSite

Secure

باعث می‌شود Cookie فقط روی ارتباط HTTPS ارسال شود.

HttpOnly

دسترسی مستقیم JavaScript از طریق APIهایی مانند document.cookie را به Cookie محدود می‌کند.

این ویژگی به‌خصوص برای Session Cookieها اهمیت زیادی دارد؛ زیرا در برخی سناریوهای XSS می‌تواند مانع خواندن مستقیم Cookie توسط JavaScript شود.

البته HttpOnly آسیب‌پذیری XSS را برطرف نمی‌کند.

SameSite

مشخص می‌کند Cookie در Requestهای Cross-Site چگونه ارسال شود.

مقادیر شناخته‌شده عبارت‌اند از:

Strict
Lax
None

SameSite می‌تواند بخشی از دفاع در برابر برخی حملات CSRF باشد، اما نباید تنها مکانیسم امنیتی CSRF تلقی شود.

MDN توصیه می‌کند Cookieهای حساس تا حد امکان با Secure و در صورت عدم نیاز JavaScript با HttpOnly تنظیم شوند و برای SameSite نیز براساس جریان سایت مقدار Strict یا Lax در نظر گرفته شود.

آیا X-XSS-Protection هنوز باید فعال شود؟

سال‌ها پیش هدر:

X-XSS-Protection

برای فعال کردن XSS Filter داخلی بعضی Browserها استفاده می‌شد.

اما این مکانیزم امروزه Legacy محسوب می‌شود و در معماری مدرن نباید آن را جایگزین CSP کرد.

OWASP حتی اشاره می‌کند که در برخی شرایط رفتار این فیلترها می‌تواند مشکل‌آفرین باشد و پیشنهاد می‌کند از CSP مناسب استفاده شود و X-XSS-Protection فعال تلقی نشود.

بنابراین دیدن این Header در چک‌لیست‌های بسیار قدیمی نباید شما را به کپی کردن تنظیمات آن‌ها ترغیب کند.

امنیت وب تغییر می‌کند و Headerهای توصیه‌شده ده سال قبل لزوماً همان Headerهای توصیه‌شده امروز نیستند.

Expect-CT چطور؟

Expect-CT نیز Header دیگری است که در بعضی مقالات قدیمی Security Headers دیده می‌شود.

OWASP امروزه استفاده از آن را توصیه نمی‌کند و اشاره دارد که مرورگرهای اصلی خود الزامات Certificate Transparency را مدیریت می‌کنند.

این مثال نشان می‌دهد چرا Copy-Paste کردن «لیست ۱۰ هدر امنیتی» از مقاله‌ای قدیمی روش خوبی برای Hardening سایت نیست.

آیا Server Header را باید حذف کرد؟

بعضی Serverها اطلاعاتی درباره نرم‌افزار Backend ارسال می‌کنند.

برای مثال ممکن است پاسخ مشخص کند سرور از چه Technology استفاده می‌کند.

کم کردن Information Disclosure می‌تواند اقدام مناسبی باشد، اما نباید درباره ارزش آن اغراق کرد.

مخفی کردن نسخه Server:

• آسیب‌پذیری را Patch نمی‌کند.
• سرویس را واقعاً ناشناس نمی‌کند.
• جای Upgrade را نمی‌گیرد.
• مهاجم حرفه‌ای ممکن است با Fingerprinting اطلاعات مشابهی به دست آورد.

بنابراین کاهش Version Disclosure یک Hardening جانبی است، نه کنترل اصلی امنیت.

تنظیم پیشنهادی Security Headerها برای همه سایت‌ها یکسان نیست

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

مثلاً یک سایت شرکتی ساده ممکن است فقط منابع داخلی داشته باشد.

اما یک فروشگاه اینترنتی ممکن است از:

• درگاه پرداخت
• CDN
• Analytics
• Anti-Fraud
• Map
• CAPTCHA
• Live Chat
• Marketing Pixel
• Video Provider

استفاده کند.

CSP این دو سایت نمی‌تواند الزاماً یکسان باشد.

یک پنل مدیریت Internal نیز Policy متفاوتی از یک وب‌سایت محتوایی Public خواهد داشت.

نمونه Baseline مفهومی برای Security Headerها

نمونه زیر فقط برای فهم ساختار است و نباید مستقیماً روی Production کپی شود:

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

این Config ممکن است برای یک سایت مناسب و برای سایت دیگر مخرب باشد.

برای مثال:

• شاید سایت نیاز به iframe داشته باشد.
• شاید Map به Geolocation نیاز داشته باشد.
• شاید Scriptهای Third-party وجود داشته باشند.
• شاید Font از CDN بارگذاری شود.
• شاید Subdomainهای بدون HTTPS وجود داشته باشند.

بنابراین Security Headerها باید مهندسی شوند، نه کپی.

چگونه Security Headerهای سایت را بررسی کنیم؟

چند روش ساده وجود دارد.

بررسی با Developer Tools مرورگر

در Chrome، Firefox و بسیاری از Browserهای دیگر می‌توان:

1. Developer Tools را باز کرد.
2. وارد Network شد.
3. صفحه را Refresh کرد.
4. Request اصلی Document را انتخاب کرد.
5. Response Headers را مشاهده کرد.

در آنجا می‌توان وجود هدرهایی مانند:

content-security-policy
strict-transport-security
x-content-type-options
referrer-policy
permissions-policy

را بررسی کرد.

بررسی با curl

از محیط Command Line نیز می‌توان Headerها را مشاهده کرد.

مثلاً بررسی Response Headerهای دامنه خودتان با ابزارهایی مانند curl روشی متداول برای Troubleshooting است.

نکته مهم این است که Redirectها نیز بررسی شوند؛ زیرا Header صفحه HTTP، Redirect و پاسخ نهایی HTTPS ممکن است با یکدیگر تفاوت داشته باشند.

بررسی از پشت CDN

اگر سایت از Cloudflare یا CDN دیگری استفاده می‌کند، باید مشخص شود Header در کدام لایه اضافه می‌شود.

ممکن است:

• Apache هدر را تولید کند.
• Nginx اضافه کند.
• Application اضافه کند.
• CDN آن را Override کند.
• Reverse Proxy آن را حذف کند.

پس صرفاً بررسی Config Server کافی نیست؛ Response نهایی‌ای که مرورگر دریافت می‌کند اهمیت دارد.

پیاده‌سازی Security Headerها در Nginx

در Nginx معمولاً Headerها با تنظیمات مرتبط با add_header مدیریت می‌شوند.

اما محل قرارگیری Directiveها و رفتار Inheritance اهمیت دارد.

در پروژه‌های واقعی باید Config کامل بررسی شود و پس از تغییر نیز Syntax Test و Regression Test انجام شود.

به‌خصوص CSP را نباید بدون بررسی Dependencyهای Frontend فعال کرد.

پیاده‌سازی Security Headerها در Apache

در Apache معمولاً Module مربوط به Header و Directiveهای Header set یا ساختارهای مشابه استفاده می‌شوند.

اما ممکن است سایت پشت Proxy یا CDN باشد و Header نهایی در لایه دیگری تغییر کند.

بنابراین همیشه نتیجه واقعی Response بررسی شود.

Security Headerها در وردپرس

در سایت وردپرسی چند روش برای اضافه کردن Header وجود دارد:

• تنظیم مستقیم Web Server
• Reverse Proxy
• CDN
• Plugin امنیتی
• Application Layer
• تنظیمات Hosting

از نظر معماری معمولاً اگر دسترسی مناسبی دارید، مدیریت Header در سطح Server یا Edge می‌تواند قابل‌کنترل‌تر باشد.

اما مهم‌تر از محل اعمال، هماهنگی با ساختار WordPress است.

WordPress ممکن است Pluginها و Themeهایی داشته باشد که از:

• Inline Script
• Inline Style
• CDN خارجی
• Google Fonts
• CAPTCHA
• Analytics
• Embed
• Ajax
• REST API

استفاده کنند.

به همین دلیل CSP سخت‌گیرانه در WordPress معمولاً نیازمند Audit دقیق Frontend است.

چرا CSP در وردپرس سخت‌تر است؟

وردپرس اکوسیستم Plugin محور دارد.

هر Plugin ممکن است Resourceهای خاص خود را Load کند.

فرض کنید امروز CSP براساس منابع فعلی سایت ساخته شده است.

فردا مدیر سایت Plugin چت آنلاین نصب می‌کند.

آن Plugin ممکن است Script را از یک Origin جدید دریافت کند.

در صورت CSP سخت‌گیرانه، Feature جدید کار نمی‌کند.

راه صحیح این نیست که CSP را حذف کنیم.

راه صحیح داشتن فرایند Change Management است.

هر تغییر Frontend باید مشخص کند:

• چه Resource جدیدی اضافه شده؟
• از چه Origin؟
• چرا لازم است؟
• آیا می‌توان Self-host کرد؟
• آیا دامنه مورد اعتماد است؟
• آیا CSP باید تغییر کند؟

این دیدگاه CSP را از یک Header ساده به بخشی از Governance امنیت Frontend تبدیل می‌کند.

اشتباهات رایج در تنظیم هدرهای امنیتی سایت

۱. کپی کردن یک Config آماده

رایج‌ترین اشتباه همین است.

کاربر مقاله‌ای پیدا می‌کند که می‌گوید:

«این ۷ هدر را اضافه کنید و سایت شما امن می‌شود.»

سپس Config را بدون شناخت معماری کپی می‌کند.

ممکن است سایت از کار بیفتد یا Policy عملاً امنیت کمی داشته باشد.

۲. استفاده از CSP فقط برای گرفتن امتیاز ابزارهای اسکن

وجود Header مساوی با Policy قوی نیست.

یک CSP بسیار Permissive ممکن است فقط نام CSP را به Response اضافه کند، بدون اینکه کنترل قابل توجهی اعمال کند.

۳. استفاده بی‌دلیل از unsafe-inline

اگر CSP با هدف کاهش XSS اعمال شده است، باز کردن گسترده Inline Execution می‌تواند بخشی از اثر مورد انتظار را کاهش دهد.

۴. فعال کردن HSTS preload بدون بررسی

Preload تصمیم مهمی است.

قبل از آن باید HTTPS در تمام Scope موردنظر پایدار باشد.

۵. فعال کردن includeSubDomains در دامنه دارای Subdomain قدیمی

این کار می‌تواند Legacy Service را از دسترس خارج کند.

۶. محدود کردن Permissions بدون شناخت Featureها

مثلاً سایت واقعاً برای Video Conference به Microphone نیاز دارد اما Policy آن را غیرفعال می‌کند.

۷. حذف X-Frame-Options بدون داشتن frame-ancestors مناسب

اگر تصمیم گرفته‌اید کنترل Clickjacking را به CSP منتقل کنید، مطمئن شوید Policy مربوطه واقعاً وجود دارد.

۸. تصور اینکه Security Header آسیب‌پذیری را برطرف می‌کند

هدرها دفاع تکمیلی هستند.

اگر سایت Stored XSS دارد، Root Cause باید رفع شود.

۹. تست نکردن Mobile و Browserهای مختلف

برخی Policyها ممکن است آثار متفاوتی روی Browser یا WebViewهای مختلف داشته باشند.

۱۰. بررسی نکردن Response نهایی

ممکن است Config Server صحیح باشد اما CDN Header را تغییر دهد.

همیشه چیزی که Client دریافت می‌کند بررسی شود.

چک‌لیست بررسی هدرهای امنیتی سایت

برای Audit اولیه می‌توان از این چک‌لیست استفاده کرد:

HTTPS

• آیا تمام صفحات با HTTPS باز می‌شوند؟
• آیا HTTP به HTTPS Redirect می‌شود؟
• آیا Mixed Content وجود دارد؟
• آیا Certificate معتبر است؟

HSTS

• آیا HSTS فعال است؟
• آیا max-age متناسب است؟
• آیا includeSubDomains واقعاً قابل استفاده است؟
• آیا Preload آگاهانه انتخاب شده است؟

CSP

• آیا Content-Security-Policy وجود دارد؟
• آیا Policy واقعی است یا بیش از حد باز؟
• آیا script-src بررسی شده؟
• آیا منابع Third-party محدود شده‌اند؟
• آیا object-src بررسی شده؟
• آیا frame-ancestors تنظیم شده؟
• آیا base-uri بررسی شده؟
• آیا ابتدا Report-Only آزمایش شده است؟

MIME

• آیا X-Content-Type-Options: nosniff فعال است؟
• آیا Content-Type فایل‌ها صحیح است؟

Referrer

• آیا Referrer-Policy صریح وجود دارد؟
• آیا URL سایت حاوی داده حساس است؟
• آیا Policy با Analytics سازگار است؟

Permissions

• آیا سایت Camera لازم دارد؟
• Microphone چطور؟
• Geolocation؟
• سایر Browser APIها؟
• آیا قابلیت‌های غیرضروری محدود شده‌اند؟

Cookies

• Session Cookie دارای Secure است؟
• HttpOnly فعال است؟
• SameSite متناسب انتخاب شده؟
• Lifetime منطقی است؟
• Scope Cookie بیش از حد گسترده نیست؟

Clickjacking

• آیا frame-ancestors وجود دارد؟
• آیا سایت نیاز واقعی به iframe دارد؟
• آیا X-Frame-Options برای Compatibility لازم است؟

اولویت‌بندی هدرهای امنیتی سایت

اگر قرار باشد برای یک سایت معمولی اولویت‌بندی انجام دهیم، می‌توان به‌صورت تقریبی چنین دیدگاهی داشت:

اولویت بسیار بالا

• HTTPS صحیح
• CSP
• HSTS پس از آماده بودن زیرساخت
• X-Content-Type-Options
• امنیت Cookieهای Session

اولویت بالا

• Referrer-Policy
• Clickjacking Protection با frame-ancestors
• Permissions-Policy براساس نیاز

وابسته به معماری

• COOP
• COEP
• CORP
• سیاست‌های Cross-Origin پیشرفته

این ترتیب مطلق نیست.

برای یک SaaS پیچیده ممکن است Cross-Origin Isolation اهمیت بسیار بیشتری نسبت به یک وبلاگ داشته باشد.

آیا Security Headerها روی سئو تأثیر دارند؟

به‌صورت مستقیم نباید CSP یا HSTS را یک «ترفند SEO» دانست.

اما امنیت و سلامت فنی سایت با تجربه کاربر، اعتماد، HTTPS و پایداری سایت ارتباط دارند.

تنظیم اشتباه Security Header حتی ممکن است به SEO آسیب غیرمستقیم بزند.

برای مثال اگر CSP اشتباه باعث شود:

• JavaScript ضروری اجرا نشود،
• تصاویر Load نشوند،
• CSS ناقص شود،
• Tagهای لازم از کار بیفتند،
• Navigation Client-side خراب شود،

Googlebot یا کاربران ممکن است نسخه ناقصی از سایت مشاهده کنند.

بنابراین هدف از Security Header باید امنیت باشد، نه کسب یک چراغ سبز مصنوعی در ابزارهای Audit.

آیا WAF جایگزین Security Header است؟

خیر.

WAF در نقطه دیگری از معماری کار می‌کند.

WAF تلاش می‌کند Requestها را بررسی و برخی الگوهای مخرب را Block کند.

Security Headerها به Browser دستور می‌دهند چگونه Response و منابع صفحه را مدیریت کند.

برای مثال:

• WAF ممکن است بخشی از Requestهای XSS را شناسایی کند.
• Output Encoding جلوی تبدیل ورودی به کد را می‌گیرد.
• CSP اجرای منابع غیرمجاز را محدود می‌کند.

این‌ها لایه‌های مکمل هستند.

آیا CDN می‌تواند Security Header اضافه کند؟

بله.

بسیاری از CDNها و Reverse Proxyها امکان افزودن یا تغییر Response Header را دارند.

این روش می‌تواند برای مدیریت Centralized بسیار مناسب باشد.

اما دو نکته مهم وجود دارد.

اول اینکه Policy باید متعلق به Application باشد و Team امنیت باید بداند تغییر Frontend چه اثری روی Policy دارد.

دوم اینکه نباید چند لایه مختلف Header متناقض تولید کنند.

برای مثال اگر Application یک CSP و CDN یک CSP دیگر ارسال کند، رفتار نهایی باید دقیقاً بررسی شود.

MDN اشاره می‌کند وجود چند Content Security Policy معمولاً محدودیت‌ها را ترکیب می‌کند و اضافه کردن Policyهای بیشتر نمی‌تواند Policy قبلی را آزادتر کند؛ بلکه می‌تواند محدودیت بیشتری ایجاد کند.

فرایند حرفه‌ای استقرار Security Headerها

به‌جای اضافه کردن یک‌باره همه Headerها، فرایند زیر منطقی‌تر است.

مرحله اول: Inventory

تمام Resourceهای سایت را شناسایی کنید.

• Script
• CSS
• Image
• Font
• API
• WebSocket
• iframe
• Analytics
• Payment
• CAPTCHA
• Advertising

مرحله دوم: Threat Model

مشخص کنید چه خطرهایی برای سایت مهم‌تر هستند.

برای مثال:

• XSS
• Clickjacking
• Session Theft
• Information Leakage
• Mixed Content
• Cross-Origin Data Exposure

مرحله سوم: Baseline

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

مرحله چهارم: CSP Report-Only

Policy اولیه CSP را بدون Blocking کامل آزمایش کنید.

مرحله پنجم: تحلیل گزارش‌ها

همه Violationها Attack نیستند.

ممکن است Browser Extension یا Resource Legitimate باعث Report شده باشد.

گزارش‌ها باید تحلیل شوند.

مرحله ششم: Enforcement

پس از تست مناسب، Policy اعمال شود.

مرحله هفتم: Monitoring

CSP چیزی نیست که یک‌بار تنظیم شود و برای همیشه فراموش شود.

Frontend تغییر می‌کند و Policy نیز باید بازبینی شود.

مرحله هشتم: Regression Testing

پس از تغییر Headerها بخش‌های حیاتی آزمایش شوند:

• Login
• Registration
• Checkout
• Payment
• Search
• Forms
• Upload
• Dashboard
• Mobile
• API Integration

هدرهای امنیتی در معماری Defense in Depth چه جایگاهی دارند؟

فرض کنیم یک فروشگاه اینترنتی حرفه‌ای داریم.

لایه‌های امنیت آن ممکن است شامل موارد زیر باشند:

کاربر
↓
CDN / DDoS Protection
↓
WAF
↓
TLS / HTTPS
↓
Security Headers
↓
Web Server
↓
Application Security
↓
Authentication / Authorization
↓
Database Security
↓
Logging / Monitoring

Security Header فقط یک لایه از این معماری است.

اگر Database Queryها آسیب‌پذیر باشند، CSP جلوی SQL Injection را نمی‌گیرد.

اگر Authorization خراب باشد، HSTS جلوی IDOR را نمی‌گیرد.

اگر Password Policy ضعیف باشد، X-Content-Type-Options کمکی به Credential Stuffing نمی‌کند.

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

CSP سخت‌گیرانه بهتر است یا CSP سازگار؟

بهترین CSP سیاستی است که تا حد امکان سخت‌گیرانه باشد، اما عملکرد Legitimate سایت را حفظ کند.

Policyای که آن‌قدر Strict است که تیم مجبور شود آن را خاموش کند، در عمل موفق نیست.

از طرف دیگر Policy بیش از حد باز نیز ارزش امنیتی محدودی دارد.

بنابراین CSP موفق حاصل تعادل میان:

• Security
• Compatibility
• Maintainability
• Business Requirements

است.

آیا تمام صفحات باید Security Header یکسان داشته باشند؟

الزاماً خیر.

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

مثلاً:

• صفحه Login
• Checkout
• Admin Panel
• Landing Page
• API Response
• Static Asset

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

حتی OWASP اشاره می‌کند Headerهایی مانند CSP بیشتر برای Responseهایی معنا دارند که توسط Browser به‌عنوان محتوای قابل Render و اجرای کد استفاده می‌شوند؛ یک JSON API ساده الزاماً دقیقاً همان نیاز یک HTML Document را ندارد.

Security Headerها را هر چند وقت یک‌بار بررسی کنیم؟

بهتر است بررسی Headerها بخشی از چرخه امنیت سایت باشد.

به‌خصوص در شرایط زیر:

• نصب Plugin جدید
• تغییر Theme
• اضافه شدن CDN
• تغییر Hosting
• Migration Server
• اضافه کردن Payment Provider
• اضافه شدن Analytics
• تغییر Authentication
• اضافه کردن iframe
• اضافه شدن Subdomain
• تغییر Reverse Proxy

در سایت‌های حساس می‌توان Security Headerها را در CI/CD نیز تست کرد.

سؤالات متداول درباره هدرهای امنیتی سایت

هدرهای امنیتی سایت چیست؟

هدرهای امنیتی سایت Response Headerهایی هستند که سرور برای Browser ارسال می‌کند تا محدودیت‌ها و سیاست‌های امنیتی مشخصی اعمال شوند. CSP، HSTS، Referrer-Policy و X-Content-Type-Options از مهم‌ترین نمونه‌ها هستند.

مهم‌ترین Security Header کدام است؟

یک Header واحد برای همه تهدیدها وجود ندارد. CSP برای کنترل منابع و کاهش ریسک XSS بسیار مهم است، HSTS برای HTTPS اهمیت دارد و Headerهایی مانند X-Content-Type-Options و Referrer-Policy نیز اهداف امنیتی مستقل دارند.

CSP چیست؟

Content Security Policy سیاستی است که مشخص می‌کند Browser چه منابعی مانند Script، Font، CSS، Image و Frame را از چه Originهایی بارگذاری یا اجرا کند.

آیا CSP جلوی تمام حملات XSS را می‌گیرد؟

خیر. CSP یک لایه Defense in Depth است. Root Cause آسیب‌پذیری XSS باید با روش‌هایی مانند Output Encoding، Sanitization و کدنویسی امن برطرف شود.

HSTS چیست؟

HSTS یا HTTP Strict Transport Security به Browser اعلام می‌کند دامنه را فقط از طریق HTTPS باز کند.

آیا فعال کردن HSTS خطر دارد؟

اگر HTTPS تمام Domain و Subdomainهای Scope به‌درستی تنظیم نشده باشد، استفاده اشتباه از includeSubDomains یا مدت بسیار طولانی می‌تواند باعث مشکل دسترسی شود.

آیا HSTS preload ضروری است؟

خیر. Preload یک تصمیم اختیاری و نسبتاً بلندمدت است و باید تنها زمانی انجام شود که دامنه و Subdomainهای مربوطه کاملاً برای HTTPS آماده باشند.

X-Content-Type-Options چه می‌کند؟

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

Referrer-Policy چه کاربردی دارد؟

مشخص می‌کند هنگام ارسال Request به صفحات دیگر، چه مقدار اطلاعات درباره URL مبدا در Referer Header منتقل شود.

Permissions-Policy چیست؟

برای محدود کردن قابلیت‌های Browser مانند Camera، Microphone، Geolocation و سایر Featureهای قابل کنترل استفاده می‌شود.

آیا X-Frame-Options هنوز لازم است؟

CSP frame-ancestors روش مدرن‌تر و انعطاف‌پذیرتری برای کنترل Embed شدن صفحه است، اما X-Frame-Options در برخی معماری‌ها همچنان به‌عنوان Compatibility Layer حفظ می‌شود.

آیا X-XSS-Protection را فعال کنیم؟

در معماری مدرن وب این Header Legacy محسوب می‌شود و CSP مناسب راهکار قابل اتکاتری است.

Security Headerها در وردپرس قابل استفاده هستند؟

بله، اما مخصوصاً CSP باید با Pluginها، Theme، CDN، فونت‌ها، Analytics و Resourceهای خارجی سایت هماهنگ شود.

آیا افزونه امنیتی وردپرس برای Security Header کافی است؟

نه الزاماً. باید Response نهایی سایت بررسی شود. Header می‌تواند در Web Server، CDN، Reverse Proxy یا Application تنظیم شده باشد.

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

به‌تنهایی خیر. آن‌ها بخشی از یک معماری امنیتی چندلایه هستند و باید کنار Patch Management، WAF، Authentication امن، Backup، Monitoring و Secure Coding استفاده شوند.

چگونه بفهمیم CSP سایت باعث خرابی شده است؟

Browser Developer Tools، Console و گزارش‌های CSP Violation می‌توانند Resourceهای Block شده را مشخص کنند. استفاده اولیه از Report-Only نیز به شناسایی مشکل قبل از Enforcement کمک می‌کند.

آیا می‌توان Security Header آماده اینترنت را کپی کرد؟

توصیه نمی‌شود. Headerهایی مانند CSP، Permissions-Policy، COEP و HSTS باید براساس Architecture واقعی سایت تنظیم شوند.

جمع‌بندی؛ هدرهای امنیتی سایت را چگونه اصولی پیاده‌سازی کنیم؟

هدرهای امنیتی سایت یکی از مهم‌ترین بخش‌های Hardening لایه وب هستند، اما ارزش واقعی آن‌ها زمانی مشخص می‌شود که براساس معماری و نیاز واقعی سایت تنظیم شوند.

Content-Security-Policy می‌تواند Browser را در بارگذاری و اجرای Resourceها محدود کند و به‌عنوان یک لایه دفاعی در برابر XSS، Injection و Clickjacking نقش مهمی داشته باشد. با این حال CSP جایگزین رفع آسیب‌پذیری و Secure Coding نیست.

HSTS وظیفه متفاوتی دارد و Browser را به استفاده از HTTPS ملزم می‌کند. تنظیم آن، مخصوصاً includeSubDomains و preload، باید پس از بررسی دقیق تمام زیرساخت انجام شود.

X-Content-Type-Options: nosniff از MIME Sniffing جلوگیری می‌کند و Referrer-Policy می‌تواند انتقال غیرضروری اطلاعات URL به Originهای دیگر را محدود کند. Permissions-Policy نیز برای کنترل قابلیت‌های حساسی مانند Camera، Microphone و Geolocation کاربرد دارد.

برای مقابله با Clickjacking نیز frame-ancestors در CSP یکی از کنترل‌های اصلی مدرن محسوب می‌شود، در حالی که X-Frame-Options بیشتر نقش Legacy و Compatibility دارد.

در Applicationهای پیچیده‌تر، Headerهایی مانند COOP، COEP و CORP نیز برای Cross-Origin Isolation و کنترل Resourceها اهمیت پیدا می‌کنند.

اصل کلیدی این است که Security Headerها را صرفاً برای گرفتن امتیاز در ابزارهای Audit فعال نکنید.

یک CSP اشتباه ممکن است سایت را خراب کند. HSTS اشتباه می‌تواند دسترسی کاربران را مختل کند و Permissions-Policy بدون شناخت Application ممکن است Feature ضروری را غیرفعال کند.

فرایند حرفه‌ای شامل Inventory منابع، Threat Modeling، استفاده از CSP Report-Only، تست روی Browserهای مختلف، بررسی Response نهایی، Monitoring و بازبینی Policy پس از تغییرات سایت است.

در نهایت، هدرهای امنیتی سایت زمانی بیشترین ارزش را دارند که بخشی از Defense in Depth باشند؛ یعنی در کنار HTTPS، WAF، Secure Coding، مدیریت Session، کنترل دسترسی، به‌روزرسانی نرم‌افزارها، Backup و Monitoring مورد استفاده قرار گیرند.