Meta name referrer content always

Автор: Сайрус Шепард (Cyrus Shepard) — сотрудник команды Moz, ранее занимался исключительно вопросами поисковой оптимизации, сегодня в большей степени сосредоточен на создании продвигающего контента и технических аспектах его распространения и отслеживания статистики. Сайрус Шепард не раз возглавлял кампании по продвижению в интернете крупных и авторитетных брендов.

Попытка поисковых систем сделать интернет более безопасным и, как следствие, вынужденный переход многих сайтов на использование протокола шифрования HTTPS, внесли ряд серьёзных изменений в повседневную деятельность вебмастеров и оптимизаторов. Помимо решения вопросов безопасности соединения, перевод сайтов на HTTPS сулил их владельцам и маркетологам дополнительные преимущества, с точки зрения поискового продвижения.

Усилия представителей поиска возымели эффект, и сегодня мы можем наблюдать в результатах поисковой выдачи все большее и большее число ресурсов, использующих протокол HTTPS. Результаты недавнего исследования MozCast свидетельствуют, что на сегодняшний день около 20% результатов, показывающихся на первой странице выдачи Google, ведут на защищённые страницы:

К сожалению, использование протокола HTTPS сайтами имеет и свои, довольно весомые недостатки. Переход с HTTP на HTTPS доставил массу трудностей и технических неудобств интернет-маркетологам.

Первая проблема была связана с вынужденным применением кода ответа сервера 301 для перенаправления пользователей на безопасные версии страниц. Исторически данный тип перенаправлений ассоциировался у профессионалов отрасли с потерей ссылающейся страницей ссылочного веса, как минимум на 15%, что само собой может привести к снижению её видимости в результатах поисковой выдачи. Одна только эта проблема способна перечеркнуть все обещанные Google преимущества.

Эксперт отрасли Росс Хадженс (Ross Hudgens) идеально сформулировал проблему в своём твите: «"HTTPS как фактор ранжирования". Перевод с HTTP на HTTPS с применением 301 редиректа ведет к потере ссылочного веса. Выгода от перехода на HTTPS — незначительная, зато потеря ссылочного веса – ощутима. Трафик теряется».

"HTTPS is a ranking factor". 301 HTTP to HTTPS. Links lose equity through 301. HTTPS gain is less than amount of equity loss. Lose traffic.

Тем не менее, на пике событий многие оптимизаторы радостно делились историями успешного перевода своих ресурсов на безопасный протокол HTTPS, рапортуя о том, что видимость безопасных страниц в SERP Google даже улучшилась. Вскоре использование HTTPS на сайте было официально объявлено сигналом ранжирования для Google и даже вошло в список факторов ранжирования по итогам 2014 года. Трудно поверить, но перевод сайта на HTTPS дает чрезвычайно кратковременный эффект. Впоследствии позиции ресурса в выдаче и вовсе снижаются. Так перевод блога Moz на протокол шифрования, призванный обеспечить большую конфиденциальность работы с ресурсом для зарегистрированных пользователей, привел к снижению видимости страниц в результатах органической выдачи Google на 8-9%.

Проблема номер два оказалась куда более существенной. Она-то и стала основной темой этой статьи. В результате массовой миграции сайтов на безопасный протокол, вебмастера столкнулись с проблемой полной или частичной потери данных о переходах пользователей на сайты с других источников. Традиционная схема передачи трафика исторически сводилась к следующему: когда один сайт передает трафик другому, информация об источнике перехода фиксируется системой аналитики ресурса. Это – один из важнейших типов данных, который позволяет вебмастерам отслеживать источники переходов и анализировать входящий трафик.

SEO-специалисты исторически использовали данные о переходах для создания стратегий продвижения своих ресурсов. Часто специалисты перепроверяли данные о переходах с различных источников, чтобы получить более подробную информацию о качестве входящего трафика.

Недавний скачок рефспама на страницы сайтов (автоматических обращений к сайту с подстановкой нужного рефферера) – лишнее доказательство тому, что ситуацией успешно пользуются нечистые на руку оптимизаторы:

Когда трафик с сайтов, защищённых протоколом HTTPS, поступает на ресурсы, применяющие HTTP, реферальные данные не передаются, и вебмастеру становится невозможно определить, из каких источников он поступает.

Вот как выглядела статистика переходов на персональный блог автора данной статьи с ресурса Moz после перевода последнего на HTTPS:

Зачем нужен мета-тег «referrer»?

Поскольку решение проблемы традиционными методами становится затруднительным, приходится решать вопрос за счёт применения иных методов. Следует признать, что большинство интернет-маркетологов еще не слишком хорошо осведомлены о существовании альтернативных путей и возможностей отслеживания данных о входящем трафике. Выйти из ситуации, к примеру, помогает использование мета-тега «referrer», который появился несколько лет назад. Он позволяет контролировать процесс передачи реферальных данных. Мета-тег поддерживается всеми основными браузерами и передает данные о реферерах, согласно пользовательским настройкам. При этом трафик остается зашифрованным, а пользователи получают все преимущества от применения сайтом протокола HTTPS. Тем не менее, владелец ресурса получает возможность передавать данные о переходах на любые веб-сайты, включая те, которые до сих пор применяют протокол HTTP.

Как использовать мета-тег «referrer»?

Ниже представлены упрощенные инструкции по использованию мета-тега «referrer». Тем, у кого есть желание углубиться в тему подробнее, автор статьи рекомендует ознакомиться со следующим документом.

Полезными также могут оказаться и следующие ссылки:

Упомянутый выше мета-тег размещается в разделе HTML-страницы и способен принимать 5 различных значений. От них впоследствии будет зависеть то, насколько полную информацию о реферерах будут передавать сайту браузеры.

Типы значений могут быть следующими:

None: Никогда не передает реферальные данные:

None When Downgrade: Передает реферальные данные сайтам на HTTPS, в то время, как сайтам на HTTP данные не передаются.

Origin Only: Передает данные о хостах и поддоменах. При этом URL , как правило, имеет следующий вид: https://moz.com/example.html would simply send https://moz.com (пример).

Origin When Cross-Origin: Передает полные данные о URL в случаях, когда настройка произведена по схеме №3 вне зависимости от того, какой протокол использует сайт HTTP или HTTPS.

Unsafe URL: Всегда передает полный URL реферера. Важно понимать, что данная настройка является наименее безопасной. Часть незашифрованных данных может быть передана. По умолчанию фрагменты URL , имя пользователя и пароли автоматически исключаются из URL-а.

Мета-тег в действии

Увидеть, как работает мета-тег «referrer», можно, совершив переход по следующей ссылке. Такое значение URL можно получить, если выбрать в качестве его настройки параметр «Origin». При такой настройке параметров тега данные о реферере передаются схеме: хост и поддомен. В данном случае в качестве итогового результата показывается следующий адрес сайта перехода: http://moz.com.

На практике данные аналитики до применения мета-тега «referrer» и после начала его использования выглядят так:

Чтобы упростить процедуру отслеживания и сделать её максимально безопасной, большинство представителей сайтов предпочитают использовать параметр «Origin» при настройке мета-тега «referrer». Однако у данного подхода есть свои недостатки. Один из главных минусов заключается в том, что при настройке тега соответствующим образом для ресурса Moz, аналитика системы AdRoll, которую ресурс использует для ретаргетинга объявлений, перестает работать. В своей аналитике AdRoll использует данные Moz о реферальных переходах, в то же время параметр «Origin» подразумевает, что единственный URL, с которого перешел пользователь был https://moz.com. Таким образом, аналитика становится недействительной.

Заключительные выводы

Полюбить мета-тега «referrer» можно только за то, что он хоть каким-то образом позволяет передаваться по сети данным о переходах с защищенных сайтов. Так, что жизнь не останавливается!

Мета-тег помогает вебмастерам и оптимизаторам точнее понимать, с каких конкретно ресурсов на их сайты поступает целевой трафик. Наконец, применение мета-тега «referrer» способствует укреплению взаимосвязей между ресурсами, обмену данными, является немаловажным аспектом в формировании ссылочных стратегий и в целом способствует оптимизации сайта.

