روال‌های مطلوب Referer و Referrer-Policy

Maud Nalpas

این صفحه برخی‌از روال‌های مطلوب را برای تنظیم Referrer-Policy و استفاده از ارجاع‌دهنده در درخواست‌های ورودی شرح می‌دهد.

خلاصه

• نشت غیرمنتظره اطلاعات میان‌مبدئی به حریم خصوصی کاربران وب آسیب می‌رساند. خط‌مشی ارجاع‌دهنده محافظتی می‌تواند کمک کند.
• بهتر است خط‌مشی ارجاع‌دهنده strict-origin-when-cross-origin را تنظیم کنید. این خط‌مشی بیشتر کاربرد ارجاع‌دهنده را حفظ می‌کند و درعین‌حال خطر نشت داده‌ها در میان‌مبدأها را کاهش می‌دهد.
• از ارجاع‌دهنده‌ها برای محافظت دربرابر «جعل درخواست بین‌سایتی» (CSRF) استفاده نکنید. به‌جای آن از نشان‌های CSRF و سرایندهای دیگر به‌عنوان لایه امنیتی اضافی استفاده کنید.

توجه:

• اگر درباره تفاوت بین «سایت» و «مبدأ» مطمئن نیستید، آشنایی با «same-site» و «same-origin» را ببینید.
• سرصفحه Referer به‌دلیل غلط املایی در مشخصات اصلی، فاقد R است. سرصفحه Referrer-Policy و referrer در جاوا اسکریپت و DOM به‌درستی نوشته شده‌اند.

Referer and Referrer-Policy 101

درخواست‌های HTTP می‌توانند شامل یک Refererسرصفحه اختیاری باشند، که نشان‌دهنده مبدأ یا نشانی وب صفحه وب است که درخواست از آنجا ارسال شده است. سرصفحه Referrer-Policy تعیین می‌کند چه داده‌هایی در سرصفحه Referer دردسترس قرار گیرد.

در مثال زیر، سرایند Referer شامل نشانی وب کامل صفحه‌ای در site-one است که درخواست از آنجا ارسال شده است.

درخواست HTTP با سرصفحه ارجاع‌دهنده.

سرصفحه Referer ممکن است در انواع مختلف درخواست‌ها وجود داشته باشد:

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

برای پیمایش‌ها و iframeها، می‌توانید بااستفاده از document.referrer با جاوا اسکریپت به این داده‌ها دسترسی پیدا کنید.

می‌توانید چیزهای زیادی از مقادیر Referer یاد بگیرید. برای مثال، یک سرویس تجزیه‌وتحلیل ممکن است از آن‌ها برای تعیین اینکه ۵۰٪ از بازدیدکنندگان site-two.example از social-network.example آمده‌اند استفاده کند. اما وقتی نشانی وب کامل، شامل مسیر و رشته پُرسمان، در Referer در سراسر مبدأها ارسال می‌شود، می‌تواند حریم خصوصی کاربر را به‌خطر بیندازد و ریسک‌های امنیتی ایجاد کند:

استفاده از نشانی وب کامل می‌تواند بر حریم خصوصی و امنیت کاربر تأثیر بگذارد.

نشانی‌های وب ۱ تا ۵ حاوی اطلاعات خصوصی و گاهی اطلاعات حساس یا شناساننده هستند. نشت بی‌صدای این اطلاعات در سراسر مبدأها می‌تواند حریم خصوصی کاربران وب را به‌خطر بیندازد.

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

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

چه خط‌مشی‌هایی دردسترس است و چه تفاوتی باهم دارند؟

می‌توانید یکی از هشت خط‌مشی را انتخاب کنید. بسته به خط‌مشی، داده‌های دردسترس از سرصفحه Referer (و document.referrer) می‌تواند:

• داده‌ای وجود ندارد (سرصفحه Referer وجود ندارد)
• فقط مبدأ
• نشانی وب کامل: مبدأ، مسیر، و رشته پُرسمان

نمونه‌هایی از داده‌های ارجاع‌دهنده.

