مرجع سریع سرصفحه های امنیتی

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

ایجی کیتامورا
آرتور جانک
Artur Janc
X GitHub
ماد نالپاس

این مقاله فهرستی از مهم‌ترین هدرهای امنیتی است که می‌توانید برای محافظت از وب‌سایت خود استفاده کنید. از آن برای درک ویژگی‌های امنیتی مبتنی بر وب، یادگیری نحوه پیاده‌سازی آنها در وب‌سایت خود و به عنوان مرجعی برای مواقعی که به یادآوری نیاز دارید، استفاده کنید.

هدرهای امنیتی توصیه شده برای وب‌سایت‌هایی که با داده‌های حساس کاربران سروکار دارند:
سیاست امنیت محتوا (CSP)
انواع قابل اعتماد
هدرهای امنیتی توصیه شده برای همه وب سایت ها:
گزینه‌های نوع محتوای X
گزینه‌های X-Frame
سیاست منابع بین‌منبعی (CORP)
سیاست بازکننده‌های بین‌منشأیی (COOP)
امنیت انتقال سختگیرانه HTTP (HSTS)
هدرهای امنیتی برای وب‌سایت‌هایی با قابلیت‌های پیشرفته:
اشتراک‌گذاری منابع بین مبدا (CORS)
خط مشی جاسازی متقابل (COEP)
تهدیدهای شناخته شده در وب
قبل از پرداختن به هدرهای امنیتی، در مورد تهدیدهای شناخته شده در وب و اینکه چرا باید از این هدرهای امنیتی استفاده کنید، اطلاعات کسب کنید.

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

محافظت از سایت در برابر آسیب‌پذیری‌های تزریق

آسیب‌پذیری‌های تزریق زمانی ایجاد می‌شوند که داده‌های غیرقابل اعتماد پردازش شده توسط برنامه شما می‌توانند بر رفتار آن تأثیر بگذارند و معمولاً منجر به اجرای اسکریپت‌های تحت کنترل مهاجم شوند. رایج‌ترین آسیب‌پذیری ناشی از اشکالات تزریق ، اسکریپت‌نویسی بین سایتی (XSS) در اشکال مختلف آن، از جمله XSS منعکس شده ، XSS ذخیره شده ، XSS مبتنی بر DOM و سایر انواع آن است.

یک آسیب‌پذیری XSS معمولاً می‌تواند به مهاجم دسترسی کامل به داده‌های کاربر پردازش‌شده توسط برنامه و هرگونه اطلاعات دیگری که در همان مبدأ وب میزبانی می‌شود، بدهد.

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

  • از سیاست امنیت محتوا (CSP) برای کنترل اسکریپت‌هایی که می‌توانند توسط برنامه شما اجرا شوند استفاده کنید تا خطر تزریق کد را کاهش دهید.
  • از انواع قابل اعتماد (Trusted Types) برای اجرای پاکسازی داده‌های ارسالی به APIهای خطرناک جاوا اسکریپت استفاده کنید.
  • از X-Content-Type-Options برای جلوگیری از تفسیر اشتباه مرورگر از انواع MIME منابع وب‌سایت شما استفاده کنید، که می‌تواند منجر به اجرای اسکریپت شود.

سایت خود را از سایر وب‌سایت‌ها جدا کنید

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

آسیب‌پذیری‌های رایجی که باعث تضعیف جداسازی وب می‌شوند عبارتند از کلیک‌ربایی ، جعل درخواست بین‌سایتی (CSRF)، گنجاندن اسکریپت بین‌سایتی (XSSI) و نشت‌های مختلف بین‌سایتی .

اگر به این هدرها علاقه‌مند هستید، «توسعه وب پس از اسپکتر» مطلب بسیار خوبی برای مطالعه است.

یک وب‌سایت قدرتمند و ایمن بسازید

Spectre هر داده‌ای را که بارگذاری می‌شود، با وجود سیاست same-origin، در همان گروه زمینه مرور قرار می‌دهد که به طور بالقوه قابل خواندن است. مرورگرها ویژگی‌هایی را که ممکن است از آسیب‌پذیری پشت یک محیط خاص به نام " cross-origin isolation " سوءاستفاده کنند، محدود می‌کنند. با cross-origin isolation، می‌توانید از ویژگی‌های قدرتمندی مانند SharedArrayBuffer استفاده کنید.

