Link otwierany w nowej karcie wygląda niewinnie, ale w HTML potrafi uruchomić mechanizm, który łączy bezpieczeństwo, prywatność i analitykę ruchu. W praktyce ten temat sprowadza się do wyboru między ochroną strony źródłowej a zachowaniem informacji o tym, skąd przyszedł użytkownik; zestaw noopener noreferrer rozwiązuje oba problemy, ale nie zawsze w tym samym stopniu. Poniżej pokazuję, co dokładnie robi każdy wariant, kiedy go używać i jak uniknąć błędów, które wciąż pojawiają się w prostych komponentach linków.
Co warto zapamiętać o bezpiecznych linkach otwieranych w nowej karcie
- noopener odcina nową kartę od strony, która ją otworzyła, dzięki czemu ogranicza ryzyko podmiany widoku źródłowego.
- noreferrer robi to samo, a dodatkowo nie wysyła nagłówka Referer, więc ukrywa źródło wejścia.
-
target="_blank" w nowoczesnych przeglądarkach zwykle daje efekt zbliżony do
noopener, ale jawny zapis nadal porządkuje kod i ogranicza ryzyko w mniej aktualnych środowiskach. - Jeśli zależy Ci na analityce, afiliacji albo kampaniach, sam
noreferrermoże być zbyt agresywny. - To samo podejście warto stosować nie tylko w
, ale też w linkach generowanych przez JavaScript oraz w wybranych przypadkach dlai.
Dlaczego bezpieczne otwieranie nowych kart ma znaczenie
Największy problem z linkami otwieranymi w nowej karcie nie leży w samym fakcie otwarcia nowego okna, tylko w tym, że nowa strona może próbować oddziaływać na stronę, z której przyszła. To właśnie fundament ataku typu reverse tabnabbing: użytkownik widzi zaufaną domenę, a potem oryginalna karta zostaje podmieniona na fałszywą stronę logowania lub inny wariant phishingu. OWASP wprost wskazuje, że taki scenariusz może wykorzystać link z target="_blank", jeśli nie zadbasz o odpowiednią ochronę.
W praktyce ryzyko rośnie wszędzie tam, gdzie link prowadzi do zewnętrznego serwisu, treści generowanej przez użytkownika albo strony, której nie kontrolujesz w pełni. To nie jest detal od „bardziej czystego HTML-a”, tylko realna decyzja o tym, czy nowa karta ma mieć dostęp do kontekstu Twojej strony. Kiedy patrzę na to redakcyjnie i technicznie jednocześnie, traktuję ten temat jak obowiązkowy element higieny kodu, a nie opcjonalny dodatek. Kiedy rozumiesz już zagrożenie, dużo łatwiej rozdzielić dwa atrybuty, które często wrzuca się do jednego worka.
Czym różni się noopener od noreferrer
Te dwa słowa bywają stawiane obok siebie, ale robią trochę inne rzeczy. noopener odcina dostęp do window.opener, czyli blokuje możliwość, by nowa karta manipulowała kartą źródłową. noreferrer robi to samo, a dodatkowo usuwa nagłówek Referer, więc serwis docelowy nie dostaje informacji o adresie strony, z której użytkownik kliknął link.
MDN podkreśla, że w nowoczesnych przeglądarkach target="_blank" zachowuje się tak, jakby noopener było ustawione domyślnie, ale to nadal nie mówi nic o refererze. Z kolei OWASP przypomina, że noreferrer automatycznie obejmuje też ochronę zapewnianą przez noopener. Właśnie dlatego wybór zależy od tego, czy bardziej zależy Ci na bezpieczeństwie, czy także na zachowaniu danych o źródle ruchu.
| Wartość | Co robi | Co zostaje zachowane | Kiedy ma sens |
|---|---|---|---|
noopener |
Blokuje dostęp przez window.opener
|
Referer nadal może zostać wysłany | Gdy chcesz bezpieczeństwa bez utraty informacji analitycznych |
noreferrer |
Blokuje window.opener i ukrywa źródło wejścia |
Nie ma nagłówka Referer | Gdy prywatność i brak śladu źródłowego są ważniejsze niż analityka |
| Obie wartości razem | Łączy ochronę kontekstu z ukryciem referera | Brak Referer | Gdy chcesz prostego, bezpiecznego standardu dla linków zewnętrznych |
To rozróżnienie jest ważniejsze, niż wygląda na pierwszy rzut oka. Jeśli raz to sobie uporządkujesz, łatwiej będziesz pisać poprawny HTML bez zgadywania przy każdym linku.
Jak pisać poprawne linki w HTML
Najbardziej praktyczny wzorzec jest prosty: jeśli link otwiera się w nowej karcie i prowadzi poza Twoją stronę, dopisz odpowiedni rel od razu przy elemencie . Dzięki temu kod jest czytelny, intencja jasna, a komponent nie opiera się na domyślnych zachowaniach przeglądarki. Dla typowego linku zewnętrznego bez potrzeby zachowania referera zapis wygląda tak:
Przeczytaj artykuł
Jeśli zależy Ci na bezpieczeństwie, ale jednocześnie chcesz zachować dane o źródle ruchu, użyj samego noopener:
Przeczytaj artykuł
Ten sam schemat warto pamiętać także dla i , bo MDN obejmuje nimi tę samą logikę relacji. W praktyce najważniejsza zasada brzmi: nie traktuj nowej karty jako decyzji wyłącznie UX-owej. To jednocześnie decyzja o bezpieczeństwie i o tym, czy chcesz zostawić ślad referera. Kiedy zapisujesz link w komponencie lub w CMS-ie, najlepiej wymuszać ten wzorzec automatycznie, zamiast liczyć na to, że ktoś będzie o nim pamiętał przy każdym wpisie.
Najczęstsze błędy, które widzę w projektach
Najczęściej problem nie polega na tym, że ktoś w ogóle nie zna tych atrybutów, tylko na tym, że używa ich wybiórczo albo zbyt mechanicznie. Poniżej są błędy, które pojawiają się szczególnie często:
- Dodawanie
target="_blank"do każdego linku, także wewnętrznego, bez zastanowienia, czy nowa karta naprawdę jest potrzebna. - Zakładanie, że nowoczesne przeglądarki załatwiają wszystko za Ciebie i nie trzeba już pisać jawnego
rel. - Używanie
noreferrerw miejscach, gdzie zależy Ci na atrybucji ruchu, kampaniach lub analizie źródeł wejścia. - Zapominanie o linkach tworzonych w JavaScript, gdzie problem może pojawić się przy
window.open(), a nie tylko przy klasycznym. - Brak spójnego standardu w komponentach, przez co jeden moduł generuje bezpieczny link, a drugi już nie.
W projektach z treściami od użytkowników największy sens ma automatyzacja. Jeśli redaktor albo użytkownik końcowy może wstawiać odnośniki samodzielnie, to lepiej zabezpieczyć je na etapie renderowania albo sanitizacji niż liczyć na ręczną dyscyplinę. Z punktu widzenia utrzymania to zwykle szybsze i mniej podatne na przypadkowe pomyłki. Mając ten zestaw pułapek na uwadze, łatwiej przejść do prostego standardu, który można wdrożyć bez dyskusji w zespole.
Mój praktyczny standard dla linków wychodzących
Gdybym miał ułożyć jedną regułę do większości projektów, brzmiałaby ona tak: link zewnętrzny w nowej karcie dostaje przynajmniej noopener, a jeśli nie potrzebuję referera, dokładam też noreferrer. To podejście jest bezpieczne, przewidywalne i łatwe do utrzymania w komponentach.
- Link do obcej domeny, bez znaczenia analitycznego: użyj obu wartości.
- Link do zaufanego partnera, gdzie chcesz zachować źródło ruchu: zostaw samo
noopener. - Link wewnętrzny otwierany w nowej karcie: najpierw zadaj sobie pytanie, czy to w ogóle ma sens UX-owo.
- Link generowany dynamicznie w JavaScript: potraktuj go tak samo ostrożnie jak klasyczny odnośnik HTML.
Jeśli mam zostawić jedną praktyczną myśl, to taką: nowa karta ma być wygodą dla użytkownika, a nie sposobem na rozmycie odpowiedzialności za bezpieczeństwo. Dobrze ustawiony rel zajmuje sekundę, a potrafi oszczędzić problemów, których nie widać aż do momentu, kiedy ktoś naprawdę spróbuje wykorzystać lukę.