برخی‌از خط‌مشی‌ها به‌گونه‌ای طراحی شده‌اند که بسته به بافت رفتار متفاوتی داشته باشند: درخواست میان‌مبدئی یا هم‌مبدئی، اینکه آیا مقصد درخواست به‌اندازه مبدأ ایمن است یا نه، یا هر دو. این کار برای محدود کردن مقدار اطلاعات هم‌رسانی‌شده در مبدأها یا مبدأهای با امنیت کمتر مفید است، درحالی‌که غنای ارجاع‌دهنده را در سایت خودتان حفظ می‌کند.

جدول زیر نشان می‌دهد که چگونه خط‌مشی‌های ارجاع‌دهنده داده‌های نشانی وب دردسترس از سرصفحه ارجاع‌دهنده و document.referrer را محدود می‌کنند:

حوزه خط‌مشی	نام خط‌مشی	ارجاع‌دهنده: داده‌ای وجود ندارد	ارجاع‌دهنده: فقط مبدأ	ارجاع‌دهنده: نشانی وب کامل
بافتار درخواست را درنظر نمی‌گیرد	no-referrer	بررسی
	origin		بررسی
	unsafe-url			بررسی
امنیت‌محور	strict-origin	درخواست از HTTPS به HTTP	درخواست از HTTPS به HTTPS یا HTTP به HTTP
	no-referrer-when-downgrade	درخواست از HTTPS به HTTP		درخواست از HTTPS به HTTPS یا HTTP به HTTP
متمرکز بر حریم خصوصی	origin-when-cross-origin		درخواست میان‌مبدئی	درخواست هم‌مبدأ
	same-origin	درخواست میان‌مبدئی		درخواست هم‌مبدأ
تمرکز بر حریم خصوصی و امنیت	strict-origin-when-cross-origin	درخواست از HTTPS به HTTP	درخواست میان‌مبدئی از HTTPS به HTTPS یا HTTP به HTTP	درخواست هم‌مبدأ

MDN فهرست کاملی از خط‌مشی‌ها و نمونه‌های رفتاری را ارائه می‌دهد.

هنگام تنظیم خط‌مشی ارجاع‌دهنده، باید به چند نکته توجه کنید:

• همه خط‌مشی‌هایی که طرح (HTTPS درمقابل HTTP) را درنظر می‌گیرند (strict-origin، no-referrer-when-downgrade، و strict-origin-when-cross-origin) با درخواست‌های ارسالی از یک مبدأ HTTP به مبدأ HTTP دیگر همانند درخواست‌های ارسالی از مبدأ HTTPS به مبدأ HTTPS دیگر رفتار می‌کنند، هرچند HTTP امنیت کمتری دارد. دلیلش این است که برای این خط‌مشی‌ها، آنچه اهمیت دارد این است که آیا تنزل امنیتی رخ می‌دهد یا نه؛ یعنی اگر درخواست بتواند داده‌ها را از مبدأ رمزگذاری‌شده به مبدأ رمزگذاری‌نشده افشا کند، مانند درخواست‌های HTTPS ← HTTP. درخواست HTTP ← HTTP کاملاً رمزگذاری‌نشده است، بنابراین تنزلی وجود ندارد.
• اگر درخواست هم‌مبدأ باشد، یعنی طرح (HTTPS یا HTTP) یکسان است، بنابراین تنزل امنیتی وجود ندارد.

خط‌مشی‌های ارجاع‌دهنده پیش‌فرض در مرورگرها

از اکتبر ۲۰۲۱

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

مرورگر	Referrer-Policy پیش‌فرض / رفتار
Chrome	پیش‌فرض strict-origin-when-cross-origin است.
Firefox	پیش‌فرض strict-origin-when-cross-origin است. از نسخه ۹۳، برای کاربران «محافظت دربرابر ردگیری سخت‌گیرانه» و «مرور خصوصی»، خط‌مشی‌های ارجاع‌دهنده با محدودیت کمتر no-referrer-when-downgrade، origin-when-cross-origin، و unsafe-url برای درخواست‌های بین‌سایتی نادیده گرفته می‌شوند، یعنی ارجاع‌دهنده همیشه برای درخواست‌های بین‌سایتی، صرف‌نظر از خط‌مشی وب‌سایت، کوتاه می‌شود.
Edge	پیش‌فرض strict-origin-when-cross-origin است.
Safari	پیش‌فرض شبیه به strict-origin-when-cross-origin است، با برخی تفاوت‌های خاص. برای جزئیات، جلوگیری از ردیابی «محافظت دربرابر ردیابی» را ببینید.

