Noopener и noreferrer: что меняет ссылка в новой вкладке

Noopener и noreferrer решают разные части перехода: первое управляет связью нового контекста с исходным окном, второе дополнительно запрещает передачу referrer и включает поведение noopener. Для обычной внешней ссылки связь обычно не нужна. Для согласованного popup нужно отдельно проверить, от каких возможностей зависит его работа.

Три свойства, которые легко объединить по ошибке

Открытие нового контекста, наличие window.opener и передача сведений о переходе не являются одним параметром. Ссылка может открыться отдельно, но вопрос связи и referrer всё равно требует определения. Результат нужно описывать через нужные свойства, а не через привычный набор слов в шаблоне.

В описании noopener на MDN указано поведение без предоставления новой странице соответствующей связи через window.opener. При этом реальный интерфейс открытия зависит и от браузера. Нельзя считать один вид окна достаточным доказательством его свойств.

Что уже делает обычный target blank

MDN отмечает неявное поведение noopener для target="_blank" у перечисленных обычных ссылочных и формовых элементов. Поэтому отсутствие явно написанного rel само по себе не доказывает, что любая современная ссылка уязвима. Проверяйте конкретный механизм и целевые клиенты.

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

Роль noreferrer

В справке MDN по noreferrer описано отсутствие Referer при переходе и дополнительное поведение noopener. Эти свойства могут быть нужны вместе, но добавление noreferrer также меняет передачу сведений о переходе. Решение должно соответствовать задаче, а не только копироваться из соседней ссылки.

Не путайте это с отношением nofollow. Названия встречаются рядом в шаблонах, но не являются взаимозаменяемыми переключателями. И отсутствие заголовка Referer не удаляет сведения, которые вы сами явно включили в адрес назначения.

Учебная матрица переходов

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

Что проверить у window.open

В описании Window.open на MDN отдельно определены свойства noopener и noreferrer. Для соответствующего режима noopener меняется и возможность получить ссылку на новое окно: документация указывает null. Код, который рассчитывает на объект окна, должен учитывать этот контракт.

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

Если между окнами нужен обмен

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

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

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

Как проверить шаблон, а не одну удачную ссылку

Составьте перечень реальных способов открытия: обычные внешние ссылки, внутренние переходы и программные окна. Для каждого запишите нужную связь и политику передачи referrer. Не делайте вывод обо всём сайте по одному элементу другого типа.

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

В целевых браузерах фиксируйте наблюдаемое состояние и условия. Не объявляйте поддержку всех старых клиентов по одной текущей справке. В то же время не выдавайте любое отсутствие явного rel за подтверждённую проблему без проверки неявного поведения.

Порядок приёмки

1. Определите механизм открытия и назначение нового контекста.
2. Запишите, нужна ли связь окон и разрешена ли передача referrer.
3. Сопоставьте свойства обычной ссылки или Window.open с этим контрактом.
4. В своей тестовой среде проверьте наблюдаемые связь и переход, не используя чужие ресурсы для атак.
5. Для popup отдельно проверьте завершение, обмен и отказ открытия.
6. Сохраните результат для согласованных клиентов и ограничения охвата.

Для защиты сайта полезна карта типов переходов. В разработке веб-приложения контракт popup стоит определить до реализации. Для доработки передайте ожидаемые свойства и безопасные сценарии проверки, а не только просьбу дописать rel ко всему подряд.

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