Лучшее от AliExpress:

Полезный META тег Referrer Policy для HTTPS сайта.

Не очень понятно, зачем и кому именно выгодна концепция тотального перевода сайтов на https протокол. Но похоже, поезд уже ушёл, и поделать с этим ничего нельзя.

Поисковые гиганты уровня Гугла откровенно лоббируют https протокол документов в своей поисковой выдаче. Браузеры в адресной строке стебутся и глумятся, как могут, над «небезопасными» сайтами. В SEO нише все новости подряд про преференции сайтов под SSL сертификатами, и так далее.

И добро бы, будь это просто новостной фон.
Прочли и забыли.

Но на деле наши хостеры уже давно и всем подряд выдают SSL-сертификаты типа DV (domain validation), причём насильно. Пусть самого начального уровня (бесплатные), и на короткий срок, но автоматически продлеваемые. А это уже не досужие разговоры, и с этим следует как-то определиться.

Наблюдения за Гуглом.

Местный автор поначалу относился к SSL вакханалии полностью индифферентно. Но, раз того требует великий Гугл, нехай страницы авторизации и всяких там форм обратной связи всегда будут под https протоколом, а все остальные — как уж в адресной строке сложилось. Хоть так, хоть этак, ибо используемый автором движок позволяет в конфигах задать URL морды сайта в зависимости от того, как протокол написан в адресной строке текущего юзера:

‘base’ => ‘http’ .((isset( $_SERVER [ ‘HTTPS’ ]) and $_SERVER [ ‘HTTPS’ ]== ‘on’ ) ? ‘s’ : » ). ‘://lasto.com/’ ,

Это удобно — сайт работает параллельно как в http, так и https протоколах. С одной стороны, не особо понятно, зачем рядовому сайту вообще нужен https, так что специально мы переходить на этот протокол не стали. Но, раз уж Гугл сильно хочет видеть все страницы с вводом персональных данных под шифрованием, пусть видит.

Никто не предполагал, что далее случится странное.

Местный автор заметил, что спустя некоторое время индексирующий бот Гугла, обходя его сайт, видел на странице авторизации все ссылки в навигации в протоколе https (в соответствии с логикой, указанной выше PHP оператором, все внутренние ссылки строятся относительно морды сайта, заданной вот так), и последовательно заменял в выдаче у всех этих документов в URL-е протокол на безопасный.

Понятно, что произошло дальше.

Заходя впоследствии на «безопасные» версии этих документов, индексирующий бот получал все внутренние ссылки с них тоже исключительно в https протоколе, и спустя краткое время в поисковой выдаче практически не осталось http документов. Ну разве что редиректы всякие, ведущие наружу.

Фактически Гугл осознанно заместил в поисковой выдаче http документы их https версиями, хотя на сайте они полностью равноправны — можно было документы открывать хоть так, хоть этак.

А вот это уже знак. Наверное, надо теперь подвергнуть легалайзу действия Гугла, и полностью отказаться от http версии сайта в пользу https. Тем паче, что переиндексация фактически уже случилась, причём естественным образом, исключительно с помощью индексирующего бота (местный автор, конечно же, не занимается ахинеей типа построение карты сайта и тому подобными извращениями).

Кстати, Яндекс ничего подобного делать не стал, и по запросу «site:lasto.com» выдавал документы строго в http протоколе. При этом никакой директивы Host в файле роботса прописано не было, в Яндекс.Вебмастере местный автор никогда даже не регистрировался, и зеркало сайта или предпочтительный протокол в нём не настраивал.

Перевод сайта на HTTPS протокол.

Поскольку всякий вебмастер приучен сразу и правильно понимать намёки великого Гугла, который из каких-то соображений однозначно выбрал «правильный» протокол, было бы логично теперь избавиться от одной из версий ресурса в пользу другой. Что делается явной записью в конфиге вместо «странного» PHP оператора:

Всё, морда сайта у нас теперь задана во всей её конкретности, не допускает вольного толкования, и осталось лишь принудительно перекинуть http трафик в https протокол. Что делается силами .htaccess файла, и в простейшем случае выглядит так:

RewriteEngine On
RewriteCond % < SERVER_PORT >!^ 443 $
RewriteRule .* https : //%% [R=301,L]

Скорее всего, первая строчка в .htaccess файле уже имеется, её второй раз писать не надо. А две оставшихся размещаются до рулёзов самого движка.

Ну и можно ещё заглянуть в файл robots.txt, если он у Вас есть. Специально для Яндекса там обычно прописана директива «Host:», в которой принято указывать зеркало сайта (есть www. в имени домена, или нет). Этой же директивой задаётся и желаемый протокол — видимо, иным образом донести до Яндекса своё отношение к выбору протокола сайта не получается.

В принципе, перечисленными выше тремя нехитрыми действиями дело и ограничивается. Если у Вас, конечно, правильный движок, который автоматически перестроит все внутренние ссылки сайта, попутно сделав их абсолютными, и в желаемом протоколе.

А теперь неприятное. Недостатки HTTPS протокола.

Замедление загрузки сайта.

Нужно быть готовым к тому, что «обычный» трафик ходит заметно быстрее, чем «защищённый». Ибо во втором случае есть дополнительное обращение к третьей стороне (поставщик SSL сертификата), что занимает лишнее время перед тем, как сайт начнёт загружаться. И эта задержка заметна на глаз.

Ошибка SSL: Потеря доступа к сайту.

Есть определённая вероятность того, что бесплатные начальные сертификаты (обычно от «Let’s Encrypt»), выпускаемые всего на три месяца, могут быть не продлены вовремя. В результате сайт не открывается, на экране ошибка доступа по причине недействительности SSL сертификата. Что печалит.

Отзыв SSL сертификата, Роскомнадзор.

Как мы теперь все прекрасно понимаем, не очень-то вменяемый Роскомнадзор вполне может в любой момент заблокировать любую подсеть IP адресов любой ёмкости, причём по любой надуманной причине. Если в тех айпишниках вдруг окажется инфраструктура удостоверяющего центра, все сайты с SSL сертификатом от него тут же отваливаются, и больше ничего не показывают.

Такое уже разок было (Роскомнадзор заблокировал Comodo, а заодно и себя, ибо сам в тот момент имел SSL сертификат от Comodo). И много раз ещё повторится в разных вариантах.

Причём ситуация намного хуже, чем может показаться.

Сайты под «безопасным» протоколом по факту более централизованы, чем их дикие собратья. Ибо сертификат сайта может быть легко отозван (правда, по решению суда).

Но легче и проще ни в какой суд вообще не обращаться, а выпустить (и навязать его всем пользователям) какой-нибудь «Яндекс-браузер», который, как и любой другой браузер, тоже имеет право отзывать SSL сертификат как отдельного сайта, так и вообще все сертификаты, выпущенные любым удостоверяющим центром.

Пока такого ещё ни разу не делалось, но в нужный момент Вы в одночасье лишитесь доступа к «неправильным» сайтам — браузер со стрингами на логотипе впаривается всеми силами и каждому подряд не просто так.

Наличие у сайта SSL сертификата искажает статистику исходящего с него трафика. Вот тут будьте внимательны.

Все мы помним, как Гугл поломал детектирование поисковых запросов, просто переведя свой поиск на https протокол. Ибо наши сайты в большинстве своём тогда были «беззащитные», а им по уставу не положено видеть параметры в URL-ах ссылающегося на них сайта. А именно в тех параметрах прописан поисковый запрос.

Самый последний пункт нам, как вебмастерам, очень интересен. И, видимо, настала пора познакомиться с такой сущностью, как Referrer Policy. Собственно, это и является истинной темой нашей сегодняшней встречи.

МЕТА тег «Referrer Policy»

Это относительно свеженький стандарт, от 2017 года. Но уже популярный.
На языке первоисточника доступен тут.

Встраивается в сайт простейшим образом, в виде тега секции header

meta name = "referrer" content = "*" >