روال‌های مطلوب برای تنظیم خط‌مشی ارجاع‌دهنده

هدف: به‌طور صریح خط‌مشی بهبود حریم خصوصی، مانند strict-origin-when-cross-origin(یا سخت‌گیرانه‌تر) را تنظیم کنید.

روش‌های مختلفی برای تنظیم خط‌مشی‌های ارجاع‌دهنده برای سایت شما وجود دارد:

• به‌عنوان سرصفحه HTTP
• در HTML
• از جاوا اسکریپت به‌ازای هر درخواست

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

سرایند HTTP و عنصر متا هر دو در سطح صفحه هستند. ترتیب اولویت برای تعیین خط‌مشی مؤثر عنصر به‌صورت زیر است:

1. خط‌مشی سطح عنصر
2. خط‌مشی سطح صفحه
3. پیش‌فرض مرورگر

مثال:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

تصویر با خط‌مشی no-referrer-when-downgrade درخواست شده است و همه درخواست‌های زیرمنبع دیگر از این صفحه از خط‌مشی strict-origin-when-cross-origin پیروی می‌کنند.

چگونه خط‌مشی ارجاع‌دهنده را ببینم؟

securityheaders.com برای تعیین اینکه یک سایت یا صفحه خاص از کدام خط‌مشی استفاده می‌کند مفید است.

همچنین می‌توانید از ابزارهای توسعه‌دهنده در Chrome،‏ Edge، یا Firefox برای دیدن خط‌مشی ارجاع‌دهنده استفاده‌شده برای درخواست خاصی استفاده کنید. در زمان نوشتن این مطلب، Safari سرصفحه Referrer-Policy را نشان نمی‌دهد، اما Referer ارسال‌شده را نشان می‌دهد.

پانل شبکه Chrome DevTools با درخواست انتخاب‌شده.

کدام خط‌مشی را باید برای وب‌سایتتان تنظیم کنید؟

اکیداً توصیه می‌کنیم خط‌مشی بهبود حریم خصوصی مانند strict-origin-when-cross-origin (یا سخت‌گیرانه‌تر) را به‌طور صریح تنظیم کنید.

چرا «صریحاً»؟

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

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

چرا strict-origin-when-cross-origin (یا سخت‌گیرانه‌تر)؟

به خط‌مشی‌ای نیاز دارید که ایمن، تقویت‌کننده حریم خصوصی، و مفید باشد. معنی «مفید» به آنچه از ارجاع‌دهنده می‌خواهید بستگی دارد:

• ایمن: اگر وب‌سایتتان از HTTPS استفاده می‌کند (اگر استفاده نمی‌کند، آن را در اولویت قرار دهید)، نباید اجازه دهید نشانی‌های وب وب‌سایتتان در درخواست‌های غیرHTTPS لو برود. ازآنجایی‌که هرکسی در شبکه می‌تواند این‌ها را ببیند، نشت اطلاعات کاربرانتان را درمعرض حملات «شخص میانی» قرار می‌دهد. خط‌مشی‌های no-referrer-when-downgrade، strict-origin-when-cross-origin، no-referrer، و strict-origin این مشکل را حل می‌کنند.
• بهبود حریم خصوصی: برای درخواست میان‌مبدئی، no-referrer-when-downgrade نشانی وب کامل را هم‌رسانی می‌کند که می‌تواند باعث مشکلات حریم خصوصی شود. ‫strict-origin-when-cross-origin و strict-origin فقط مبدأ را هم‌رسانی می‌کنند، و no-referrer هیچ‌چیز را هم‌رسانی نمی‌کند. این امر باعث می‌شود که strict-origin-when-cross-origin، strict-origin، و no-referrer را به‌عنوان گزینه‌های بهبود حریم خصوصی داشته باشید.
• مفید: no-referrer و strict-origin هرگز نشانی وب کامل را هم‌رسانی نمی‌کنند، حتی برای درخواست‌های هم‌مبدأ. اگر به نشانی وب کامل نیاز دارید، strict-origin-when-cross-origin گزینه بهتری است.