رمزگذاری ترافیک سایت شما

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

رمزگذاری ناکافی می‌تواند در موارد زیر رخ دهد: عدم استفاده از HTTPS، محتوای ترکیبی ، تنظیم کوکی‌ها بدون ویژگی Secure (یا پیشوند __Secure ) یا منطق اعتبارسنجی CORS ضعیف .

سیاست امنیت محتوا (CSP)

اسکریپت نویسی بین سایتی (XSS) حمله‌ای است که در آن یک آسیب‌پذیری در یک وب‌سایت اجازه تزریق و اجرای یک اسکریپت مخرب را می‌دهد.

Content-Security-Policy با محدود کردن اسکریپت‌هایی که می‌توانند توسط صفحه اجرا شوند، یک لایه اضافی برای کاهش حملات XSS فراهم می‌کند.

توصیه می‌شود که CSP سختگیرانه را با استفاده از یکی از رویکردهای زیر فعال کنید:

  • اگر صفحات HTML خود را روی سرور رندر می‌کنید، از یک CSP دقیق مبتنی بر nonce استفاده کنید.
  • اگر HTML شما باید به صورت ایستا یا ذخیره شده در حافظه پنهان ارائه شود، مثلاً اگر یک برنامه تک صفحه‌ای است، از یک CSP دقیق مبتنی بر هش استفاده کنید.

مثال کاربرد: یک CSP مبتنی بر nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
نحوه استفاده از CSP

