Krótki opis nagłówków zabezpieczeń

Dowiedz się więcej o nagłówkach, które mogą chronić witrynę i szybko wyszukiwać najważniejsze informacje.

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

W tym artykule znajdziesz najważniejsze nagłówki zabezpieczeń, których możesz używać do ochrony do Twojej witryny. Dzięki niemu poznasz funkcje zabezpieczeń internetowych i dowiesz się, jak implementuj je w swojej witrynie oraz korzystaj z nich, by przypominać Ci o nich.

Nagłówki zabezpieczeń zalecane w przypadku witryn, które obsługują poufne dane użytkownika:
Polityka bezpieczeństwa treści (CSP)
Zaufane typy
Nagłówki zabezpieczeń zalecane dla wszystkich witryn:
X-Content-Type-Options
X-Frame-Options
Zasady dotyczące zasobów z różnych domen (CORP)
Zasady dotyczące otwartych produktów z różnych domen (COOP)
HTTP Strict Transport Security (HSTS)
Nagłówki zabezpieczeń dla witryn z zaawansowanymi funkcjami:
Udostępnianie zasobów między serwerami z różnych domen (CORS)
Zasady dotyczące umieszczania treści z różnych domen (COEP)
Znane zagrożenia w internecie
Zanim zagłębimy się w nagłówki dotyczące bezpieczeństwa, poznaj znane zagrożenia internetowe i dlaczego warto używać tych nagłówków.

Zanim zagłębimy się w nagłówki dotyczące bezpieczeństwa, poznaj znane zagrożenia internetowe i dlaczego warto używać tych nagłówków.

Ochrona witryny przed lukami w zabezpieczeniach przed wstrzyknięciem kodu

Luki w zabezpieczeniach polegające na wstrzyknięciu pojawiają się, gdy niezaufane dane przetwarzane przez może wpłynąć na swoje działanie i zwykle prowadzić do wykonania skrypty kontrolowane przez atakującego. Najczęstsza luka w zabezpieczeniach spowodowana wstrzyknięciem Błędy występują między witrynami skrypty (XSS) w w różnych formach, w tym XSS przechowywane dane XSS, Oparta na DOM XSS oraz z innymi wariantami.

Luka XSS zwykle daje osobie przeprowadzającej atak pełny dostęp do danych użytkownika przetwarzane przez aplikację oraz wszelkie inne informacje przechowywane w tej samej sieci origin.

Tradycyjne metody ochrony przed wstrzykiwaniem obejmują powtarzające się stosowanie automatycznego ucieczki systemów szablonów HTML, unikając stosowania niebezpiecznych skryptów JavaScript. interfejsów API oraz poprawnego przetwarzania danych użytkowników za pomocą hostingu przesyłanie plików do osobnej domeny i dezynfekcję kodu HTML kontrolowanego przez użytkowników.

  • Użyj polityki Content Security Policy (CSP), aby kontrolować, które skrypty mogą być wykonywane przez aplikację, aby zmniejszyć ryzyko wstrzykiwania.
  • Używaj zaufanych typów, aby egzekwować oczyszczanie danych przekazywanych do niebezpiecznych API JavaScript.
  • Użyj X-Content-Type-Options, aby uniemożliwić przeglądarce błędnej interpretacji typów MIME zasobów witryny, co może prowadzić do wykonywania skryptu.

Odizoluj witrynę od innych witryn

Otwartość internetu umożliwia witrynom współdziałanie ze sobą w sposób, może naruszać oczekiwania aplikacji w zakresie bezpieczeństwa. Obejmuje to niespodziewane zmiany wysyłania uwierzytelnionych żądań lub umieszczania danych z innej aplikacji w dokumentu atakującego, co pozwoli hakerowi zmodyfikować lub odczytać dane aplikacji.

Do najczęstszych luk w zabezpieczeniach, które utrudniają izolację sieci, należą: clickjacking, cross-site żądanie oszustw (CSRF), inne witryny uwzględnianie skryptów (XSSI) oraz różne wyciek danych między witrynami.

Post-Spectre Web Programowanie to świetny temat jeśli interesują Cię te nagłówki.

Utwórz bezpieczną witrynę w sposób bezpieczny

Spectre wczytuje dane do tej samej grupy kontekstu przeglądania, którą można potencjalnie odczytać pomimo zasady z tej samej domeny. Ograniczenia przeglądarek które mogłyby wykorzystać lukę kryjącą się w specjalnym środowisku „cross-origin and” (izolacja zasobów z innych domen). Dzięki izolacji zasobów z innych domen możesz: korzystać z zaawansowanych funkcji, takich jak SharedArrayBuffer.