Вместо звёздочки можно и нужно писать разные сущности, и в зависимости от вписанной сущности внешний сайт, на который ссылается страница с таким вот МЕТА тегом в коде, либо будет знать в точности источник трафика, либо только его домен, либо не узнает вообще ничего.

Понимая, что при этом как ссылающийся сайт, так и получающий трафик по ссылке, могут работать в любом из протоколов (http или https), мы получим множество вариантов, которые стоит изучать в отдельности.

no-referrer

Самый убийственный вариант, когда сведения о ссылающейся странице (так называемый «реферер») к получателю трафика вообще не передаются. Даже если получатель трафика — этот же самый сайт (переход по внутренней ссылке в пределах сайта).

Трудно представить, зачем такой вариант вообще предусмотрен. Видимо, для истинных параноиков. Либо когда вебмастер вообще не анализирует перемещение посетителей по ресурсу, и не желает сообщать внешним сайтам, с какого именно URL-а к нему переходит серфер — для внешнего сайта это будет так называемый «букмарковый трафик».

Этот вариант МЕТА тега совершенно обязательно размещать на всех страницах всевозможных систем тикетов, особенно бездарно сконструированных. Местный автор часто видит в своей статистике переходы с тикетовых систем разных хостеров, причём при клике в линк можно читать этот чужой тикет, без всякой авторизации вообще.

Это, конечно, эпический фейл и фиаско. Если уж скрипт системы тикетов написан идиотом, хотя бы добавьте данный МЕТА-тег на все страницы тикетов в указанном выше виде. Что, конечно, совсем не поможет, если браузер клиента старый, и этот тег не разумеет.

no-referrer-when-downgrade

Реферер не передаётся от https к http сайту, и передаётся во всех остальных случаях. Причём это справедливо и для варианта общения сайта с самим собой, но в разных протоколах.

С большой степенью вероятности отсутствие данного МЕТА-тега вообще приведёт к такому же эффекту.

same-origin

Очень интересный вариант, когда реферер передаётся только внутри собственного сайта, при переходе между его документами. Но только в случае, когда этот сайт работает по https протоколу. В любом другом случае реферера просто нет.

Как применять, понятно. Данный вариант предназначен для накопления статистики перемещения между внутренними документами сайта посредством какой-либо метрики, но при этом сайт ничего не сообщает об URL-ах своих документов прилинкованным оттуда внешним сайтам.

origin

На какой бы сайт не ссылалась страница с таким тегом, в качестве реферера будет виден лишь домен сайта. Документ в URL-е не передаётся. Протокол принимающего трафик сайта безразличен.

Обратите внимание, это ничем не отличается от банального рефспама, когда Ваш ресурс обильно пингуют с рефером в виде морды сайта — совершенно понятно, что исходящую ссылку на Вас прямо с морды никто никогда не ставит, и это именно рефспам, который местный автор в своих продуктах (статмодуль) вообще игнорирует, заключая всех этим занимающихся в табличку попингуев.

Так что не будет хорошей идеей употреблять сей МЕТА тег именно в таком написании. Да и метрики откажутся работать — внутренние переходы не отследить.

strict-origin

То же самое, но уже играет роль иерархия протоколов. При переходе с https сайта на http (в том числе и в пределах одного домена) реферер не передаётся. Во всех остальных случаях в качестве реферера фигурирует морда сайта, а не его конкретный документ.

origin-when-cross-origin

Только при переходе внутри сайта реферером является ссылающаяся страница, во всех остальных случаях это будет морда сайта.

То же самое, что и четвёртый вариант, но тут метрика должна быть работоспособна.

strict-origin-when-cross-origin

Более строгий вариант- то же, что и предыдущее, но если ссылающийся сайт в https протоколе, а прилинкованный — в http, то реферер вообще пропадает.

unsafe-url

Реферер передаётся в любом случае.

Как видим, по дефолту (когда мы переводим свой сайт с http на https протокол) у нас автоматически реализуется второй вариант, а сайты в http протоколе, на которые мы по-прежнему ссылаемся, перестают воспринимать нас в качестве источника трафика — в реферере это просто не отражено.