همه این‌ها یعنی strict-origin-when-cross-origin معمولاً انتخاب معقولی است.

مثال: تنظیم خط‌مشی strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

یا در سمت سرور، برای مثال در Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

اگر strict-origin-when-cross-origin (یا سخت‌گیرانه‌تر) همه موارد استفاده شما را پوشش ندهد چه؟

در این مورد، رویکرد پیش‌رونده را اتخاذ کنید: خط‌مشی محافظتی مانند strict-origin-when-cross-origin را برای وب‌سایتتان تنظیم کنید و درصورت نیاز، خط‌مشی آسان‌گیرانه‌تری را برای درخواست‌های خاص یا عناصر HTML تنظیم کنید.

مثال: خط‌مشی سطح عنصر

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit ممکن است document.referrer یا سرایند Referer را برای درخواست‌های بین‌سایتی محدود کند. جزئیات را ببینید.

مثال: خط‌مشی سطح درخواست

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

چه چیز دیگری را باید درنظر بگیرید؟

خط‌مشی شما باید به وب‌سایت و موارد استفاده شما بستگی داشته باشد، همان‌طور که توسط شما، تیم شما، و شرکت شما تعیین شده است. اگر برخی‌از نشانی‌های وب حاوی داده‌های شناسایی یا حساس است، خط‌مشی محافظتی تنظیم کنید.

هشدار: داده‌هایی که ممکن است ازنظر شما حساس نباشند می‌توانند برای کاربران شما حساس باشند، یا ممکن است داده‌هایی باشند که کاربران نمی‌خواهند یا انتظار ندارند به‌طور پنهانی میان‌مبدئی نشت کنند.

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

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

محافظت از داده‌های کاربران

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

ارجاع‌دهنده‌های ورودی می‌توانند {referer-can-change} را تغییر دهند

استفاده از ارجاع‌دهنده از درخواست‌های میان‌مبدئی ورودی چند محدودیت دارد:

• اگر کنترلی بر پیاده‌سازی فرستنده درخواست ندارید، نمی‌توانید درباره سرصفحه Referer (و document.referrer) که دریافت می‌کنید فرضیه‌ای داشته باشید. ممکن است صادرکننده درخواست تصمیم بگیرد در هرزمانی به خط‌مشی no-referrer یا به‌طور کلی‌تر به خط‌مشی سخت‌گیرانه‌تری نسبت‌به آنچه قبلاً استفاده می‌کرد تغییر دهد. این یعنی داده‌های کمتری نسبت‌به قبل از Referer دریافت می‌کنید.
• مرورگرها به‌طور فزاینده‌ای از Referrer-Policy strict-origin-when-cross-origin به‌طور پیش‌فرض استفاده می‌کنند. این یعنی اگر سایت فرستنده خط‌مشی‌ای تنظیم نکرده باشد، ممکن است اکنون در درخواست‌های میان‌مبدئی ورودی، به‌جای نشانی وب کامل ارجاع‌دهنده، فقط مبدأ را دریافت کنید.
• مرورگرها ممکن است نحوه مدیریت Referer را تغییر دهند. برای مثال، برخی‌از توسعه‌دهندگان مرورگر ممکن است تصمیم بگیرند که برای محافظت از حریم خصوصی کاربر، همیشه ارجاع‌دهنده‌ها را در درخواست‌های زیرمنبع میان‌مبدئی به مبدأها کوتاه کنند.
• سرصفحه Referer (و document.referrer) ممکن است حاوی داده‌های بیشتری از آنچه نیاز دارید باشد. برای مثال، ممکن است نشانی وب کامل داشته باشد درحالی‌که شما فقط می‌خواهید بدانید درخواست میان‌مبدئی است یا نه.

جایگزین‌های Referer

در شرایط زیر ممکن است لازم باشد گزینه‌های جایگزین را درنظر بگیرید:

• یکی از ویژگی‌های ضروری سایت شما از نشانی وب ارجاع‌دهنده درخواست‌های میان‌مبدئی ورودی استفاده می‌کند.
• سایت شما دیگر بخشی از نشانی وب ارجاع‌دهنده را که در درخواست میان‌مبدئی نیاز دارد دریافت نمی‌کند. این اتفاق زمانی رخ می‌دهد که فرستنده درخواست خط‌مشی خود را تغییر دهد یا زمانی که خط‌مشی‌ای تنظیم نکرده باشد و خط‌مشی پیش‌فرض مرورگر تغییر کرده باشد (مانند Chrome 85).

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

اگر فقط به مبدأ نیاز دارید

• اگر از ارجاع‌دهنده در دستورگانی استفاده می‌کنید که دسترسی سطح بالا به صفحه دارد، window.location.origin جایگزین است.
• درصورت دردسترس بودن، سرصفحه‌هایی مثل Origin و Sec-Fetch-Site Origin را به شما می‌دهند یا توضیح می‌دهند که آیا درخواست میان‌مبدئی است یا نه، که ممکن است دقیقاً همان چیزی باشد که نیاز دارید.

اگر به عناصر دیگر نشانی وب (مسیر، پارامترهای پُرسمان…) نیاز دارید

• پارامترهای درخواست ممکن است مورد استفاده شما را برطرف کند، که باعث می‌شود کار تجزیه ارجاع‌دهنده را انجام ندهید.
• اگر از ارجاع‌دهنده در دستورگانی استفاده می‌کنید که دسترسی سطح بالا به صفحه دارد، window.location.pathname ممکن است به‌عنوان جایگزین کار کند. فقط بخش مسیر نشانی وب را استخراج کنید و آن را به‌عنوان آرگومان ارسال کنید تا اطلاعات حساس احتمالی در پارامترهای نشانی وب ارسال نشود.

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

• بررسی کنید که آیا می‌توانید سیستم‌هایتان را تغییر دهید تا انتظار داشته باشند که فرستنده درخواست (برای مثال، site-one.example) اطلاعات موردنیازتان را به‌طور صریح در نوعی پیکربندی تنظیم کند.
  • مزایا: صریح‌تر، حافظ حریم خصوصی بیشتر برای کاربران site-one.example، سازگارتر با آینده.
  • نکته منفی: احتمالاً کار بیشتری ازطرف شما یا برای کاربران سیستم شما نیاز است.
• بررسی کنید آیا سایتی که درخواست‌ها را ارسال می‌کند با تنظیم «خط‌مشی ارجاع‌دهنده» no-referrer-when-downgrade برای هر عنصر یا هر درخواست موافقت می‌کند یا نه.
  • نکته منفی: احتمالاً برای کاربران site-one.example کمتر حافظ حریم خصوصی است، احتمالاً در همه مرورگرها پشتیبانی نمی‌شود.

محافظت دربرابر جعل درخواست بین‌سایتی (CSRF)

فرستنده درخواست همیشه می‌تواند با تنظیم خط‌مشی no-referrer تصمیم بگیرد که ارجاع‌دهنده را ارسال نکند و عامل بدخواه حتی می‌تواند ارجاع‌دهنده را جعل کند.

از نشانه‌های CSRF به‌عنوان محافظت اصلی استفاده کنید. برای محافظت بیشتر، از SameSite استفاده کنید، و به‌جای Referer، از سرایندهایی مثل Origin (درخواست‌های POST و CORS دردسترس است) و Sec-Fetch-Site درصورت دردسترس بودن استفاده کنید.

ثبت و اشکال‌زدایی

حتماً از داده‌های شخصی یا حساس کاربران که ممکن است در Referer باشد محافظت کنید.

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

پرداخت‌ها

ارائه‌دهندگان پرداخت ممکن است برای بررسی‌های امنیتی به سرایند Referer درخواست‌های ورودی متکی باشند.

برای مثال:

• کاربر روی دکمه خرید در online-shop.example/cart/checkout کلیک می‌کند.
• online-shop.example برای مدیریت تراکنش به payment-provider.example هدایت می‌کند.
• payment-provider.example Referer این درخواست را با فهرستی از مقادیر مجاز Referer که فروشندگان تنظیم کرده‌اند مقایسه می‌کند. اگر با هیچ‌کدام از ورودی‌های فهرست مطابقت نداشته باشد، payment-provider.example درخواست را رد می‌کند. اگر مطابقت داشته باشد، کاربر می‌تواند تراکنش را ادامه دهد.

