این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

یک خط‌مشی پیش‌فرض ارجاع‌دهنده جدید برای Chrome - strict-origin-when-cross-origin

Maud Nalpas

قبل از اینکه شروع کنیم:

اگر از تفاوت بین "سایت" و "مبدا" مطمئن نیستید، به درک "همان سایت" و "منشا یکسان" مراجعه کنید.
سرصفحه Referer به دلیل غلط املایی اصلی در مشخصات، یک R را ندارد. هدر Referrer-Policy و referrer در جاوا اسکریپت و DOM به درستی نوشته شده است.

خلاصه

مرورگرها به سمت سیاست‌های ارجاع پیش‌فرض تقویت‌کننده حریم خصوصی در حال تکامل هستند تا زمانی که یک وب‌سایت خط‌مشی تنظیم نشده است، یک بازگشت خوب را ارائه دهند.
کروم قصد دارد به‌تدریج strict-origin-when-cross-origin به‌عنوان خط‌مشی پیش‌فرض در سال ۸۵ فعال کند. این ممکن است بر موارد استفاده متکی به مقدار ارجاع دهنده از مبدا دیگری تأثیر بگذارد.
این پیش‌فرض جدید است، اما وب‌سایت‌ها همچنان می‌توانند خط‌مشی دلخواه خود را انتخاب کنند.
برای امتحان کردن تغییر در Chrome، پرچم را در chrome://flags/#reduced-referrer-granularity فعال کنید. همچنین می‌توانید این دمو را بررسی کنید تا تغییرات را در عمل مشاهده کنید.
فراتر از خط مشی ارجاع دهنده، نحوه برخورد مرورگرها با ارجاع دهندگان ممکن است تغییر کند—پس مراقب آن باشید.

چه چیزی در حال تغییر است و چرا؟

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

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

نمودار: مرجع در یک درخواست ارسال شده است. — *ارجاع-سیاست و ارجاع.*

هنگامی که هیچ خط مشی تنظیم نشده است، پیش فرض مرورگر استفاده می شود. وب سایت ها اغلب به پیش فرض مرورگر موکول می کنند.

برای پیمایش ها و iframe ها، داده های موجود در سرصفحه Referer نیز می توانند از طریق جاوا اسکریپت با استفاده از document.referrer دسترسی داشته باشند.

تا همین اواخر، no-referrer-when-downgrade یک سیاست پیش فرض گسترده در بین مرورگرها بوده است. اما اکنون بسیاری از مرورگرها در مرحله ای از حرکت به سمت پیش فرض های افزایش حریم خصوصی هستند.

Chrome قصد دارد خط‌مشی پیش‌فرض خود را از نسخه 85 از no-referrer-when-downgrade به strict-origin-when-cross-origin تغییر دهد.

این به این معنی است که اگر هیچ خط‌مشی برای وب‌سایت شما تنظیم نشده باشد، Chrome به‌طور پیش‌فرض از strict-origin-when-cross-origin استفاده می‌کند. توجه داشته باشید که همچنان می توانید یک خط مشی انتخابی خود را تنظیم کنید. این تغییر تنها بر روی وب سایت هایی تأثیر می گذارد که هیچ گونه خط مشی ندارند.

این تغییر به چه معناست؟

strict-origin-when-cross-origin حریم خصوصی بیشتری را ارائه می دهد. با این خط مشی، فقط مبدأ در سرصفحه Referer درخواست های متقاطع ارسال می شود.

این از نشت داده های خصوصی که ممکن است از قسمت های دیگر URL کامل مانند مسیر و رشته پرس و جو قابل دسترسی باشد جلوگیری می کند.

نمودار: مرجع بسته به خط مشی، برای درخواست متقاطع ارسال می شود. — *بسته به خط مشی، ارجاع دهنده (و document.referrer) برای یک درخواست متقاطع ارسال می شود.*

مثلا:

درخواست متقاطع، ارسال شده از https://site-one.example/ stuff/detail?tag=red به https://site-two.example/…:

با no-referrer-when-downgrade : ارجاع دهنده: https://site-one.example/ stuff/detail?tag=red .
با strict-origin-when-cross-origin : مرجع: https://site-one.example/.

چه چیزی ثابت می ماند؟

مانند no-referrer-when-downgrade , strict-origin-when-cross-origin امن است: هنگامی که درخواست از مبدأ HTTPS (امن) به یک HTTP ارسال می شود، هیچ ارجاعی (سرصفحه Referer و document.referrer ) وجود ندارد. ناامن). به این ترتیب، اگر وب‌سایت شما از HTTPS استفاده می‌کند ( اگر نه، آن را در اولویت قرار دهید )، نشانی‌های اینترنتی وب‌سایت شما در درخواست‌های غیر HTTPS درز نمی‌کنند—زیرا هر کسی در شبکه می‌تواند آن‌ها را ببیند، بنابراین کاربران شما را در معرض دید کاربر قرار می‌دهد. حملات میانی
در همان مبدا، مقدار هدر Referer URL کامل است.

به عنوان مثال: درخواست همان منبع، ارسال شده از https://site-one.example/ stuff/detail?tag=red به https://site-one.example/…:

با strict-origin-when-cross-origin : مرجع: https://site-one.example/ stuff/detail?tag=red

چه تاثیری دارد؟

بر اساس بحث با سایر مرورگرها و آزمایش‌های خود کروم در Chrome 84، انتظار می‌رود شکستگی قابل مشاهده توسط کاربر محدود باشد .

ورود به سیستم یا تجزیه و تحلیل سمت سرور که به URL ارجاع دهنده کامل در دسترس است، احتمالاً تحت تأثیر کاهش جزئیات در آن اطلاعات قرار می گیرد.

چه کار باید انجام بدهید؟

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

تغییر را درک کرده و تشخیص دهید

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

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

تغییر را آزمایش کنید و متوجه شوید که آیا این روی سایت شما تأثیر می گذارد یا خیر

از قبل می‌توانید تغییر را از Chrome 81 امتحان کنید: از chrome://flags/#reduced-referrer-granularity در Chrome دیدن کنید و پرچم را فعال کنید. وقتی این پرچم فعال باشد، همه وب‌سایت‌های بدون خط‌مشی از پیش‌فرض جدید strict-origin-when-cross-origin استفاده می‌کنند.

اسکرین شات کروم: نحوه فعال کردن پرچم chrome://flags/#reduced-referrer-granularity. — *فعال کردن پرچم*

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

کار دیگری که برای تشخیص تأثیر باید انجام دهید این است که بررسی کنید آیا پایگاه کد وب سایت شما از ارجاع دهنده استفاده می کند یا نه از طریق هدر Referer درخواست های دریافتی روی سرور یا از document.referrer در جاوا اسکریپت.

اگر از ارجاع دهنده درخواست ها از مبدأ دیگری به سایت خود استفاده می کنید (به طور خاص مسیر و/یا رشته پرس و جو) ممکن است برخی از ویژگی های سایت شما خراب شوند یا رفتار متفاوتی داشته باشند و این مبدا از خط مشی ارجاع دهنده پیش فرض مرورگر استفاده می کند (یعنی هیچ مجموعه سیاست).

اگر این بر سایت شما تأثیر می گذارد، گزینه های جایگزین را در نظر بگیرید

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

از تکنیک‌ها و هدرهای جایگزین مانند Origin و Sec-fetch-Site برای محافظت از CSRF، ورود به سیستم و سایر موارد استفاده خود استفاده کنید. Referer and Referrer-Policy: best practices را بررسی کنید.
در صورت نیاز و شفاف برای کاربران خود، می‌توانید با شرکای خود در یک خط‌مشی خاص هماهنگ شوید. کنترل دسترسی - وقتی ارجاع‌دهنده توسط وب‌سایت‌ها برای اعطای دسترسی خاص به منابع خود به منابع دیگر استفاده می‌شود - ممکن است چنین موردی باشد، اگرچه با تغییر Chrome، مبدا همچنان در سرصفحه Referer (و در document.referrer ) به اشتراک گذاشته می‌شود.

توجه داشته باشید که بیشتر مرورگرها در جهت مشابهی حرکت می‌کنند که نوبت به ارجاع‌دهنده می‌رسد (به پیش‌فرض‌های مرورگر و تحولات آن‌ها در Referer and Referrer-Policy: بهترین شیوه‌ها مراجعه کنید.

یک خط مشی صریح و تقویت کننده حریم خصوصی را در سراسر سایت خود اجرا کنید

در درخواست هایی که توسط وب سایت شما ایجاد می شود چه Referer باید ارسال شود، یعنی چه سیاستی باید برای سایت خود تعیین کنید؟

حتی با توجه به تغییر کروم، ایده خوبی است که در حال حاضر یک خط مشی صریح و تقویت کننده حریم خصوصی مانند strict-origin-when-cross-origin یا سختگیرانه تر تنظیم کنید.

این از کاربران شما محافظت می کند و باعث می شود وب سایت شما در مرورگرها رفتار قابل پیش بینی تری داشته باشد. عمدتاً به شما کنترل می دهد - به جای اینکه سایت شما به پیش فرض های مرورگر وابسته باشد.

Referrer and Referrer-Policy را بررسی کنید: بهترین روش ها برای جزئیات در مورد تنظیم یک خط مشی.

درباره شرکت Chrome

خط‌مشی سازمانی Chrome ForceLegacyDefaultReferrerPolicy برای سرپرستان فناوری اطلاعات در دسترس است که می‌خواهند خط‌مشی ارجاع‌دهنده پیش‌فرض قبلی یعنی no-referrer-when-downgrade در محیط‌های سازمانی اجباری کنند. این به شرکت ها فرصت بیشتری برای آزمایش و به روز رسانی برنامه های خود می دهد.

این خط‌مشی در Chrome 88 حذف خواهد شد.

ارسال بازخورد

آیا بازخوردی برای به اشتراک گذاشتن یا چیزی برای گزارش دارید؟ بازخورد خود را در مورد قصد Chrome برای ارسال به اشتراک بگذارید، یا سؤالات خود را در maudnals@ توییت کنید.

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