بهترین شیوه های ارجاع و ارجاع-سیاست

Maud Nalpas

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

خلاصه

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

نکته :

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

ارجاع و ارجاع - سیاست 101

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

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

یک درخواست HTTP با هدر Referer.

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

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

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

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

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

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

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

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

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

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

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

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

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

جدول زیر نشان می‌دهد که چگونه سیاست‌های ارجاع، داده‌های URL موجود در سربرگ Referrer و 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 کاملاً رمزگذاری نشده است، بنابراین هیچ کاهش امنیتی وجود ندارد.
• اگر یک درخواست از نوع same-origin باشد، به این معنی است که طرح (HTTPS یا HTTP) یکسان است، بنابراین هیچ کاهش امنیتی وجود ندارد.

سیاست‌های پیش‌فرض ارجاع در مرورگرها

از اکتبر ۲۰۲۱

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

مرورگر	Referrer-Policy
کروم	مقدار پیش‌فرض strict-origin-when-cross-origin است.
فایرفاکس	مقدار پیش‌فرض strict-origin-when-cross-origin است. از نسخه ۹۳ به بعد، برای کاربرانی که از محافظت دقیق در برابر ردیابی و مرور خصوصی استفاده می‌کنند، سیاست‌های ارجاع‌دهنده با محدودیت کمتر no-referrer-when-downgrade ، origin-when-cross-origin و unsafe-url برای درخواست‌های بین‌سایتی نادیده گرفته می‌شوند، به این معنی که ارجاع‌دهنده همیشه برای درخواست‌های بین‌سایتی، صرف نظر از سیاست وب‌سایت، کوتاه می‌شود.
لبه	مقدار پیش‌فرض strict-origin-when-cross-origin است.
سافاری	مقدار پیش‌فرض مشابه 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 برای تعیین اینکه یک سایت یا صفحه خاص از چه سیاستی استفاده می‌کند، مفید است.

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

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

چه سیاستی را باید برای وب‌سایت خود تعیین کنید؟

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

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

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

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

چرا strict-origin-when-cross-origin )؟

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

• ایمن : اگر وب‌سایت شما از HTTPS استفاده می‌کند ( اگر نه، آن را در اولویت قرار دهید )، شما نمی‌خواهید URLهای وب‌سایت شما در درخواست‌های غیر HTTPS نشت کنند. از آنجایی که هر کسی در شبکه می‌تواند این موارد را ببیند، نشت‌ها کاربران شما را در معرض حملات شخص در وسط قرار می‌دهند. سیاست‌های no-referrer-when-downgrade ، strict-origin-when-cross-origin ، no-referrer و strict-origin این مشکل را حل می‌کنند.
• افزایش حریم خصوصی : برای یک درخواست cross-origin، no-referrer-when-downgrade آدرس کامل URL را به اشتراک می‌گذارد که می‌تواند باعث ایجاد مشکلات حریم خصوصی شود. strict-origin-when-cross-origin و strict-origin فقط مبدا را به اشتراک می‌گذارند و no-referrer هیچ چیزی را به اشتراک نمی‌گذارد. این به شما گزینه‌های strict-origin-when-cross-origin ، strict-origin و no-referrer به عنوان گزینه‌های افزایش حریم خصوصی می‌دهد.
• مفید : no-referrer و strict-origin هرگز URL کامل را به اشتراک نمی‌گذارند، حتی برای درخواست‌های same-origin. اگر به URL کامل نیاز دارید، 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" />

یا سمت سرور، مثلاً در اکسپرس:

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

اگر strict-origin-when-cross-origin (یا stricter) با همه موارد استفاده شما سازگار نباشد، چه می‌شود؟

در این مورد، یک رویکرد مترقی اتخاذ کنید: یک سیاست محافظتی مانند 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>

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

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

script.js :

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

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

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

هشدار: داده‌هایی که ممکن است برای شما حساس به نظر نرسند، می‌توانند برای کاربران شما حساس باشند، یا می‌توانند صرفاً داده‌هایی نباشند که آنها بخواهند یا انتظار داشته باشند که مخفیانه از طریق cross-origin نشت کنند.

بهترین شیوه‌ها برای درخواست‌های ورودی

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

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

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

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

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

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

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

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

• یکی از ویژگی‌های اساسی سایت شما، استفاده از URL ارجاع‌دهنده‌ی درخواست‌های ورودی بین‌مرجعی است.
• سایت شما دیگر بخشی از URL ارجاع‌دهنده مورد نیاز خود را در یک درخواست بین‌مرجعی دریافت نمی‌کند. این اتفاق زمانی می‌افتد که فرستنده درخواست، خط‌مشی خود را تغییر دهد یا زمانی که هیچ خط‌مشی تنظیم نکرده باشد و خط‌مشی پیش‌فرض مرورگر تغییر کرده باشد (مانند کروم ۸۵ ).

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

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

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

اگر به عناصر دیگری از URL نیاز دارید (مسیر، پارامترهای پرس و جو ...)

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

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

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

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

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

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

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

نتیجه‌گیری

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

برای کسب اطلاعات بیشتر در مورد تکنیک‌های مختلف برای محافظت از کاربران خود، به مجموعه Safe and secure ما مراجعه کنید.

منابع

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

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