Конечно, это ненормальная ситуация.

Поэтому всё-таки имеет смысл вписать в шаблон дизайна сайта МЕТА-тег в самом последнем варианте его написания. Чтобы любой сайт имел возможность наблюдать в своей статистике все ссылающиеся на него ресурсы в рамках максимально демократичной процедуры «unsafe-url Referrer Policy».

Примечание.

Естественно, реферер (информация об источнике трафика) переносится от сайта к сайту силами браузера посетителя, и браузер либо знаком с «Referrer Policy», либо не понимает, чего от него хочет хитрый МЕТА-тег.

Однако все современные браузеры этому тегу тщательно обучены, и слушаются его. Если же понимания тега у браузера нет, вступает в силу правило номер два в списке выше, являющееся действием по умолчанию.

Рекомендации.

Как видим, МЕТА-тег «Referrer Policy» хоть и не отличается разнообразием вариантов (их номенклатуру можно было бы и расширить), тем не менее позволяет работать с реферерами по-разному, в зависимости от протокола сайта. Это ценное свойство, особенно если можно открыть сайт хоть «безопасно», хоть «не безопасно».

Более полезна способность тега ограничить передачу реферера либо совсем, либо только внешним сайтам. Этим следует обязательно пользоваться на страницах, требующих секьюритетности — всякие там личные кабинеты, тикеты, и тому подобное.

Правда, если сервисы написаны по уму (например, URL всех страниц сервиса одинаковый, ибо данные передаются исключительно через POST, а GET параметры не используются вообще), тегу особо и нечего защищать. Разве что сам факт наличия исходящей ссылки.

Тем не менее, тег однозначно полезный, знать про него надо.
Как и вовсю пользоваться им.

Другие статьи категории «Вебмастеру на заметку»

Видимо, случилось прекращение роста в доменной зоне RU.

Какие элементы сайта сегодня можно потерять.

Антипопингуйство сегодня, и один из вариантов борьбы с ним.

№ 1 Referrer Policy применительно к движку местного автора.

Стоит знать, что так называемая Нана при передаче любой информации посредством форм, построенных на фреймворке движка, обязательно контролирует источник данных. Тот самый реферер.

Если вдруг окажется, что он не определён, или не совпадает с ожидаемым, форма тупо не сработает. Да ещё и будет ругаться.

Поэтому Вы не можете полностью отключить реферер, либо исказить его (отдавать реферер, совпадающий с мордой сайта, а не реальным документом, отправившим данные, как это предусмотрено некоторыми из политик).

Зато определённый интерес представляет политика «same-origin»

Под ней сайт будет принимать данные только в том случае, если он открыт в https протоколе, то есть когда взаимодействие с пользователем или админом происходит под шифрованием, безопасным образом. А в ином случае данные не примутся.

№ 2 Директива Хост для Яндекса не нужна

20 марта сего года Яндекс в блоге для вебмастеров сообщил, что отказывается от директивы "Host" в пользу 301 редиректа, и разрешил удалить её из роботс. Так окончились пятнадцать лет борьбы со спецификацией.

Спасибо за информацию.
Даже и не знал 🙂

Воистину, всё, что «хочет от тебя странного», должно быть проигнорировано просто на автомате.

Если я нажимаю на ссылку на сайте, заголовок http referer указывает на исходную страницу, с которой я перешла на целевую страницу:

Заголовок широко используется в маркетинге, чтобы проанализировать, откуда пришли посетители сайта. Также он применяется для сбора статистики о поведении посетителей и трафике.

Но этот заголовок может нести потенциальную угрозу безопасности, если в нем передается слишком много информации.

В спецификации RFC2616 о referer говорится, что: « Клиенты не должны включать поле заголовка Referer в незащищенный HTTP-запрос , если исходная страница использовала защищенный протокол «. То есть, если наш запрос ведет с HTTPS-страницы на HTTP , заголовок Referer не должен включаться.

