Zasoby z innych źródeł, które są udostępniane przez strony trzecie, często nie zawierają odpowiednich nagłówków CORP. Jeśli można je wysyłać bez danych logowania, możesz teraz włączyć izolację między domenami, oznaczając je jako takie.
Wprowadziliśmy nową wartość zasad dotyczących umieszczania zasobów z innych źródeł (COEP)
credentialless
, która umożliwia przeglądarce wczytywanie zasobów z innych źródeł, które nie korzystają z zasad dotyczących zasobów z innych źródeł (CORP), przez wysyłanie żądania bez danych uwierzytelniających, takich jak pliki cookie. Ułatwia to programistom stosowanie izolacji między domenami.
Dlaczego potrzebujemy izolacji od zasobów z innych domen
Niektóre interfejsy API zwiększają ryzyko ataków typu side-channel, takich jak Spectre. Aby ograniczyć to ryzyko, przeglądarki oferują odizolowane środowisko oparte na opcjonalnym zgłaszaniu, zwane izolacją zasobów z innych domen. W stanie odizolowania między domenami strona internetowa może korzystać z funkcji uprzywilejowanych, takich jak SharedArrayBuffer
, performance.measureUserAgentSpecificMemory()
i precyzyjne zegary z lepszą rozdzielczością, przy jednoczesnym izolowaniu pochodzenia od innych, chyba że wyrażono na to zgodę.
Aby umożliwić izolację między domenami, strona internetowa musi wysyłać 2 nagłówki HTTP:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
W stanie odizolowania od zasobów z innych witryn wszystkie zasoby z innych witryn muszą być udostępniane za pomocą CORS lub muszą mieć ustawiony nagłówek Cross-Origin-Resource-Policy
.
Problemy z włączaniem izolacji między domenami
Chociaż izolacja między domenami zwiększa bezpieczeństwo stron internetowych i umożliwia stosowanie zaawansowanych funkcji, jej wdrożenie może być trudne. Jednym z największych wyzwań jest konieczność włączenia CORS lub CORP dla wszystkich zasobów między domenami. Zasoby bez tych nagłówków nie będą wczytywane przez przeglądarkę na stronie odizolowanej między domenami.
Te zasoby między domenami są zwykle dostarczane przez osoby trzecie, które mogą mieć trudności z dodaniem niezbędnych nagłówków.
Co jednak, jeśli wiemy, że zasób jest na tyle bezpieczny, że można go wczytać? W istocie jedyne zasoby, które są zagrożone, to te, do których dostęp jest uzyskiwany za pomocą danych logowania, ponieważ mogą one zawierać informacje poufne, których atakujący nie może samodzielnie pobrać. Oznacza to, że zasoby, których można zażądać bez danych logowania, są publicznie dostępne i bezpieczne do wczytania.
credentialless
na ratunek
Właśnie w tym przypadku przydają się COEP: credentialless
. credentialless
to nowa wartość nagłówka Cross-Origin-Embedder-Policy
. Podobnie jak w przypadku atrybutu require-corp
, można go użyć do włączenia izolacji między domenami, ale zamiast wymagać nagłówka CORP:cross-origin
w przypadku żądań między domenami bez atrybutu CORS, żądania te są wysyłane bez poświadczeń (np. plików cookie).
Izolację między domenami można też włączyć za pomocą tych 2 nagłówków:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
Oznacza to, że żądany serwer w innej domenie nie będzie mógł odpowiedzieć za pomocą zasobu poufnego, a żądający może zawsze założyć, że odpowiedź zawiera tylko informacje dostępne publicznie.
Jest to też zgodne z planem przeglądarek dotyczącym wycofania plików cookie innych firm.
Prezentacja
W tej wersji demonstracyjnej możesz wypróbować różne opcje nagłówka: https://cross-origin-isolation.glitch.me
Najczęstsze pytania
Czy mogę wysłać prośbę o uprawnienia w środowisku credentialless
?
Oczywiście, ale w takim przypadku musisz zmienić tryb żądania, aby wymagał sprawdzenia CORS w odpowiedzi. W przypadku tagów HTML, takich jak <audio>
, <img>
, <link>
, <script>
i <video>
, po prostu dodaj crossorigin="use-credentials"
, aby poinformować przeglądarkę, że ma wysyłać żądania z danymi logowania.
Na przykład nawet wtedy, gdy dokument na koncie https://www.example.com
ma nagłówek Cross-Origin-Embedder-Policy: credentialless
, usługa <img
src="https://images.example.com/avatar.png" crossorigin="use-credentials">
wyśle żądanie z uprawnieniami.
W przypadku interfejsu API fetch()
można użyć request.mode = 'cors'
.
Dlaczego COEP: credentialless
jest nadal przydatna dla mojej witryny?COEP: require-corp
COEP: require-corp
nie wymaga ręcznego przełączania trybu żądania na CORS, jeśli pliki cookie są potrzebne do niektórych zasobów podrzędnych z różnych domen.
Czy w środowisku credentialless
mogę też wczytywać elementy iframe z różnych źródeł bez specjalnych nagłówków?
Nie. Ładowanie ramek iframe z wielu źródeł w środowisku credentialless
nadal wymaga spełnienia tych samych warunków co w przypadku require-corp
. Dokumenty iframe muszą być wyświetlane z 2 nagłówkami:
Cross-Origin-Embedder-Policy: credentialless
(lubrequire-corp
)Cross-Origin-Resource-Policy: cross-origin
Dobra wiadomość jest taka, że trwa dyskusja na temat zezwalania na wczytywanie elementów iframe z innych źródeł bez tych nagłówków, jeśli iframe crossorigin="anonymous"
.
Pozwoli to na wczytywanie elementów iframe z różnych źródeł bez nagłówków, ale bez danych logowania.
Czy inne przeglądarki będą mogły korzystać z tej funkcji?
- Problem ze śledzeniem w Firefoxie
- Żądanie dotyczące pozycji w interfejsie Webkit: Brak sygnału
- TAG W3C Prośba o pozycję: Oczekuje
Co dalej?
Aby rozwiązać inne problemy związane z izolacją zasobów z innych domen, wprowadzamy 2 dodatkowe aktualizacje:
Osoby, które zarejestrowały się w programie Chrome origin, aby przedłużyć okres przejściowy dla obiektów SharedArrayBuffer ze względu na powyższe przeszkody, mogą się zastanawiać, kiedy on się zakończy. Pierwotnie ogłosiliśmy, że ta funkcja zostanie zakończona w Chrome 96, ale postanowiliśmy odłożyć to do Chrome 106.
Zasoby
- Wyizolowanie witryny za pomocą zasad COOP i COEP
- Dlaczego potrzebujesz „izolacji od zasobów z innych domen” do obsługi zaawansowanych funkcji
- Przewodnik po włączaniu izolacji zasobów z innych domen
- Aktualizacje SharedArrayBuffer w Chrome 88 na Androida i Chrome 92 na komputer
Zdjęcie: Martin Adams na Unsplash