Szyfrowanie ruchu w witrynie

Problemy z szyfrowaniem pojawiają się, gdy aplikacja nie zaszyfruje w pełni danych transport publiczny, dzięki czemu osoby przeprowadzające podsłuch mogą wysłuchać informacji o interakcjach użytkownika. z aplikacją.

Niewystarczające szyfrowanie może wystąpić w następujących przypadkach: niekorzystanie z protokołu HTTPS, treść mieszana, ustawianie plików cookie bez Secure (lub __Secure prefiks), lub nieregularna weryfikacja CORS .

Polityka bezpieczeństwa treści (CSP)

Skrypty między witrynami (XSS) to atak, luka w zabezpieczeniach witryny umożliwia wstrzyknięcie szkodliwego skryptu .

Content-Security-Policy zapewnia dodatkową warstwę, która pozwala ograniczyć ataki XSS przez z ograniczeniem liczby skryptów, które mogą być wykonywane przez stronę.

Zalecamy włączenie ścisłego CSP za pomocą jednej z tych metod:

  • Jeśli renderujesz strony HTML na serwerze, użyj rygorystycznego CSP bez użycia kodu.
  • Jeśli kod HTML musi być wyświetlany statycznie lub w pamięci podręcznej, na przykład w przypadku aplikacji na jednej stronie, użyj rygorystycznego CSP opartego na haszowaniu.

Przykład użycia: CSP bez wartości

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
Jak korzystać z CSP