Тем не менее, стандарты RFC не являются обязательными, и данные могут быть считаны. Несколько лет назад Facebook имел серьезные проблемы, когда выяснилось, что иногда идентификатор инициирующей страницы передавался рекламодателям в заголовке referer, когда пользователь нажимал на объявление .

Кроме этого, когда трафик проходит между двумя HTTPS сайтами ( SSL становится все более распространенным ) RFC не требует, чтобы заголовок server http referer удалялся.

Метатег referrer

Потенциальным решением этих проблем может стать метатег referrer . Добавляя к исходной странице:

мы можем отредактировать заголовок referrer так, чтобы сайты видели, откуда пришел трафик. Но при этом предотвратить утечку конфиденциальных данных.

Список параметров для поля контента :

• no-referrer: не опускать заголовок referrer из запроса;
• no-referrer-when-downgrade: не пропустить заголовок referrer при переходе с HTTPS на HTTP ;
• origin: установить заголовок http referer таким образом, чтобы указать в нем только исходный сайт;
• origin-when-cross-origin: если запрос ведет на другой сайт или протокол, установить для заголовка referrer параметр origin ;
• unsafe-url: установить заголовок referrer таким образом, чтобы в нем передавалась полная информация исходного URL-адреса .

Независимо от того, между какими сайтами или протоколами осуществляется переход ( потенциальная угроза утечки данных ).

В качестве практического примера: если бы facebook реализовал этот тег следующим образом:

то, когда мистер Бобби Тейблз зашел бы на Facebook , URL-адрес его страницы выглядел бы так:

Когда он нажал на внешнюю ссылку и перешел на другой сайт, заголовок http referer выглядел бы так:

Это бы защитило его данные. Целевой сайт регистрирует, что к ним заходил посетитель с facebook , но его имя пользователя не было бы передано.

Google был первым, кто реализовал такую схему , чтобы якобы уменьшить время ожидания от ssl-сайтов . Хотя можно было бы предположить, что основной была задача показать клиентам, что их сайт является источником трафика.

Будьте осторожны

Применяется ли заголовок server http referer с новым мета тегом referrer или нет, в любом случае нужно использовать его с определенной степенью осторожности.

Referer-спам по-прежнему является проблемой. Злоумышленники могут настроить таргетинг на сайт с помощью специального заголовка referer , который сообщает аналитику его владельцу. Чтобы узнать, откуда пришел трафик, владелец ресурса может перейти по ссылке, ведущей на вредоносную веб-страницу.

Заголовок referer также открывает возможности для XSS-атак . Использовать заголовки в нелегальных целях просто, поэтому задействовать referer для авторизации или аутентификации крайне неосмотрительно.

Заголовок отсутствует, если

• пользователь вводит URL-адрес в адресной строке браузера;
• пользователь зашел на сайт через закладки;
• запрос ведет с протокола HTTPS на HTTP ;
• запрос ведет с протокола HTTPS на различные URL-адреса с протоколом HTTPS ;
• защитное программное обеспечение ( антивирус, брандмауэр и т.д. ) очистило запрос;
• прокси-сервер очистил запрос;
• плагин браузера очистил запрос;
• сайт был посещен программно ( например, с помощью curl ) без установки заголовка;
• это запрещает метатег referrer ;
• это разрешает метатег referrer это разрешает, но браузер его не поддерживает .

Для сайтов, которые задействуют заголовок http referer в рекламных кампаниях, его некорректное использование может стать проблемой. Правила прокси-серверов, разрешающие доступ для пользователей, переходящих с конкретных сайтов, формирует высокий риск того, что это не будет работать вообще ( в зависимости от браузера пользователя или локальной настройки ). И возникнут уязвимости для злоупотреблений заголовками.

Подводя итоги

Заголовок referer всегда был довольно неоднозначным, и на данный момент остается неоднозначным, хотя и в меньшей степени. Он может стать очень полезным инструментом для сбора данных о веб-трафике, но лучше не использовать его, если речь идет о конфиденциальных данных.

Данная публикация представляет собой перевод статьи « A brief history of the referer header » , подготовленной дружной командой проекта Интернет-технологии.ру