روال‌های مطلوب برای بررسی‌های امنیتی جریان پرداخت

به‌عنوان ارائه‌دهنده پرداخت، می‌توانید از Referer به‌عنوان بررسی پایه دربرابر برخی حملات استفاده کنید. بااین‌حال، سرایند Referer به‌تنهایی مبنای قابل‌اعتمادی برای بررسی نیست. سایت درخواست‌کننده، چه فروشنده قانونی باشد چه نباشد، می‌تواند خط‌مشی‌ای تنظیم کندno-referrer که اطلاعات Referer را برای ارائه‌دهنده پرداخت غیرقابل‌دسترس کند.

بررسی Referer ممکن است به ارائه‌دهندگان پرداخت کمک کند مهاجمان ساده‌لوحی را که خط‌مشی no-referrer تنظیم نکرده‌اند شناسایی کنند. اگر از Referer به‌عنوان اولین بررسی استفاده می‌کنید:

• انتظار نداشته باشید که Referer همیشه وجود داشته باشد. اگر وجود دارد، آن را فقط با حداقل داده‌هایی که می‌تواند شامل شود، یعنی مبدأ، بررسی کنید.
  • هنگام تنظیم فهرست مقادیر مجاز Referer، مطمئن شوید که فقط مبدأ را اضافه کنید و هیچ مسیری اضافه نکنید.
  • برای مثال، مقادیر مجاز Referer برای online-shop.example باید online-shop.example باشد، نه online-shop.example/cart/checkout. با انتظار نداشتن هیچ Referer یا انتظار داشتن مقدار Referer که فقط مبدأ سایت درخواست‌کننده باشد، از خطاهایی که ممکن است ناشی از فرض کردن درباره Referrer-Policy فروشنده باشد جلوگیری می‌کنید.
• اگر Referer وجود ندارد، یا اگر وجود دارد و بررسی مبدأ Referer پایه شما موفقیت‌آمیز است، می‌توانید به روش درستی‌سنجی دیگری که قابل‌اعتمادتر است بروید.

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

وقتی سایت فروشنده HTTP بدون خط‌مشی ارجاع‌دهنده به ارائه‌دهنده پرداخت HTTPS هدایت می‌شود، چه اتفاقی برای Referer می‌افتد؟

هیچ Referer در درخواست به ارائه‌دهنده پرداخت HTTPS قابل‌مشاهده نیست، زیرا اکثر مرورگرها به‌طور پیش‌فرض از strict-origin-when-cross-origin یا no-referrer-when-downgrade استفاده می‌کنند، وقتی وب‌سایت هیچ خط‌مشی‌ای تنظیم نکرده باشد. تغییر Chrome به خط‌مشی پیش‌فرض جدید این رفتار را تغییر نخواهد داد.

توجه: اگر وب‌سایتتان از HTTP استفاده می‌کند، به HTTPS منتقل شوید.

نتیجه‌گیری

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

برای آشنایی بیشتر با روش‌های مختلف محافظت از کاربران، به مجموعه ایمن و مطمئن ما مراجعه کنید

منابع

• آشنایی با «same-site» و «same-origin»
• سرصفحه امنیتی جدید: خط‌مشی ارجاع‌دهنده (۲۰۱۷)
• خط‌مشی ارجاع‌دهنده در MDN
• سرصفحه ارجاع‌دهنده: نگرانی‌های امنیتی و حریم خصوصی در MDN
• تغییر Chrome: هدف Blink برای پیاده‌سازی
• تغییر Chrome: هدف Blink برای ارسال
• تغییر Chrome: ورودی وضعیت
• تغییر Chrome: نسخه ۸۵ بتا پست وبلاگ
• رشته GitHub درباره کوتاه کردن ارجاع‌دهنده: مرورگرهای مختلف چه می‌کنند
• مشخصات خط‌مشی ارجاع‌دهنده

با تشکر فراوان از مشارکت و بازخورد همه بازبینان - به‌ویژه Kaustubha Govind، David Van Cleve،‏ Mike West،‏ Sam Dutton،‏ Rowan Merewood،‏ Jxck، و Kayce Basques.