Defaults.Exposed › Виправлення › Referrer-Policy

Як виправити Referrer-Policy

Referrer-Policy — це однорядкова інструкція, яку ваш сайт передає браузеру кожного відвідувача, контролюючи, скільки вашої веб-адреси мандрує з ними, коли вони натискають посилання на інший сайт. Без неї повна адреса сторінки, на якій вони були — пошукові запити, номери облікових записів, посилання для скидання, внутрішні шляхи — тихо передається наступному сайту, на який вони потрапляють, включно з рекламодавцями, аналітичними компаніями та будь-ким ще, на кого веде посилання.

Висновок для вашого бізнесу: Кожен раз, коли відвідувач натискає вихідне посилання, рекламу або спільний ресурс, їхній браузер може передати повну адресу вашої сторінки адресату — а якщо ваші адреси містять пошукові запити, ідентифікатори клієнтів, номери замовлень або одноразові посилання, ви витікаєте дані клієнтів до третіх сторін, яких не контролюєте. Це проблема захисту даних, яку регулятори сприймають серйозно, мовчки порушена обіцянка конфіденційності та оцінювана прогалина, яку служба безпеки клієнта позначить під час перевірки.

Що це може вам коштувати

• Клієнт заповнює форму або виконує пошук, потім натискає вихідне посилання або рекламу — і адреса сторінки, разом з тим, що вони ввели, передається прямо рекламодавцю або аналітичній фірмі, якій ви ніколи не мали наміру це передавати.
• Посилання для скидання пароля та підтвердження облікового запису іноді містять секретний токен у веб-адресі; без цього заголовка натискання будь-якого посилання на цій сторінці може передати всю адресу — разом з токеном — зовнішньому сайту.
• Приватні внутрішні шляхи сторінок (адміністративні зони, сторінки лише для клієнтів, рівні цін, посилання на документи) розкриваються кожній третій стороні, через яку клікають ваші відвідувачі, передаючи конкурентам і шпигунам карту вашого сайту, яку вони ніколи не повинні бачити.
• Огляд безпеки клієнта або аудит конфіденційності сканує ваш сайт, бачить відсутню Referrer-Policy і фіксує це як збій мінімізації даних — знахідка, яка може призупинити контракт або сертифікацію.
• Персональні дані потрапляють до обробників, з якими у вас немає угоди, перетворюючи п'ятихвилинне недбальство на звітний витік захисту даних.

Чому це важливо. Браузери, якщо їх не обмежити, є балакучими: за замовчуванням вони повідомляють наступний сайт, звідки щойно прийшов відвідувач, часто включно з повною адресою сторінки. Для сайту-брошури це може бути нешкідливим, але щойно ваші адреси містять щось особисте — пошуковий запит, ідентифікатор замовлення, email у посиланні, приватний шлях — це за замовчуванням тихо витікає до зовнішніх сторін. Referrer-Policy — це єдине налаштування, що каже браузерам припинити надмірний обмін. Це оцінювана перевірка у вашій картці результатів, що варта реальних балів, вона безпосередньо відображає обов'язки мінімізації даних за законодавством про конфіденційність, і це один зі стандартних заголовків безпеки, який будь-який професійний огляд очікує знайти.

Що це таке — простими словами

Кожен раз, коли відвідувач на вашому сайті натискає посилання на інший сайт — вихідне посилання, банерну рекламу, «поділитися», або навіть шрифт чи зображення, завантажені звідкись іще — їхній браузер тихо додає замітку про те, з якої вашої сторінки вони прийшли. Ця замітка і є referrer (посилальник).

Використаний розумно, referrer нешкідливий і навіть корисний: саме так інші сайти знають, що трафік прийшов від вас, і саме він живить багато чесної аналітики. Заковика у поведінці за замовчуванням. Без управління браузер не просто каже «вони прийшли з вашого-бізнесу.com» — він часто передає повну адресу точної сторінки, включно з усім після доменного імені. А веб-адреси несуть набагато більше, ніж люди усвідомлюють: пошукові запити, набрані на вашому сайті, номери замовлень і облікових записів, шлях до приватної сторінки лише для членів, навіть одноразові секретні токени у посиланнях для скидання пароля та підтвердження.

