Ładuj zasoby z innych domen bez nagłówków CORP za pomocą COEP: bez danych logowania

Zasoby z innych domen obsługiwane przez inne firmy często nie mają odpowiednich nagłówków CORP. Jeśli można ich prosić bez danych logowania, możesz teraz włączyć izolację zasobów z innych domen, oznaczając je jako takie.

Eiji Kitamura

Udostępniliśmy nową wartość zasady dotyczącej zasobów z innych domen (COEP) credentialless, która umożliwia przeglądarce ładowanie zasobów z innych domen, które nie korzystają z zasad dotyczących zasobów z innych domen (CORP), wysyłając żądanie bez danych logowania, takich jak pliki cookie. Pomaga to deweloperom łatwiej wdrożyć izolację od zasobów z innych domen.

Dlaczego potrzebujemy izolacji zasobów z innych domen

Niektóre internetowe interfejsy API, takie jak Spectre, zwiększają ryzyko ataków typu side-channel. Aby ograniczyć to ryzyko, przeglądarki udostępniają izolowane środowisko nazywane izolacją zasobów z innych domen, które jest dostępne po wyrażeniu zgody. W stanie izolowanym od zasobów z innych domen strona może używać funkcji uprzywilejowanych, takich jak SharedArrayBuffer, performance.measureUserAgentSpecificMemory() i dokładne liczniki czasu o lepszej rozdzielczości, a jednocześnie izoluje źródło od innych źródeł, chyba że się na to zgodzą.

Aby umożliwić izolację zasobów z innych domen, strona internetowa musi wysłać 2 nagłówki HTTP:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

W stanie izolowanym od zasobów z innych domen wszystkie zasoby z innych domen muszą być udostępniane za pomocą CORS lub muszą mieć wczytywany nagłówek Cross-Origin-Resource-Policy.

Wyzwania związane z włączaniem izolacji zasobów z innych domen

Izolacja zasobów z innych domen zwiększa bezpieczeństwo stron i umożliwia korzystanie z zaawansowanych funkcji, ale jej wdrożenie może być trudne. Jednym z największych wyzwań jest wymóg włączenia CORS lub CORP dla wszystkich zasobów z innych domen. Zasoby bez tych nagłówków nie będą wczytywane przez przeglądarkę na stronie izolowanej od zasobów z innych domen.

Takie zasoby z innych domen są zwykle obsługiwane przez firmy zewnętrzne, którym dodanie niezbędnych nagłówków może nie być łatwe.

Co jednak, jeśli wiemy, że zasób jest wystarczająco bezpieczny, żeby można go było załadować? W rzeczywistości jedynymi zasobami, które są zagrożone, są żądania z użyciem danych logowania, ponieważ potencjalnie zawierają one informacje poufne, których haker nie może wczytać. Oznacza to, że zasoby, których można żądać bez danych logowania, są publicznie dostępne i można je bezpiecznie wczytać.

credentialless na ratunek

W tym miejscu do akcji wkracza COEP: credentialless. credentialless to nowa wartość nagłówka Cross-Origin-Embedder-Policy. Podobnie jak w przypadku require-corp umożliwia włączanie izolacji zasobów z innych domen, ale zamiast wymagać nagłówka CORP:cross-origin w przypadku żądań z innych domen bez danych logowania, są wysyłane bez danych logowania (np. w plikach cookie).

Możesz też włączyć izolację zasobów z innych domen, używając tych 2 nagłówków:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Oznacza to, że żądany serwer z innych domen nie będzie w stanie odpowiedzieć z użyciem zasobów poufnych, a żądający może zawsze przyjąć, że odpowiedź zawiera tylko informacje dostępne publicznie.

Jest to też zgodne z planem przeglądarek dotyczących wycofywania plików cookie innych firm.

Pokaz

W tej wersji demonstracyjnej możesz wypróbować różne opcje nagłówka: https://cross-origin-isolation.glitch.me

Najczęstsze pytania

Czy w środowisku credentialless mogę wysłać żądanie uwierzytelnień?

Bez wątpienia wiąże się to z kosztem zmiany trybu żądania tak, aby odpowiedź wymagała sprawdzenia CORS. W przypadku tagów HTML, takich jak <audio>, <img>, <link>, <script> i <video>, wystarczy wyraźnie dołączyć crossorigin="use-credentials", aby przeglądarka mogła wysyłać żądania z danymi uwierzytelniającymi.

Nawet jeśli na przykład dokument w adresie https://www.example.com ma nagłówek Cross-Origin-Embedder-Policy: credentialless, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> wyśle żądanie z danymi uwierzytelniającymi.

W przypadku interfejsu API fetch() można użyć request.mode = 'cors'.

COEP: credentiallessW jaki sposób COEP: require-corp nadal jest przydatny w przypadku mojej witryny?

COEP: require-corp nie wymaga ręcznego przełączania trybu żądania na CORS, jeśli w przypadku niektórych zasobów podrzędnych z innych domen pliki cookie są potrzebne.

Czy w środowisku credentialless mogę też wczytywać elementy iframe z różnych domen bez specjalnych nagłówków?

Nie. Wczytywanie elementów iframe z innych domen w środowisku credentialless nadal wymaga tych samych warunków co w przypadku require-corp. Dokumenty iframe muszą być wyświetlane z 2 nagłówkami:

  • Cross-Origin-Embedder-Policy: credentialless (lub require-corp)
  • Cross-Origin-Resource-Policy: cross-origin

Na szczęście toczy się dyskusja na temat zezwalania na ładowanie elementów iframe z innych domen bez tych nagłówków poprzez dodanie elementów iframe crossorigin="anonymous". Umożliwi to ładowanie elementów iframe z innych domen bez nagłówków, ale bez danych logowania.

Czy ta funkcja zostanie zastosowana przez inne przeglądarki?

Co dalej

Wkrótce wprowadzimy 2 dodatkowe aktualizacje, aby wyeliminować inne wyzwania związane z izolacją zasobów z innych domen:

Użytkownicy, którzy z powodu powyższych przeszkód zarejestrowali się w testowaniu origin Chrome w celu przedłużenia zmiany SharedArrayBuffer, mogą się zastanawiać, kiedy zostanie ona zakończona. Początkowo informowaliśmy, że zakończymy ją w Chrome 96, ale postanowiliśmy ją przełożyć na wersję 106.

Zasoby

Zdjęcie: Martin Adams w aplikacji Unsplash