۱. از یک CSP سختگیرانه مبتنی بر nonce استفاده کنید {: #nonce-based-csp}

اگر صفحات HTML خود را روی سرور رندر می‌کنید، از یک CSP دقیق مبتنی بر nonce استفاده کنید.

برای هر درخواست در سمت سرور، یک مقدار nonce اسکریپت جدید ایجاد کنید و هدر زیر را تنظیم کنید:

فایل پیکربندی سرور

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

در HTML، برای بارگذاری اسکریپت‌ها، ویژگی nonce همه تگ‌های <script> را روی رشته {RANDOM1} یکسان تنظیم کنید.

فهرست.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

گوگل فوتوز یک مثال خوب از CSP دقیق مبتنی بر nonce است. برای مشاهده نحوه استفاده از آن از DevTools استفاده کنید.

۲. از یک CSP دقیق مبتنی بر هش استفاده کنید {: #hash-based-csp}

اگر HTML شما باید به صورت ایستا یا ذخیره شده در حافظه پنهان ارائه شود، مثلاً اگر در حال ساخت یک برنامه تک صفحه‌ای هستید، از یک CSP دقیق مبتنی بر هش استفاده کنید.

فایل پیکربندی سرور

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

در HTML، برای اعمال سیاست مبتنی بر هش، باید اسکریپت‌های خود را درون‌خطی کنید، زیرا اکثر مرورگرها از هش کردن اسکریپت‌های خارجی پشتیبانی نمی‌کنند .

فهرست.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

برای بارگذاری اسکریپت‌های خارجی، بخش «بارگذاری اسکریپت‌های منبع‌دار به صورت پویا» را در گزینه ب: بخش هدر پاسخ CSP مبتنی بر هش مطالعه کنید.

CSP Evaluator ابزاری خوب برای ارزیابی CSP شماست، اما در عین حال یک مثال CSP دقیق مبتنی بر nonce خوب نیز هست. برای مشاهده نحوه استفاده از آن از DevTools استفاده کنید.

مرورگرهای پشتیبانی شده

نکات دیگری که باید در مورد CSP به آنها توجه کرد

  • دستورالعمل frame-ancestors سایت شما را از کلیک‌دزدی محافظت می‌کند - خطری که در صورت اجازه دادن به سایت‌های غیرقابل اعتماد برای جاسازی سایت شما ایجاد می‌شود. اگر راه حل ساده‌تری را ترجیح می‌دهید، می‌توانید از X-Frame-Options برای جلوگیری از بارگیری استفاده کنید، اما frame-ancestors پیکربندی پیشرفته‌ای را در اختیار شما قرار می‌دهد تا فقط به سایت‌های مبدا خاص به عنوان جاسازی‌کننده اجازه دهید.
  • ممکن است از CSP برای اطمینان از بارگذاری تمام منابع سایت خود از طریق HTTPS استفاده کرده باشید. این موضوع دیگر اهمیت چندانی ندارد: امروزه اکثر مرورگرها محتوای ترکیبی (mixed-content) را مسدود می‌کنند.
  • همچنین می‌توانید یک CSP را در حالت فقط گزارش تنظیم کنید.
  • اگر نمی‌توانید یک CSP را به عنوان هدر سمت سرور تنظیم کنید، می‌توانید آن را به عنوان یک متا تگ نیز تنظیم کنید. توجه داشته باشید که نمی‌توانید از حالت فقط گزارش برای متا تگ‌ها استفاده کنید (هرچند این ممکن است تغییر کند ).

بیشتر بدانید

انواع قابل اعتماد

XSS مبتنی بر DOM حمله‌ای است که در آن داده‌های مخرب به یک sink که از اجرای کد پویا مانند eval() یا .innerHTML پشتیبانی می‌کند، منتقل می‌شوند.

انواع قابل اعتماد (Trusted Types) ابزارهایی برای نوشتن، بررسی امنیتی و نگهداری برنامه‌ها بدون DOM XSS ارائه می‌دهند. آن‌ها می‌توانند از طریق CSP فعال شوند و با محدود کردن APIهای وب خطرناک به پذیرش فقط یک شیء خاص - یک نوع قابل اعتماد (Trusted Type)، کد جاوا اسکریپت را به طور پیش‌فرض ایمن کنند.

برای ایجاد این اشیاء، می‌توانید سیاست‌های امنیتی تعریف کنید که در آن‌ها بتوانید اطمینان حاصل کنید که قوانین امنیتی (مانند escape کردن یا sanitization) قبل از نوشتن داده‌ها در DOM به طور مداوم اعمال می‌شوند. این سیاست‌ها تنها مکان‌هایی در کد هستند که می‌توانند به طور بالقوه DOM XSS را ایجاد کنند.

مثال‌های کاربردی

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
نحوه استفاده از انواع قابل اعتماد

  1. انواع قابل اعتماد را برای سینک‌های خطرناک DOM اعمال کنید . هدر CSP و انواع قابل اعتماد:

    Content-Security-Policy: require-trusted-types-for 'script'

    در حال حاضر، تنها مقدار قابل قبول برای دستورالعمل require-trusted-types-for 'script' است.

    البته، می‌توانید Trusted Types را با سایر دستورالعمل‌های CSP ترکیب کنید:

ادغام یک CSP مبتنی بر nonce از بالا با انواع مورد اعتماد: 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;

 <aside class="note"><b>نکته: </b> شما می‌توانید با تنظیم یک دستورالعمل اضافی <code>trusted-types</code> نام‌های مجاز سیاست Trusted Types را محدود کنید (برای مثال، <code>trusted-types myPolicy</code>). با این حال، این یک الزام نیست. </aside>

  1. تعریف یک سیاست

    سیاست: 

    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

  2. اعمال سیاست

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

    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    با استفاده از require-trusted-types-for 'script' ، استفاده از یک نوع قابل اعتماد الزامی است. استفاده از هرگونه API DOM خطرناک با یک رشته منجر به خطا خواهد شد.

مرورگرهای پشتیبانی شده

بیشتر بدانید

گزینه‌های نوع محتوای X

وقتی یک سند HTML مخرب از دامنه شما ارائه می‌شود (برای مثال، اگر تصویری که در یک سرویس عکس آپلود شده است حاوی نشانه‌گذاری HTML معتبر باشد)، برخی مرورگرها آن را به عنوان یک سند فعال در نظر می‌گیرند و به آن اجازه می‌دهند اسکریپت‌ها را در متن برنامه اجرا کند، که منجر به یک اشکال اسکریپت‌نویسی بین‌سایتی می‌شود.

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

مثال استفاده 

X-Content-Type-Options: nosniff
نحوه استفاده از گزینه‌های نوع محتوای X

X-Content-Type-Options: nosniff برای تمام منابع ارائه شده از سرور شما به همراه هدر Content-Type صحیح توصیه می‌شود.

گزینه‌های نوع-محتوای-ایکس: nosniff

سربرگ‌های نمونه ارسال شده با یک سند HTML 

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۶۴.
  • لبه: ۱۲.
  • فایرفاکس: ۵۰.
  • سافاری: ۱۱.

Source

بیشتر بدانید

گزینه‌های X-Frame

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

X-Frame-Options نشان می‌دهد که آیا یک مرورگر باید اجازه داشته باشد صفحه‌ای را در <frame> ، <iframe> ، <embed> یا <object> رندر کند یا خیر. به همه اسناد توصیه می‌شود این هدر را ارسال کنند تا مشخص شود که آیا اجازه می‌دهند توسط اسناد دیگر جاسازی شوند یا خیر.

مثال استفاده 

X-Frame-Options: DENY
نحوه استفاده از گزینه‌های X-Frame

تمام اسنادی که برای جاسازی طراحی نشده‌اند باید از هدر X-Frame-Options استفاده کنند.

می‌توانید نحوه‌ی تأثیر پیکربندی‌های زیر را بر بارگذاری iframe در این نسخه آزمایشی امتحان کنید. منوی کشویی X-Frame-Options را تغییر داده و روی دکمه‌ی Reload the iframe کلیک کنید.

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

انکار کنید که توسط اسناد دیگر جاسازی شده است.

گزینه‌های X-Frame: رد کردن
X-Frame-Options: DENY

از وب‌سایت شما در برابر جاسازی توسط وب‌سایت‌های چند-مبدأ محافظت می‌کند

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

X-Frame-Options: SAMEORIGIN

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۴.
  • لبه: ۱۲.
  • فایرفاکس: ۴.
  • سافاری: ۴.

Source

بیشتر بدانید

سیاست منابع بین‌منبعی (CORP)

یک مهاجم می‌تواند منابعی را از منبع دیگری، مثلاً از سایت شما، در سایت خود جاسازی کند تا با سوءاستفاده از نشت‌های بین سایتی مبتنی بر وب، اطلاعاتی در مورد آنها کسب کند.

Cross-Origin-Resource-Policy با مشخص کردن مجموعه وب‌سایت‌هایی که می‌توانند توسط آنها بارگیری شوند، این خطر را کاهش می‌دهد. این هدر یکی از سه مقدار زیر را می‌گیرد: same-origin ، same-site و cross-origin . به همه منابع توصیه می‌شود که این هدر را ارسال کنند تا مشخص شود که آیا اجازه بارگیری توسط وب‌سایت‌های دیگر را می‌دهند یا خیر.

مثال استفاده 

Cross-Origin-Resource-Policy: same-origin
نحوه استفاده از CORP

توصیه می‌شود که تمام منابع با یکی از سه سرآیند زیر ارائه شوند.

می‌توانید در این نسخه آزمایشی ، نحوه تأثیر پیکربندی‌های زیر را بر بارگذاری منابع تحت محیط Cross-Origin-Embedder-Policy: require-corp بررسی کنید. منوی کشویی Cross-Origin-Resource-Policy را تغییر دهید و روی دکمه Reload the iframe یا Reload the image کلیک کنید تا تأثیر آن را ببینید.

اجازه دهید منابع به cross-origin بارگذاری شوند

توصیه می‌شود سرویس‌هایی شبیه به CDN، منابع را به cross-origin (متقابلاً منبع) بارگذاری کنند (زیرا معمولاً توسط صفحات cross-origin بارگذاری می‌شوند)، مگر اینکه از قبل از طریق CORS ارائه شده باشند که تأثیر مشابهی دارد.

سیاست منابع بین‌منشا: بین‌منشا
Cross-Origin-Resource-Policy: cross-origin

محدود کردن منابعی که باید از same-origin بارگیری شوند

same-origin باید برای منابعی اعمال شود که قرار است فقط توسط صفحات same-origin بارگذاری شوند. شما باید این خاصیت را برای منابعی اعمال کنید که شامل اطلاعات حساس در مورد کاربر یا پاسخ‌های یک API هستند که قرار است فقط از همان مبدا فراخوانی شوند.

به خاطر داشته باشید که منابعی که این هدر را دارند، همچنان می‌توانند مستقیماً بارگیری شوند، برای مثال با پیمایش به URL در یک پنجره مرورگر جدید. سیاست منابع Cross-Origin فقط از جاسازی منبع توسط وب‌سایت‌های دیگر محافظت می‌کند.

سیاست منابع بین‌منشا: منشأ یکسان
Cross-Origin-Resource-Policy: same-origin

محدود کردن منابعی که باید از same-site بارگیری شوند

توصیه می‌شود same-site برای منابعی که مشابه موارد بالا هستند اما قرار است توسط زیر دامنه‌های دیگر سایت شما بارگذاری شوند، اعمال شود.

سیاست منابع بین مبدا: same-site
Cross-Origin-Resource-Policy: same-site

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۷۳.
  • لبه: ۷۹.
  • فایرفاکس: ۷۴.
  • سافاری: ۱۲.

Source

بیشتر بدانید

سیاست بازکننده‌های بین‌منشأیی (COOP)

وب‌سایت یک مهاجم می‌تواند با سوءاستفاده از نشت‌های بین‌سایتی مبتنی بر وب، سایت دیگری را در یک پنجره بازشو باز کند تا اطلاعاتی در مورد آن کسب کند. در برخی موارد، این امر ممکن است امکان سوءاستفاده از حملات کانال جانبی مبتنی بر Spectre را نیز فراهم کند.

هدر Cross-Origin-Opener-Policy راهی را برای یک سند فراهم می‌کند تا خود را از پنجره‌های cross-origin که از طریق window.open() یا پیوندی با target="_blank" بدون rel="noopener" باز می‌شوند، جدا کند. در نتیجه، هیچ بازکننده cross-origin سند هیچ ارجاعی به آن نخواهد داشت و قادر به تعامل با آن نخواهد بود.

مثال استفاده 

Cross-Origin-Opener-Policy: same-origin-allow-popups
نحوه استفاده از کوآپ

می‌توانید در این نسخه آزمایشی، نحوه تأثیر پیکربندی‌های زیر را بر ارتباط با یک پنجره پاپ‌آپ بین مبدا و مقصد بررسی کنید. منوی کشویی Cross-Origin-Opener-Policy را هم برای سند و هم برای پنجره پاپ‌آپ تغییر دهید، روی دکمه Open a popup کلیک کنید و سپس روی Send a postMessage کلیک کنید تا ببینید آیا پیام واقعاً ارسال شده است یا خیر.

جدا کردن یک سند از پنجره‌های چند-مبدأی

تنظیم same-origin باعث می‌شود سند از پنجره‌های سند با مبدا متفاوت جدا شود.

سیاست آغازگر بین مبدایی: same-origin
Cross-Origin-Opener-Policy: same-origin

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

تنظیم same-origin-allow-popups به یک سند اجازه می‌دهد تا ارجاع به پنجره‌های پاپ‌آپ خود را حفظ کند، مگر اینکه COOP را با same-origin یا same-origin-allow-popups تنظیم کرده باشد. این بدان معناست که same-origin-allow-popups همچنان می‌تواند از ارجاع سند هنگام باز شدن به عنوان یک پنجره پاپ‌آپ جلوگیری کند، اما به آن اجازه می‌دهد تا با پاپ‌آپ‌های خود ارتباط برقرار کند.

سیاست بازکننده‌ی بین مبدا: اجازه دادن به پاپ‌آپ‌های با مبدا یکسان
Cross-Origin-Opener-Policy: same-origin-allow-popups

اجازه دهید یک سند توسط پنجره‌های چند مبدأیی ارجاع داده شود

unsafe-none مقدار پیش‌فرض است، اما می‌توانید صریحاً مشخص کنید که این سند می‌تواند توسط یک پنجره‌ی بین‌منبعی باز شود و دسترسی متقابل را حفظ کند.

سیاست بازکننده‌ی بین‌منبعی: ناامن-هیچکدام
Cross-Origin-Opener-Policy: unsafe-none

الگوهای ناسازگار با COOP را گزارش دهید

شما می‌توانید گزارش‌هایی را دریافت کنید وقتی که COOP از تعاملات بین پنجره‌ای با Reporting API جلوگیری می‌کند. 

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP همچنین از حالت فقط گزارش پشتیبانی می‌کند، بنابراین می‌توانید گزارش‌ها را بدون مسدود کردن ارتباط بین اسناد بین مبدا دریافت کنید. 

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۸۳.
  • لبه: ۸۳.
  • فایرفاکس: ۷۹.
  • سافاری: ۱۵.۲.

Source

بیشتر بدانید

اشتراک‌گذاری منابع بین مبدا (CORS)

برخلاف سایر موارد موجود در این مقاله، اشتراک‌گذاری منابع بین مبدائی (CORS) یک هدر نیست، بلکه یک مکانیزم مرورگر است که دسترسی به منابع بین مبدائی را درخواست و اجازه می‌دهد.

به طور پیش‌فرض، مرورگرها سیاست same-origin را برای جلوگیری از دسترسی یک صفحه وب به منابع cross-origin اجرا می‌کنند. به عنوان مثال، هنگامی که یک تصویر cross-origin بارگذاری می‌شود، حتی اگر به صورت بصری در صفحه وب نمایش داده شود، جاوا اسکریپت موجود در صفحه به داده‌های تصویر دسترسی ندارد. ارائه دهنده منبع می‌تواند با انتخاب CORS محدودیت‌ها را کاهش داده و به سایر وب‌سایت‌ها اجازه دهد تا منبع را بخوانند.

مثال استفاده 

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
نحوه استفاده از CORS

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

معیارهای یک درخواست ساده:

  • این روش GET ، HEAD یا POST است.
  • هدرهای سفارشی فقط شامل Accept ، Accept-Language ، Content-Language و Content-Type می‌شوند.
  • Content-Type می‌تواند application/x-www-form-urlencoded ، multipart/form-data یا text/plain باشد.

هر چیز دیگری به عنوان یک درخواست از پیش ارسال شده طبقه‌بندی می‌شود. برای جزئیات بیشتر، به Cross-Origin Resource Sharing (CORS) - HTTP | MDN مراجعه کنید.

درخواست ساده

وقتی یک درخواست معیارهای ساده درخواست را برآورده می‌کند، مرورگر یک درخواست cross-origin با یک هدر Origin ارسال می‌کند که مبدا درخواست‌کننده را نشان می‌دهد.

نمونه هدر درخواست 

Get / HTTP/1.1
Origin: https://example.com

مثال هدر پاسخ 

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com نشان می‌دهد که https://example.com می‌تواند به محتوای پاسخ دسترسی داشته باشد. منابعی که قرار است توسط هر سایتی قابل خواندن باشند، می‌توانند این هدر را روی * تنظیم کنند، در این صورت مرورگر فقط درخواست را بدون نیاز به اعتبارنامه درخواست می‌کند.
  • Access-Control-Allow-Credentials: true نشان می‌دهد که درخواست‌هایی که حاوی اعتبارنامه‌ها (کوکی‌ها) هستند، مجاز به بارگذاری منبع هستند. در غیر این صورت، درخواست‌های احراز هویت شده رد خواهند شد، حتی اگر مبدا درخواست‌کننده در هدر Access-Control-Allow-Origin موجود باشد.

می‌توانید در این نسخه آزمایشی، تأثیر این درخواست ساده را بر بارگذاری منابع تحت محیط Cross-Origin-Embedder-Policy: require-corp بررسی کنید. برای مشاهده تأثیر، روی کادر انتخاب Cross-Origin Resource Sharing کلیک کنید و دکمه Reload the image را بزنید.

درخواست‌های از پیش تعیین‌شده

قبل از درخواست پیش‌پرواز، یک درخواست OPTIONS ارسال می‌شود تا بررسی شود که آیا درخواست بعدی اجازه ارسال دارد یا خیر.

نمونه هدر درخواست 

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST اجازه می‌دهد درخواست زیر با روش POST انجام شود.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type به درخواست‌کننده اجازه می‌دهد تا هدرهای HTTP X-PINGOTHER و Content-Type را در درخواست بعدی تنظیم کند.

مثال‌هایی از هدرهای پاسخ 

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS نشان می‌دهد که درخواست‌های بعدی می‌توانند با متدهای POST ، GET و OPTIONS انجام شوند.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type نشان می‌دهد که درخواست‌های بعدی می‌توانند شامل هدرهای X-PINGOTHER و Content-Type باشند.
  • Access-Control-Max-Age: 86400 نشان می‌دهد که نتیجه درخواست از پیش ارسال شده می‌تواند به مدت ۸۶۴۰۰ ثانیه ذخیره شود.

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۴.
  • لبه: ۱۲.
  • فایرفاکس: ۳.۵
  • سافاری: ۴.

Source

بیشتر بدانید

خط مشی جاسازی متقابل (COEP)

برای کاهش توانایی حملات مبتنی بر Spectre در سرقت منابع بین مبدا، ویژگی‌هایی مانند SharedArrayBuffer یا performance.measureUserAgentSpecificMemory() به طور پیش‌فرض غیرفعال هستند.

Cross-Origin-Embedder-Policy: require-corp از بارگیری منابع بین‌منبعی مانند تصاویر، اسکریپت‌ها، استایل‌شیت‌ها، آی‌فریم‌ها و موارد دیگر توسط اسناد و کارگران جلوگیری می‌کند، مگر اینکه این منابع صریحاً از طریق هدرهای CORS یا CORP بارگیری شوند. COEP را می‌توان با Cross-Origin-Opener-Policy ترکیب کرد تا یک سند را در حالت ایزوله بین‌منبعی قرار دهد.

وقتی می‌خواهید جداسازی بین مبدا و مبدا را برای سند خود فعال کنید Cross-Origin-Embedder-Policy: require-corp استفاده کنید.

مثال استفاده 

Cross-Origin-Embedder-Policy: require-corp
نحوه استفاده از COEP

مثال‌های کاربردی

COEP یک مقدار واحد به نام require-corp می‌گیرد. با ارسال این هدر، می‌توانید به مرورگر دستور دهید که بارگذاری منابعی را که از طریق CORS یا CORP فعال نمی‌شوند، مسدود کند.

نحوه کار COEP

می‌توانید در این نسخه آزمایشی ، تأثیر پیکربندی‌های زیر را بر بارگذاری منابع بررسی کنید. منوی کشویی Cross-Origin-Embedder-Policy ، منوی کشویی Cross-Origin-Resource-Policy ، کادر انتخاب Report Only و غیره را تغییر دهید تا ببینید چگونه بر بارگذاری منابع تأثیر می‌گذارند. همچنین، نسخه آزمایشی نقطه پایانی گزارش‌گیری را باز کنید تا ببینید آیا منابع مسدود شده گزارش شده‌اند یا خیر.

فعال کردن ایزولاسیون بین مبدائی

با ارسال Cross-Origin-Embedder-Policy: require-corp به همراه Cross-Origin-Opener-Policy: same-origin ایزولاسیون بین مبدایی را فعال کنید. 

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

گزارش منابع ناسازگار با COEP

شما می‌توانید گزارش‌های مربوط به منابع مسدود شده ناشی از COEP را با Reporting API دریافت کنید. 

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

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

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۸۳.
  • لبه: ۸۳.
  • فایرفاکس: ۷۹.
  • سافاری: ۱۵.۲.

Source

بیشتر بدانید

امنیت انتقال سختگیرانه HTTP (HSTS)

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

هدر Strict-Transport-Security به مرورگر اطلاع می‌دهد که هرگز نباید سایت را با استفاده از HTTP بارگذاری کند و به جای آن از HTTPS استفاده کند. پس از تنظیم، مرورگر برای مدت زمانی که در هدر تعریف شده است، به جای HTTP از HTTPS برای دسترسی به دامنه بدون ریدایرکت استفاده خواهد کرد.

مثال استفاده 

Strict-Transport-Security: max-age=31536000
نحوه استفاده از HSTS

تمام وب‌سایت‌هایی که از HTTP به HTTPS منتقل می‌شوند، هنگام دریافت درخواست با HTTP، باید با یک هدر Strict-Transport-Security پاسخ دهند. 

Strict-Transport-Security: max-age=31536000

مرورگرهای پشتیبانی شده

Browser Support

  • کروم: ۴.
  • لبه: ۱۲.
  • فایرفاکس: ۴.
  • سافاری: ۷.

Source

بیشتر بدانید

مطالعه بیشتر