Referrer-Policy — це єдина інструкція, яку ваш сайт надсилає браузеру, що каже, скільки цієї замітки йому дозволено передавати. Ви можете сказати йому передавати лише ваше доменне ім’я, лише іншим сторінкам на вашому власному сайті або взагалі нічого. Подумайте про це як різницю між тим, що ви передаєте незнайомцю повну домашню адресу з вашим щоденним розкладом, проти того, щоб просто сказати їм, у якому місті ви живете.

Це один із невеликого сімейства «заголовків безпеки» — короткі інструкції, які ваш сайт дає браузеру кожного відвідувача. Це не змінює, як виглядає або працює ваш сайт. Це просто зупиняє браузер від надмірного обміну від вашого імені.

Що це може коштувати вам

Ось конкретні, повсякденні способи, якими відсутня або дозвільна Referrer-Policy завдає шкоди реальному бізнесу. Для жодного з них не потрібен хакер — вони відбуваються автоматично, щодня, у звичайному використанні.

• Витік пошуку. Клієнт шукає на вашому сайті щось чутливе — медичний продукт, послугу, пов’язану з боргами, порівняння конкурентів — і пошуковий запит потрапляє в адресу сторінки. Потім він натискає вихідне посилання або рекламу на цій сторінці результатів. Рекламодавець тепер отримує вашу адресу з пошуковим запитом у ній, дізнаючись точно, що шукав ваш клієнт. Ви ніколи не погоджувалися це передавати, і ви не можете взяти це назад.

• Розкрите посилання для скидання. Багато систем вкладають секретний одноразовий токен в адресу сторінок скидання пароля, підтвердження email або «магічного входу». Якщо ця сторінка містить будь-яке вихідне посилання або сторонній ресурс, повна адреса — разом з токеном — може бути передана зовнішньому сайту. У найгіршому випадку це передає третій стороні ключі від облікового запису.

• Карта сайту, яку ви роздали безкоштовно. Ваші внутрішні шляхи сторінок часто розкривають вашу структуру: /admin, /enterprise-pricing, /clients/acme, /downloads/private-report. Без цього заголовка кожен зовнішній сайт, через який клікають ваші відвідувачі, отримує ці шляхи. Конкуренти дізнаються ваші рівні ціноутворення і лінійки продуктів; зловмисники дізнаються, які сторінки атакувати.

• Небажані відносини обміну даними. Законодавство про конфіденційність очікує, що ви знаєте, куди йдуть персональні дані ваших клієнтів, і маєте угоду на місці. Витік адрес сторінок, що містять ідентифікатори клієнтів або адреси email, до рекламних мереж і аналітичних фірм — без угоди і без згоди — є саме тим видом неконтрольованого потоку даних, який перетворює рутинний аудит на знахідку, а знахідку — на звітний витік.

• Угода, що зависає на перевірці. Коли більший клієнт вивчає вас, відсутні стандартні заголовки безпеки — це швидка автоматизована відмітка. Бачення відсутньої Referrer-Policy каже їм, що базова гігієна конфіденційності ніколи не була налаштована — і цей висновок забарвлює все інше у огляді.

Що це насправді є

За замовчуванням браузери дотримуються поведінки, приблизно еквівалентної «strict-origin-when-cross-origin» в сучасних версіях — але ви не можете на це покладатися, бо старіші браузери, вбудовані webviews та певні конфігурації все ще можуть витікати більше. Єдиний спосіб бути впевненим — встановити політику явно. Коли ви це робите, ви обираєте одне правило з короткого списку. Ті, що мають значення:

• no-referrer — нічого не передавати. Наступний сайт не дізнається нічого про те, звідки прийшов відвідувач. Максимальна конфіденційність; може пригнічувати аналітику переходів.
• same-origin — передавати повну адресу лише коли відвідувач переміщується між сторінками вашого власного сайту; нічого не передавати зовнішнім сайтам.
• strict-origin-when-cross-origin — рекомендований стандарт. У межах вашого власного сайту передається повний шлях; зовнішнім сайтам передається лише ваше просте доменне ім’я (і нічого взагалі при переході зі захищеної сторінки на незахищену). Зовнішні сторони дізнаються, що трафік прийшов від вас, але ніколи не приватні деталі після вашого домену.
• origin — завжди передавати лише ваше доменне ім’я, навіть у межах вашого власного сайту.

