این صفحه برخی از بهترین روشها را برای تنظیم خطمشی ارجاعدهنده و استفاده از ارجاعدهنده در درخواستهای دریافتی نشان میدهد.
خلاصه
- نشت اطلاعات متقابل غیرمنتظره به حریم خصوصی کاربران وب آسیب می رساند. یک خط مشی ارجاع حفاظتی می تواند کمک کند.
- در نظر بگیرید که یک خط مشی ارجاع دهنده با
strict-origin-when-cross-origin
تنظیم کنید. این بیشتر سودمندی ارجاع دهنده را حفظ می کند، در حالی که خطر نشت منابع متقاطع داده ها را کاهش می دهد. - از ارجاعدهندهها برای محافظت از جعل درخواست متقابل (CSRF) استفاده نکنید. به جای آن از توکنهای CSRF و سایر هدرها به عنوان یک لایه امنیتی اضافی استفاده کنید.
ارجاع و ارجاع - سیاست 101
درخواستهای HTTP میتواند شامل یک سرصفحه Referer
اختیاری باشد که نشاندهنده مبدا یا URL صفحه وب است که درخواست از آن انجام شده است. هدر Referrer-Policy
مشخص میکند که چه دادههایی در سرصفحه Referer
در دسترس هستند.
در مثال زیر، هدر Referer
شامل URL کامل صفحه در site-one
است که درخواست از آن انجام شده است.
هدر Referer
ممکن است در انواع مختلفی از درخواست ها وجود داشته باشد:
- درخواست های ناوبری، زمانی که کاربر روی یک پیوند کلیک می کند.
- درخواستهای منبع فرعی، زمانی که یک مرورگر تصاویر، iframe، اسکریپتها و سایر منابع مورد نیاز یک صفحه را درخواست میکند.
برای پیمایش ها و iframe ها، می توانید با استفاده از document.referrer
به این داده ها با جاوا اسکریپت نیز دسترسی داشته باشید.
شما می توانید از مقادیر Referer
چیزهای زیادی یاد بگیرید. به عنوان مثال، یک سرویس تجزیه و تحلیل ممکن است از آنها استفاده کند تا مشخص کند که 50٪ از بازدیدکنندگان site-two.example
از social-network.example
هستند. اما وقتی URL کامل، از جمله مسیر و رشته پرس و جو، در Referer
در سراسر مبدا ارسال می شود، می تواند حریم خصوصی کاربر را به خطر بیندازد و خطرات امنیتی ایجاد کند:
URL های شماره 1 تا 5 حاوی اطلاعات خصوصی و گاهی اوقات اطلاعات حساس یا شناسایی هستند. افشای بیصدا این موارد در سرچشمهها میتواند حریم خصوصی کاربران وب را به خطر بیاندازد.
URL شماره 6 یک URL قابلیت است. اگر کسی غیر از کاربر مورد نظر این را دریافت کند، یک عامل مخرب می تواند کنترل حساب این کاربر را در دست بگیرد.
برای محدود کردن دادههای ارجاعدهنده برای درخواستهای سایت شما، میتوانید یک خطمشی ارجاعدهنده تنظیم کنید.
چه سیاست هایی در دسترس هستند و چه تفاوتی دارند؟
شما می توانید یکی از هشت خط مشی را انتخاب کنید. بسته به خط مشی، داده های موجود از سرصفحه Referer
(و document.referrer
) می تواند باشد:
- بدون داده (هیچ عنوان
Referer
وجود ندارد) - فقط مبدا
- URL کامل: مبدا، مسیر، و رشته پرس و جو
برخی از خطمشیها به گونهای طراحی شدهاند که بسته به زمینه، رفتار متفاوتی داشته باشند: درخواست با مبدا متقاطع یا با مبدا یکسان، آیا مقصد درخواست به اندازه مبدأ امن است یا هر دو. این برای محدود کردن مقدار اطلاعات به اشتراک گذاشته شده در بین مبداها یا به مبداهای کمتر امن مفید است و در عین حال غنای ارجاع دهنده را در سایت خود حفظ می کند.
جدول زیر نشان میدهد که چگونه خطمشیهای ارجاعدهنده دادههای URL موجود از سرصفحه ارجاع و 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) یکسان است، بنابراین هیچ کاهش امنیتی وجود ندارد.
سیاست های مراجعه کننده پیش فرض در مرورگرها
از اکتبر 2021
اگر خط مشی ارجاعی تنظیم نشده باشد، مرورگر از خط مشی پیش فرض خود استفاده می کند.
مرورگر | Referrer-Policy پیش فرض / رفتار |
---|---|
کروم | پیش فرض strict-origin-when-cross-origin . |
فایرفاکس | پیشفرض، strict-origin-when-cross-origin است.از نسخه 93 ، برای کاربران «محافظت از ردیابی دقیق» و «مرور خصوصی»، خطمشیهای کمتر محدودکننده ارجاعدهنده no-referrer-when-downgrade ، origin-when-cross-origin ، و unsafe-url برای درخواستهای متقابل سایت نادیده گرفته میشوند، به معنای ارجاعدهنده بدون توجه به خط مشی وب سایت، همیشه برای درخواست های متقابل سایت کوتاه می شود. |
لبه | پیشفرض، strict-origin-when-cross-origin است. |
سافاری | پیشفرض با برخی تفاوتهای خاص مشابه با strict-origin-when-cross-origin است. برای جزئیات بیشتر به جلوگیری از پیگیری ردیابی پیشگیری مراجعه کنید. |
بهترین شیوه ها برای تنظیم خط مشی ارجاع دهنده
راه های مختلفی برای تنظیم سیاست های ارجاع دهنده برای سایت شما وجود دارد:
- به عنوان یک هدر HTTP
- در HTML شما
- از جاوا اسکریپت بر اساس هر درخواست
می توانید خط مشی های مختلفی را برای صفحات، درخواست ها یا عناصر مختلف تنظیم کنید.
هدر HTTP و عنصر متا هر دو در سطح صفحه هستند. ترتیب اولویت برای تعیین خط مشی مؤثر یک عنصر به شرح زیر است:
- خط مشی سطح عنصر
- خط مشی سطح صفحه
- پیش فرض مرورگر
مثال:
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
ارسال شده را نشان میدهد.
کدام خط مشی را باید برای وب سایت خود تعیین کنید؟
ما قویاً توصیه میکنیم که به صراحت یک خطمشی تقویتکننده حفظ حریم خصوصی مانند strict-origin-when-cross-origin
(یا سختتر) تنظیم کنید.
چرا "صراحتا"؟
اگر خطمشی ارجاعدهنده تنظیم نکنید، از خطمشی پیشفرض مرورگر استفاده میشود—در واقع، وبسایتها اغلب به پیشفرض مرورگر موکول میکنند. اما این ایده آل نیست، زیرا:
- مرورگرهای مختلف خطمشیهای پیشفرض متفاوتی دارند، بنابراین اگر به پیشفرضهای مرورگر متکی باشید، سایت شما در بین مرورگرها بهطور قابل پیشبینی رفتار نمیکند.
- مرورگرها پیشفرضهای سختگیرانهتری مانند
strict-origin-when-cross-origin
و مکانیسمهایی مانند برش ارجاعدهنده برای درخواستهای مبدا متقاطع را اتخاذ میکنند. انتخاب صریح خط مشی افزایش حریم خصوصی قبل از تغییر پیشفرضهای مرورگر به شما امکان کنترل میدهد و به شما کمک میکند آزمایشها را هر طور که میخواهید انجام دهید.
چرا strict-origin-when-cross-origin
(یا سختگیرتر)؟
شما به خط مشی ای نیاز دارید که ایمن، تقویت کننده حریم خصوصی و مفید باشد. معنای "مفید" بستگی به آنچه از ارجاع دهنده می خواهید دارد:
- ایمن : اگر وب سایت شما از HTTPS استفاده می کند ( اگر نه، آن را در اولویت قرار دهید )، نمی خواهید URL های وب سایت شما در درخواست های غیر HTTPS درز کند. از آنجایی که هر کسی در شبکه می تواند این موارد را ببیند، درز اطلاعات کاربران شما را در معرض حملات شخص در وسط قرار می دهد. خطمشیهای
no-referrer-when-downgrade
،strict-origin-when-cross-origin
،no-referrer
وstrict-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 کامل را به اشتراک نمی گذارند، حتی برای درخواست های با مبدا یکسان. اگر به 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" />
یا سمت سرور، برای مثال در 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'});
چه چیز دیگری را باید در نظر بگیرید؟
خط مشی شما باید به وب سایت و موارد استفاده بستگی داشته باشد که توسط شما، تیم و شرکت شما تعیین می شود. اگر برخی از URL ها حاوی داده های شناسایی یا حساس هستند، یک خط مشی محافظتی تنظیم کنید.
بهترین روش ها برای درخواست های دریافتی
در اینجا چند دستورالعمل برای اینکه اگر سایت شما از URL ارجاع دهنده درخواست های دریافتی استفاده می کند، چه کاری باید انجام دهید.
از داده های کاربران محافظت کنید
Referer
میتواند حاوی دادههای خصوصی، شخصی یا شناسایی باشد، بنابراین مطمئن شوید که با آن رفتار میکنید.
ارجاع دهنده های ورودی می توانند {referer-can-change} را تغییر دهند
استفاده از ارجاع دهنده از درخواست های متقاطع ورودی دارای چند محدودیت است:
- اگر کنترلی بر اجرای فرستنده درخواست ندارید، نمی توانید در مورد سرصفحه
Referer
(وdocument.referrer
) که دریافت می کنید فرضیاتی داشته باشید. ارسال کننده درخواست ممکن است تصمیم بگیرد که در هر زمان به یک خط مشیno-referrer
یا به طور کلی تر به یک خط مشی سختگیرانه تر از آنچه قبلاً استفاده می کرد تغییر دهد. این بدان معنی است که شما داده های کمتری ازReferer
دریافت می کنید. - مرورگرها به طور فزاینده ای از Referrer-Policy
strict-origin-when-cross-origin
به طور پیش فرض استفاده می کنند. این بدان معناست که اگر سایت فرستنده خطمشی تنظیم نشده باشد، اکنون ممکن است به جای URL ارجاعدهنده کامل، در درخواستهای ورودی متقاطع، فقط مبدا را دریافت کنید. - مرورگرها ممکن است نحوه مدیریت
Referer
را تغییر دهند. به عنوان مثال، برخی از توسعهدهندگان مرورگر ممکن است تصمیم بگیرند همیشه ارجاعدهندهها را به مبدا در درخواستهای فرعی منبع متقاطع برش دهند تا از حریم خصوصی کاربر محافظت کنند. - سرصفحه
Referer
(وdocument.referrer
) ممکن است حاوی داده های بیشتری از آنچه شما نیاز دارید باشد. به عنوان مثال، ممکن است یک URL کامل داشته باشد زمانی که شما فقط می خواهید بدانید که آیا درخواست متقاطع است یا خیر.
گزینه های جایگزین برای Referer
ممکن است لازم باشد گزینه های جایگزین را در نظر بگیرید اگر:
- یکی از ویژگی های ضروری سایت شما از URL ارجاع دهنده درخواست های متقابل دریافتی استفاده می کند.
- سایت شما دیگر بخشی از URL ارجاع دهنده مورد نیاز خود را در یک درخواست متقاطع دریافت نمی کند. این زمانی اتفاق میافتد که فرستنده درخواست خطمشی خود را تغییر دهد یا زمانی که خطمشی تنظیم نشده باشد و خطمشی پیشفرض مرورگر تغییر کند (مانند Chrome 85 ).
برای تعریف گزینه های جایگزین، ابتدا تجزیه و تحلیل کنید که از چه بخشی از ارجاع دهنده استفاده می کنید.
اگر فقط به منبع نیاز دارید
- اگر از ارجاع دهنده در اسکریپتی استفاده می کنید که دسترسی سطح بالایی به صفحه دارد،
window.location.origin
یک جایگزین است. - در صورت وجود، سرصفحههایی مانند
Origin
وSec-Fetch-Site
به شما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
به عنوان جایگزین استفاده کنید. این ممکن است اطلاعاتی را که برای اهداف اشکال زدایی به روشی ساده تر و بدون نیاز به تجزیه ارجاع دهنده نیاز دارید به شما بدهد.
پرداخت ها
ارائهدهندگان پرداخت ممکن است به عنوان 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 به یک خطمشی پیشفرض جدید، این رفتار را تغییر نمیدهد.
نتیجه گیری
خطمشی ارجاعدهنده حفاظتی راهی عالی برای دادن حریم خصوصی بیشتر به کاربرانتان است.
برای کسب اطلاعات بیشتر در مورد تکنیک های مختلف برای محافظت از کاربران خود، به مجموعه ایمن و ایمن ما مراجعه کنید
منابع
- درک "همان سایت" و "همان منبع"
- عنوان امنیتی جدید: Referrer Policy (2017)
- Referrer-Policy در MDN
- سرصفحه ارجاع: نگرانی های حفظ حریم خصوصی و امنیتی در MDN
- تغییر کروم: پلک زدن قصد پیاده سازی
- تغییر کروم: پلک زدن قصد ارسال
- تغییر کروم: ورود وضعیت
- تغییر کروم: پست وبلاگ بتای 85
- پیوند ارجاع دهنده رشته GitHub: کاری که مرورگرهای مختلف انجام می دهند
- Referrer-Policy Spec
با تشکر فراوان برای مشارکت و بازخورد به همه داوران - به ویژه Kaustubha Govind، David Van Cleve، Mike West، Sam Dutton، Rowan Merewood، Jxck، و Kayce Basques.