1. Atrybut target = "_ blank" na linkach, problem bezpieczeństwa
2. Rozwiązywanie problemów z rel = "noopener"
3. rel = "noreferrer" i rel = "noopener" na wszystkich linkach?

Rok temu prawie do dnia ogłosiliśmy aktualizację benchmarku dobrych praktyk naszej usługa analityki internetowej , Ta aktualizacja zawierała punkt kontrolny atrybutów hiperłączy, aby otworzyć łącze w nowym oknie lub zakładce (target = „_ blank”).

Najnowsza wersja Firefoksa dołączyła do Google Chrome, obsługując atrybut rel = "noopener", jedno z dostarczonych przez nas rozwiązań. Poświęćmy trochę czasu, aby powrócić do tego zalecenia, które opracowaliśmy dla celów bezpieczeństwa, ale które również odpowiada na problemy z wydajnością.

Atrybut target = "_ blank" na linkach, problem bezpieczeństwa

Mathias Bynens zilustrował to bardzo wyraźnie: użycie atrybutu target = „_ puste” w łączu hipertekstowym umożliwia otwartej stronie internetowej wywołanie zmiany strony w oryginalnym oknie. Jego artykuł oferuje także strony demonstracyjne, jeśli chcesz zobaczyć problem.

W skrócie: jeśli zezwolisz użytkownikom na publikowanie linków do Twojej witryny i używają atrybutu target = „_ blank”, możesz oczekiwać, że osoba atakująca przekieruje użytkownika na inną stronę. Nie na karcie otwartej przez kliknięcie linku, ale w oryginalnej karcie (w witrynie). I to bez żadnego ostrzeżenia. Metoda, która może być bardzo skuteczna na przykład w phishingu.

Domyślnie strona ma dostęp do ewentualnej strony wywołującej za pomocą atrybutu window.opener i może modyfikować atrybut lokalizacji, nawet jeśli dwie strony nie znajdują się w tej samej domenie.

Jak pokazał Jake Archibald , otwarte łącza w nowych oknach również mają wpływ na wydajność. Tutaj ponownie znajdziesz w artykule stronę demonstracyjną.
Problem polega na tym, że w większości przeglądarek, po otwarciu nowego okna lub nowej karty z istniejącej strony, dwa okna dzielą ten sam proces systemowy. Powszechne stosowanie tego procesu może prowadzić do zakłóceń między dwoma intensywnymi procesami przetwarzania w nieaktywnym oknie, które może mieć wpływ na płynność strony używanej przez użytkownika.

Rozwiązywanie problemów z rel = "noopener"

Przede wszystkim pamiętaj, że najprostszym rozwiązaniem nie jest użycie target = "_ blank", co może być sprzeczne z dobrymi praktykami dostępności, jeśli użytkownik nie jest informowany o tym zachowaniu (np. przypomnij Repozytorium Opquast ).

Jeśli potrzebujesz użyć tego atrybutu, powinieneś dodać inny atrybut: rel = noopener. Ten atrybut anuluje wartość window.opener (uniemożliwiając w ten sposób zmianę adresu URL na stronie wywołującej).

Pomimo niedawnego wsparcia (na początku marca 2017 r.) Tej funkcji przez Firefoksa, jak ogłoszono we wstępie, zgodność przeglądarki z rel = "noopener" jest wciąż zbyt ograniczony, aby uznać, że pozwoli to rozwiązać problem bezpieczeństwa.

Następnie możesz przejść do rel = noreferrer, szeroko obsługiwanego, co będzie miało ten sam efekt. Ale jak sama nazwa wskazuje, odmówi również miejscu docelowemu odebrania nagłówka HTTP Referer, który zapewnia początek ruchu.

rel = "noreferrer" i rel = "noopener" na wszystkich linkach?

Jeśli akceptujesz treści, które mogą zawierać linki (zazwyczaj komentarze do blogów), nie używaj target = "_ blank" lub podejmij niezbędne działania. W przypadku linków zewnętrznych, za które jesteś odpowiedzialny, zagrożenie bezpieczeństwa jest znacznie ograniczone, ponieważ jego wykorzystanie oznaczałoby, że atakujący wstrzykuje javascript na połączonej stronie. Wreszcie, jeśli chodzi o linki wewnętrzne, zagrożenie bezpieczeństwa nie powstaje, ale stawki wydajności pozostają.

Bardziej globalne rozwiązanie powinno pojawić się w wersji 3 Polityka bezpieczeństwa treści kto mógłby zaproponować dyrektywa o disown-opener , co pozwoli uniknąć określenia atrybutu dla każdego łącza.

Pomyśl o tym regularnie testuj swoją witrynę za pomocą Dareboost sprawdzić zastosowanie tej dobrej praktyki na swoich stronach i korzystać ze wszystkich naszych innych punktów kontroli jakości.