І два значення, яких слід уникати, бо картка результатів вважає їх не кращими, ніж відсутність заголовку взагалі:

• unsafe-url — передавати повну адресу всім, завжди. Це найгірший випадок в одному слові.
• no-referrer-when-downgrade — стара стандартна поведінка браузера; вона все одно надсилає повну адресу іншим захищеним сайтам, витікаючи все описане вище.

Як виглядає «добре»: заголовок Referrer-Policy присутній і встановлений на обмежувальне значення — для більшості компаній strict-origin-when-cross-origin. Це підтримує аналітику переходів при роботі, забезпечуючи, що нічого після вашого доменного імені ніколи не потрапляє до зовнішнього сайту.

Як це виправити (безкоштовно, близько 5 хвилин)

Передайте цей розділ вашому IT-фахівцю, веб-розробнику або підтримці хостингу — виправлення безкоштовне, це єдиний рядок, і це не зламає ваш сайт. Тут немає ризикованого розгортання: на відміну від деяких налаштувань безпеки, розумна Referrer-Policy не може зупинити ваші посилання або сторінки від роботи. Вона лише обрізає те, що передається іншим сайтам.

Мета: встановити заголовок відповіді Referrer-Policy зі значенням strict-origin-when-cross-origin (або суворішим значенням, якщо ви хочете передавати ще менше).

Cloudflare (без коду — найпростіше, якщо ви його використовуєте): Dashboard → ваш домен → Rules → Transform Rules → Modify Response Header → Create rule → Set static → Header name Referrer-Policy, value strict-origin-when-cross-origin → застосувати до всіх вхідних запитів → Deploy.

Google Workspace / Microsoft 365: вони керують вашою поштою, а не вашим сайтом, тому заголовок встановлюється там, де ваш сайт фактично розміщений (ваш веб-хост, CDN або сервер) — не в Workspace або 365 admin. Визначте хост і використовуйте відповідний варіант нижче.

Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache (у конфігурації сайту або .htaccess):

Header always set Referrer-Policy "strict-origin-when-cross-origin"

IIS (web.config):

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express:

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

WordPress / звичайні хости: більшість керованих WordPress і спільних хостів дозволяють додавати заголовки відповіді через плагін безпеки, панель «headers» у панелі керування хостингом або за допомогою вищезгаданого фрагменту .htaccess. Якщо ви за Cloudflare, метод Cloudflare є найчистішим і застосовується скрізь одразу.

Після застосування: завантажте ваш сайт і повторно запустіть перевірку або використайте засоби розробника браузера (вкладка Мережа → натисніть основний документ → Response Headers), щоб підтвердити наявність Referrer-Policy: strict-origin-when-cross-origin.

Поширені помилки

• Встановлення дозвільного значення і припущення, що воно рахується. unsafe-url і no-referrer-when-downgrade обидва все ще витікають повну адресу. Картка результатів оцінює їх як нуль — ідентично відсутності заголовку. Якщо заголовок присутній, але балів немає, причина майже завжди в цьому.
• Встановлення лише на головній сторінці. Заголовок повинен надсилатися на кожній сторінці, бо витоки відбуваються на сторінках результатів пошуку, облікового запису і скидання — не на головній. Встановлюйте це на рівні сервера, CDN або Cloudflare, щоб воно застосовувалося по всьому сайту автоматично.
• Встановлення лише у HTML-тегах <meta>. Тег <meta name="referrer"> працює в деяких випадках, але не у всіх, і його легко зробити непослідовним по сторінках. Встановлення його як правильного заголовка відповіді (методи вище) — надійний підхід.
• Дозволяти одному шару перевизначати інший. Якщо і ваш сервер-джерело, і ваш CDN встановлюють заголовок з різними значеннями, результат може бути непередбачуваним. Оберіть одне місце для управління ним — зазвичай CDN або Cloudflare, якщо у вас є — і тримайте решту послідовною.
• Ставитись до нього як до замінника того, щоб не класти дані в URL. Заголовок обмежує шкоду, але більш чиста довгострокова звичка — не вкладати секрети і персональні дані у веб-адреси взагалі. Використовуйте заголовок зараз; підніміть питання гігієни URL з вашим розробником як наступний крок.

FAQ