1. Użyj rygorystycznego CSP opartego na liczbie jednorazowej {: #nonce-based-csp}

Jeśli renderujesz strony HTML na serwerze, użyj rygorystycznego CSP bez użycia kodu.

Wygeneruj nową wartość jednorazową skryptu dla każdego żądania po stronie serwera i ustaw następujący nagłówek:

plik konfiguracji serwera

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Aby w kodzie HTML wczytać skrypty, ustaw atrybut nonce wszystkich elementów Tagi <script> do tego samego ciągu znaków {RANDOM1}.

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Zdjęcia Google są dobrym rygorystycznym CSP bez wartości przykład. Użyj Narzędzi deweloperskich, aby zobaczyć ich zastosowania.

2. Użyj rygorystycznego CSP opartego na haszowaniu {: #hash-based-csp}

Jeśli kod HTML musi być wyświetlany statycznie lub w pamięci podręcznej, na przykład podczas tworzenia aplikacji jednostronicowej, użyj rygorystycznego CSP opartego na haszowaniu.

plik konfiguracji serwera

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Aby zastosować kod oparty na haszowaniu, w kodzie HTML musisz umieścić skrypty zasad, ponieważ większość przeglądarek nie obsługuje szyfrowania zewnętrznych skrypty.

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

Aby wczytywać skrypty zewnętrzne, przeczytaj sekcję „Dynamiczne wczytywanie skryptów źródłowych” poniżej Opcja B: nagłówek odpowiedzi CSP oparty na haszach.

CSP Evaluator to dobre narzędzie do i dobry przykład CSP. Użyj Narzędzi deweloperskich, aby zobaczyć ich zastosowania.

Obsługiwane przeglądarki

Inne ważne uwagi dotyczące CSP

  • frame-ancestors chroni witrynę przed przechwytywaniem kliknięć – istnieje ryzyko, które pojawia się, jeśli zezwolisz niezaufanych stron, na których możesz umieścić swoją. Jeśli wolisz prostsze rozwiązanie, użyj X-Frame-Options blokuje wczytywanie, ale frame-ancestors daje zaawansowaną konfigurację, która zezwala na umieszczanie w witrynach tylko określonych źródeł.
  • Korzystanie z platformy CSP pozwala upewnić się, że wszystkie zasoby witryny wczytywane przez HTTPS. Zawiera mogą stać się mniej istotne. Obecnie większość przeglądarek blokuje treści mieszane.
  • Można również ustawić CSP w trybie tylko do raportu .
  • Jeśli nie możesz ustawić CSP jako nagłówka po stronie serwera, możesz też ustawić go jako meta . Pamiętaj, że w przypadku metatagów nie można używać trybu tylko do raportowania (chociaż może się to zmienić).

Więcej informacji

Zaufane typy

Oparta na DOM XSS to atak polegający na przekazaniu szkodliwych danych do ujścia obsługującego kod dynamiczny na przykład eval() lub .innerHTML.

Zaufane typy zapewniają narzędzia do pisania, weryfikacji bezpieczeństwa i zarządzania bez DOM XSS. Można je włączyć przez CSP i ustawić Domyślnie kod JavaScript jest bezpieczny, ponieważ nie zezwala na akceptowanie niebezpiecznych internetowych interfejsów API obiekt specjalny – zaufanego typu.

Aby utworzyć te obiekty, możesz zdefiniować zasady zabezpieczeń, dzięki którym możesz: że reguły zabezpieczeń (takie jak zmiana znaczenia czy dezynfekcja) są stosowane konsekwentnie; przed zapisaniem danych w modelu DOM. Te zasady są jedynymi miejscami, w kodzie, które mogłyby wprowadzić DOM XSS.

Przykładowe zastosowania

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
Jak korzystać z Zaufanych typów

  1. Egzekwowanie zaufanych typów w przypadku niebezpiecznych ujść DOM Nagłówek CSP i Zaufane typy: 

    Content-Security-Policy: require-trusted-types-for 'script'

    Obecnie 'script' jest jedyną akceptowaną wartością dla argumentu require-trusted-types-for.

    Oczywiście możesz łączyć te typy z innymi dyrektywami CSP:

Scalanie powyższego CSP opartego na liczbie jednorazowej z zaufanymi typami: 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>Uwaga: </b> Możesz ograniczyć dozwolone nazwy zasad zaufanych typów, ustawiając dodatkowe <code>zaufane typy</code> (na przykład <code>trusted-types myPolicy</code>). Nie jest to jednak wymagane.  &lt;/aside&gt;


    
  
  1. 
    
    Zdefiniuj zasadę
    
    
    Zasady:
    
   
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    
    
  
    2. 
  
  2. 
    
    Zastosuj zasadę
    
    
    Używaj tych zasad podczas zapisywania danych w DOM:
    
   
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    
    
    W require-trusted-types-for 'script' użycie zaufanego typu jest
      . Użycie niebezpiecznego interfejsu DOM API z ciągiem znaków spowoduje wyświetlenie
      .
    
  
    3. 



Obsługiwane przeglądarki



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Więcej informacji

X-Content-Type-Options

Gdy z Twojej domeny zostanie wysłany złośliwy dokument HTML (na przykład obraz przesłany do usługi fotograficznej zawiera prawidłowe znaczniki HTML), niektóre przeglądarki potraktuje go jako aktywny dokument i pozwoli mu na wykonywanie skryptów w kontekście aplikacji i prowadząc do skryptów między witrynami .

Funkcja X-Content-Type-Options: nosniff zapobiega mu, instruując przeglądarkę typ MIME ustawiony w Nagłówek Content-Type danej odpowiedzi jest prawidłowy. Ten nagłówek jest zalecane w przypadku wszystkich zasobów.

Przykład użycia

X-Content-Type-Options: nosniff
Jak korzystać z X-Content-Type-Options

Zalecany tryb X-Content-Type-Options: nosniff jest zalecany w przypadku wszystkich zasobów udostępnianych z serwera oraz odpowiedni nagłówek Content-Type.

X-Content-Type-Options: nosniff

Przykładowe nagłówki wysłane z kodem HTML dokumentu

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 64.
  • Krawędź: 12.
  • Firefox: 50.
  • Safari: 11.

Źródło

Więcej informacji

X-Frame-Options

Jeśli złośliwa witryna może umieścić Twoją witrynę w elemencie iframe, może to zezwalać na aby osoby przeprowadzające atak wywołały niezamierzone działania użytkownika clickjacking. Poza tym w niektórych przypadki typ Spectre ataki dają złośliwe witryny, mogą poznać treść umieszczonego dokumentu.

X-Frame-Options wskazuje, czy przeglądarka może wyświetlać stronę w kolumnach <frame>, <iframe>, <embed> lub <object>. Wszystkie dokumenty wysyłanie tego nagłówka w celu wskazania, czy pozwalają umieszczone w innych dokumentach.

Przykład użycia

X-Frame-Options: DENY
Jak korzystać z X-Frame-Options

Wszystkie dokumenty, które nie są przeznaczone do umieszczania, powinny używać nagłówka X-Frame-Options.

Możesz zobaczyć, jak poniższe konfiguracje wpływają na ładowanie elementu iframe na tym wersji demonstracyjnej. Zmień X-Frame-Options i kliknij przycisk Załaduj ponownie element iframe.

Chroni Twoją witrynę przed umieszczeniem w innych witrynach

Zabroń umieszczenia w innym dokumencie.

X-Frame-Options: DENY (Opcje X-Frame-Options: DENY) 
X-Frame-Options: DENY

Chroni Twoją witrynę przed umieszczeniem w witrynie z innej domeny.

Zezwalaj na umieszczanie tylko w dokumentach tej samej domeny.

X-Frame-Options: SAMEORIGIN

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 4.
  • Krawędź: 12.
  • Firefox: 4.
  • Safari: 4.

Źródło

Więcej informacji

Zasady dotyczące zasobów z różnych domen (CORP)

Osoba przeprowadzająca atak może umieścić zasoby z innego źródła, na przykład z Twojej witryny, aby zdobyć o nich informacje za pomocą innych witryn wyciek danych.

Cross-Origin-Resource-Policy ogranicza to ryzyko, wskazując zestaw stron, przez które może być wczytywany. Nagłówek może mieć jedną z 3 wartości: same-origin, same-site i cross-origin. Wszystkie zasoby są zalecamy wysłanie tego nagłówka, aby wskazać, czy pozwalają na ładowanie innych witrynach.

Przykład użycia

Cross-Origin-Resource-Policy: same-origin
Jak korzystać z CORP

Zalecamy, aby wszystkie zasoby były obsługiwane przez jedną z tych konfiguracji: 3 nagłówki.

Możesz sprawdzić, jak poniższe konfiguracje wpływają na ładowanie zasobów w środowisko Cross-Origin-Embedder-Policy: require-corp na tym wersji demonstracyjnej. Zmień w menu Cross-Origin-Resource-Policy i kliknąć Odśwież Element iframe lub przycisk Załaduj obraz ponownie, aby zobaczyć efekt.

Zezwalaj na ładowanie zasobów cross-origin

Zaleca się, aby usługi podobne do CDN stosowały cross-origin do zasobów (ponieważ są one zwykle ładowane przez strony z innych domen), chyba że są już wyświetlane za pomocą CORS, który daje podobny efekt.

Cross-Origin-Resource-Policy: z innej domeny 
Cross-Origin-Resource-Policy: cross-origin

Ogranicz ładowanie zasobów z same-origin

Pole same-origin powinno być stosowane tylko do zasobów, które mają być ładowane przez strony z tej samej domeny. Należy go zastosować do zasobów, które zawierają poufne dane informacje o użytkowniku lub odpowiedzi interfejsu API, który ma być wywoływany tylko z tego samego źródła.

Pamiętaj, że zasoby z tym nagłówkiem można nadal ładować bezpośrednio, na przykład otwierając adres URL w nowym oknie przeglądarki. Zasób z innego źródła Zasada chroni tylko zasób przed umieszczeniem go w innych witrynach.

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

Ogranicz ładowanie zasobów z same-site

Zalecamy stosowanie same-site do zasobów podobnych do powyżej ale powinny być wczytywane przez inne subdomeny Twojej witryny.

Cross-Origin-Resource-Policy: ta sama witryna 
Cross-Origin-Resource-Policy: same-site

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 73.
  • Krawędź: 79.
  • Firefox: 74.
  • Safari: 12.

Źródło

Więcej informacji

Zasady dotyczące otwartych źródeł w różnych źródłach

Osoba atakująca może otworzyć inną witrynę w wyskakującym okienku, aby dowiedzieć się, o które wiemy, wykorzystując znajdujące się w witrynach wyciek danych. W niektórych przypadkach może to również umożliwić wyświetlenie wykorzystania ataków typu side-channel na podstawie Spectre

Nagłówek Cross-Origin-Opener-Policy umożliwia izolowanie dokumentu z okna z innej domeny otwartych za pomocą window.open() lub linku z target="_blank" bez rel="noopener". W rezultacie każdy element otwierający z innej domeny dokument nie będzie się do niego odnosił i nie będzie mógł z niego korzystać z nim.

Przykład użycia

Cross-Origin-Opener-Policy: same-origin-allow-popups
Jak korzystać z COOP

Możesz sprawdzić, jak poniższe konfiguracje wpływają na komunikację z wyskakujące okienko z innej domeny w tej wersji demonstracyjnej. Zmień menu Cross-Origin-Opener-Policy w przypadku danego dokumentu i wyskakującym okienku kliknij przycisk Otwórz wyskakujące okienko, a następnie kliknij Wyślij postMessage, aby sprawdzić, czy wiadomość została rzeczywiście dostarczona.

Izolowanie dokumentu od okien z innych domen

Ustawienie same-origin powoduje, że dokument jest izolowany od zasobów z innych domen oknach dokumentów.

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

Izoluj dokument od okien z innych domen, ale zezwalaj na wyskakujące okienka

Ustawienie same-origin-allow-popups umożliwia przechowywanie dokumentu odniesienie do jego wyskakujące okienka, chyba że sprzedawca określił coOP przy użyciu: same-origin lub same-origin-allow-popups Oznacza to, że same-origin-allow-popups nadal może zabezpieczy dokument przed odwołaniem po otwarciu jako wyskakującego okienka, ale na komunikację z własnymi wyskakującymi okienkami.

Cross-Origin-Opener-Policy: same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

Zezwalaj na odwoływanie się do dokumentu przez okna z innych domen

unsafe-none to wartość domyślna, ale możesz wprost wskazać, że to dokument można otworzyć w oknie z innej domeny i zachować wzajemny dostęp.

Cross-Origin-Opener-Policy: niebezpieczny-none . 
Cross-Origin-Opener-Policy: unsafe-none

Wzorce raportów niezgodne z COOP

Możesz otrzymywać raporty, gdy system współpracy z partnerem (COOP) uniemożliwi kontakt z reklamodawcą Interfejs API do raportowania.

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP obsługuje też tryb „tylko raporty”, dzięki któremu możesz otrzymywać raporty bez rzeczywiste blokowanie komunikacji między dokumentami z innych domen.

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2

Źródło

Więcej informacji

współdzielenie zasobów pomiędzy serwerami z różnych domen (CORS)

W przeciwieństwie do innych elementów w tym artykule funkcja CORS nie jest z nagłówkiem, lecz mechanizmem przeglądarki, który wysyła żądania i zezwala na dostęp między domenami.

Domyślnie przeglądarki wymuszają zasady dotyczące tej samej domeny, aby uniemożliwia stronie internetowej dostęp do zasobów z innych domen. Na przykład, gdy plik obraz z innej domeny jest wczytywany, mimo że jest wyświetlany na stronie internetowej JavaScript na stronie nie ma dostępu do danych obrazu. Dostawca zasobów może złagodzić ograniczenia i zezwolić innym witrynom na odczyt zasobów przez włączenie CORS.

Przykład użycia

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Jak korzystać z CORS

Zanim przejdziemy do konfigurowania CORS, warto poznać na czym polega różnica między typami żądań. W zależności od szczegółów prośby zostanie ona sklasyfikować jako proste żądanie lub żądanie wstępne.

Kryteria prostego żądania:

  • Metoda to GET, HEAD lub POST.
  • Niestandardowe nagłówki to tylko Accept, Accept-Language, Content-Language i Content-Type.
  • Wartość „Content-Type” to application/x-www-form-urlencoded, multipart/form-data lub text/plain.

Wszystkie pozostałe są klasyfikowane jako żądania wstępne. Aby dowiedzieć się więcej, zapoznaj się z informacjami o współdzieleniu zasobów między pochodzeniem (CORS) – HTTP | MDN.

Proste żądanie

Jeśli żądanie spełnia proste kryteria żądania, przeglądarka wysyła komunikat żądanie z innej domeny z nagłówkiem Origin wskazującym pochodzeniu danych.

Przykładowy nagłówek żądania

Get / HTTP/1.1
Origin: https://example.com

Przykładowy nagłówek odpowiedzi

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com oznacza, że https://example.com ma dostęp do treści odpowiedzi. Przeznaczone zasoby aby była możliwa do odczytania przez dowolną witrynę, może ustawić ten nagłówek na wartość *, w którym to przypadku przeglądarka będzie wymagać jedynie żądania wysyłanego bez dane logowania.
  • Access-Control-Allow-Credentials: true wskazuje, że żądania, które zawierają przenoszenie dane logowania (pliki cookie) mogą służyć do wczytywania zasobu. W przeciwnym razie uwierzytelnione żądania będą odrzucane, nawet jeśli źródło żądania jest w nagłówku Access-Control-Allow-Origin.

Możesz sprawdzić, jak proste żądanie wpływa na ładowanie zasobów w środowisko Cross-Origin-Embedder-Policy: require-corp na tym wersji demonstracyjnej. Kliknij pole wyboru Udostępnianie zasobów między serwerami z różnych domen i kliknij Załaduj obraz ponownie. aby zobaczyć efekt.

Żądania wstępne

Żądanie wstępne jest poprzedzone żądaniem OPTIONS sprawdzające, czy może zostać wysłane kolejne żądanie.

Przykładowy nagłówek żądania

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST umożliwia wysłanie następującego żądania metody POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type zezwala na: żądający ustawienia nagłówków HTTP X-PINGOTHER i Content-Type w sekcji kolejne żądanie.

Przykładowe nagłówki odpowiedzi

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS oznacza, że kolejne żądania mogą być wysyłane za pomocą metod POST, GET i OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type oznacza następny mogą zawierać nagłówki X-PINGOTHER i Content-Type.
  • Access-Control-Max-Age: 86400 wskazuje, że wynik etapu wstępnego może być przechowywane w pamięci podręcznej przez 86 400 sekund.

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 4.
  • Krawędź: 12.
  • Firefox: 3.5
  • Safari: 4.

Źródło

Więcej informacji

Zasady dotyczące umieszczania treści z różnych domen (COEP)

Aby ograniczyć skuteczność ataków, aby kradzież zasobów z innych domen, funkcji takich jak SharedArrayBuffer czy performance.measureUserAgentSpecificMemory() są domyślnie wyłączone.

Cross-Origin-Embedder-Policy: require-corp uniemożliwia dostęp do dokumentów i instancji roboczych wczytywanie zasobów z innych domen, takich jak obrazy, skrypty, arkusze stylów, elementy iframe inne, chyba że zasoby te wyraźnie zgadzają się na ładowanie przez CORS. lub CORP. Koszt własny sprzedaży można połączyć z usługą Cross-Origin-Opener-Policy aby włączyć w dokumencie izolację zasobów z innych domen.

Aby włączyć, użyj Cross-Origin-Embedder-Policy: require-corp izolację zasobów z innych domen w przypadku dokumentu.

Przykład użycia

Cross-Origin-Embedder-Policy: require-corp
Jak korzystać z COEP

Przykładowe zastosowania

COEP przyjmuje pojedynczą wartość require-corp. Wysyłając ten nagłówek, możesz poinstruuj przeglądarkę, aby blokowała wczytywanie zasobów, które nie wyrażają zgody przez CORS lub CORP.

Jak działa model COEP

Możesz wypróbować, jak poniższe konfiguracje wpływają na ładowanie zasobów na tym wersji demonstracyjnej. Zmień w menu Cross-Origin-Embedder-Policy Menu Cross-Origin-Resource-Policy, pole wyboru Cross-Origin-Resource-Policy itp. aby zobaczyć, jak wpływają one na ładowanie zasobów. Otwórz też punkt końcowy raportowania demo, aby sprawdzić, czy zablokowane zasoby zostało zgłoszone.

Włącz izolację zasobów z innych domen

Włącz izolację zasobów z innych domen, wysyłając e-maila Cross-Origin-Embedder-Policy: require-corp wraz z Cross-Origin-Opener-Policy: same-origin 

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

Zasoby raportu niezgodne z COEP

Dzięki raportowi możesz otrzymywać raporty o zablokowanych zasobach spowodowanych przez koszt własny sprzedaży API.

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP obsługuje też tryb „Tylko raporty”, dzięki czemu możesz otrzymywać raporty bez blokując ładowanie zasobów.

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2

Źródło

Więcej informacji

HSTS (HTTP Strict Transport Security)

Komunikacja przez zwykłe połączenie HTTP nie jest szyfrowana, przez co przesłanych danych dostępnych dla osób podsłuchujących na poziomie sieci.

Nagłówek Strict-Transport-Security informuje przeglądarkę, że nigdy nie powinna się ona wczytywać z witryny korzystającej z protokołu HTTP, a zamiast tego użyj protokołu HTTPS. Po jej skonfigurowaniu przeglądarka używa HTTPS zamiast HTTP – dostęp do domeny przez określony czas bez przekierowania zdefiniowane w nagłówku.

Przykład użycia

Strict-Transport-Security: max-age=31536000
Jak korzystać z HSTS

Wszystkie witryny przechodzące z HTTP na HTTPS powinny zwracać błąd Nagłówek Strict-Transport-Security po otrzymaniu żądania HTTP. 

Strict-Transport-Security: max-age=31536000

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 4.
  • Krawędź: 12.
  • Firefox: 4.
  • Safari: 7.

Źródło

Więcej informacji

Więcej informacji