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

Dowiedz się więcej o nagłówkach, które mogą zapewnić bezpieczeństwo Twojej witrynie, i szybko odnajdź najważniejsze informacje.

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

W tym artykule znajdziesz listę najważniejszych nagłówków zabezpieczeń, których możesz używać do ochrony swojej witryny. Dzięki niemu poznasz funkcje zabezpieczeń internetowych i dowiesz się, jak je wdrożyć w swojej witrynie, a także uzyskasz informacje, jeśli chcesz otrzymywać przypomnienia.

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
Cross-Origin Resource Policy (CORP)
Cross-Origin Opener Policy (COOP)
HTTP Strict Transport Security (HSTS)
Nagłówki zabezpieczeń dla witryn z zaawansowanymi funkcjami:
CORS (międzynarodowe udostępnianie zasobów)
Zasady umieszczania treści z różnych domen (COEP)
Znane zagrożenia w internecie
Zanim zaczniesz zajmować się nagłówkami bezpieczeństwa, dowiedz się więcej o znanych zagrożeniach w internecie oraz o tym, dlaczego warto używać nagłówków bezpieczeństwa.

Zanim zaczniesz zajmować się nagłówkami bezpieczeństwa, dowiedz się więcej o znanych zagrożeniach w internecie oraz o tym, dlaczego warto używać nagłówków bezpieczeństwa.

Ochrona witryny przed podatnością na ataki polegające na wstrzykiwaniu kodu

Luki związane z wstrzyknięciem występują, gdy niezaufane dane przetwarzane przez aplikację mogą wpływać na jej działanie i często prowadzić do wykonania skryptów kontrolowanych przez osobę przeprowadzającą atak. Najczęstszą luką w zabezpieczeniach spowodowaną wstrzyknięciem kodu jest skryptowanie między witrynami (XSS) w różnych formach, m.in. odbijane XSS, zapisany XSS, XSS na poziomie DOM i inne warianty.

W przypadku podatności XSS atakujący może uzyskać pełny dostęp do danych użytkownika przetwarzanych przez aplikację oraz do wszelkich innych informacji przechowywanych w tym samym źródle internetowym.

Tradycyjne zabezpieczenia przed wstrzykiwaniem obejmują stałe używanie systemów szablonów HTML z automatyczną zmianą znaczenia, unikanie stosowania niebezpiecznych interfejsów API JavaScript oraz prawidłowe przetwarzanie danych użytkownika przez hostowanie przesyłania plików do osobnej domeny i dezynfekcję kodu HTML kontrolowanego przez użytkownika.

  • Aby ograniczyć ryzyko wstrzyknięcia kodu, użyj standardu Content Security Policy (CSP), który pozwala kontrolować skrypty, które mogą być wykonywane przez aplikację.
  • Użyj zaufanych typów, aby wymusić sterylizację danych przekazywanych do niebezpiecznych interfejsów API JavaScript.
  • Użyj X-Content-Type-Options, aby zapobiec nieprawidłowej interpretacji typów MIME zasobów witryny przez przeglądarkę, co może doprowadzić do wykonania skryptu.

Izolowanie witryny od innych witryn

Otwartość internetu umożliwia witrynom wzajemną interakcję w sposób, który może naruszać oczekiwania dotyczące bezpieczeństwa aplikacji. Obejmuje to nieoczekiwane wysyłanie żądań uwierzytelnionych lub umieszczanie danych z innej aplikacji w dokumencie atakującego, co umożliwia mu modyfikowanie lub odczytywanie danych aplikacji.

Typowe luki w zabezpieczeniach, które podważają izolację w internecie, to clickjacking, fałszowanie żądań z innych witryn (CSRF), wstawianie skryptów z innych witryn (XSSI) oraz różne wycieki danych z innych witryn.

Jeśli interesują Cię nagłówki, warto przeczytać artykuł Programowanie w sieci po ujawnieniach Spectre.

Tworzenie bezpiecznej, wydajnej witryny

Spectre umieszcza wszystkie dane załadowane w ramach tej samej grupy kontekstu przeglądania, która może być odczywana pomimo zasady źródeł. Przeglądarki ograniczają funkcje, które mogą wykorzystywać podatność, do specjalnego środowiska zwanego „izolacją zasobów z innych domen”. Dzięki izolacji między domenami możesz korzystać z zaawansowanych funkcji, takich jak SharedArrayBuffer.

Szyfrowanie ruchu w witrynie

Problemy z szyfrowaniem występują, gdy aplikacja nie szyfruje w pełni danych w trakcie przesyłania, co umożliwia atakującym podsłuchującym na poznanie interakcji użytkownika z aplikacją.

Niewystarczające szyfrowanie może wystąpić w tych przypadkach: nieużywanie HTTPS, mieszane treści, ustawianie plików cookie bez atrybutu Secure (lub prefiksu __Secure) lub łagodna weryfikacja CORS.

Content Security Policy (CSP)

XSS to atak, w ramach którego luka w zabezpieczeniach witryny umożliwia wstrzyknięcie i uruchomienie złośliwego skryptu.

Content-Security-Policy zapewnia dodatkową warstwę zabezpieczeń przed atakami XSS poprzez ograniczenie skryptów, które mogą być wykonywane przez stronę.

Zalecamy włączenie rygorystycznego CSP za pomocą jednej z tych metod:

  • Jeśli renderujesz strony HTML na serwerze, użyj ścisłego CSP z noncem.
  • Jeśli kod HTML musi być obsługiwany statycznie lub przechowywany w pamięci podręcznej (np. gdy jest to aplikacja jednostronicowa), użyj dyrygencji CSP opartej na haśle.

Przykład użycia: CSP oparty na nonce

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

1. Stosowanie rygorystycznego standardu CSP opartego na łańcuchu losowych znaków {: #nonce-based-csp}

Jeśli renderujesz strony HTML na serwerze, użyj ścisłego CSP z noncem.

Wygeneruj nową wartość nonce skryptu dla każdego żądania po stronie serwera i ustaw ten 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, w atrybucie nonce wszystkich tagów <script> ustaw ten sam ciąg 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 to dobry przykład rygorystycznego CSP opartego na nonce. Użyj Narzędzi deweloperskich, aby zobaczyć, jak są one używane.

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

Jeśli kod HTML musi być wyświetlany statycznie lub przechowywany w pamięci podręcznej (np. gdy tworzysz aplikację jednostronicową), użyj ścisłego CSP opartego na haśle.

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ć zasady oparte na haśle, musisz wstawić skrypty w kodzie HTML, ponieważ większość przeglądarek nie obsługuje haszowania zewnętrznych skryptów.

index.html

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

Aby wczytać skrypty zewnętrzne, przeczytaj sekcję „Ładowanie skryptów źródłowych dynamicznie” w sekcji Opcja B: nagłówek odpowiedzi CSP oparty na haśle.

Sprawdzanie CSP to przydatne narzędzie do oceny CSP, ale jednocześnie dobry przykład rygorystycznego CSP opartego na niepowtarzalnych wartościach. Aby zobaczyć, jak jest używany, użyj Narzędzi programistycznych.

Obsługiwane przeglądarki

Inne informacje o CSP

Więcej informacji

Zaufane typy

XSS na poziomie DOM to atak, w którym złośliwe dane są przekazywane do odbiornika obsługującego dynamiczne wykonywanie kodu, np. eval() lub .innerHTML.

Zaufane typy zapewniają narzędzia do pisania, sprawdzania zabezpieczeń i utrzymywania aplikacji wolnych od ataków XSS w DOM. Można je włączyć za pomocą CSP i uzyskać bezpieczny kod JavaScript domyślnie, ograniczając niebezpieczne interfejsy API do akceptowania tylko specjalnego obiektu – zaufanej kategorii.

Aby utworzyć te obiekty, możesz zdefiniować zasady bezpieczeństwa, w których możesz zapewnić, że reguły bezpieczeństwa (takie jak ucieczka lub sterylizacja) są konsekwentnie stosowane przed zapisaniem danych do DOM. Te zasady są jedynymi miejscami w kodzie, w których można potencjalnie wprowadzić atak XSS DOM.

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. Wymuś zaufane typy w przypadku niebezpiecznych odbiorników DOM Nagłówek CSP i zaufanych typów: 

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

    Obecnie jedyną akceptowalną wartością dyrektywy require-trusted-types-for jest 'script'.

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

Łączenie CSP opartego na szyfrach jednorazowych 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ć liczbę dozwolonych nazw zasad zaufanych typów, ustawiając dodatkową dyrektywę <code>trusted-types</code> (na przykład <code>trusted-types myPolicy</code>). Nie jest to jednak wymagane.  </aside>


    
  
  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. 
    
    Stosowanie zasad
    
    
    Używaj tej zasady podczas zapisywania danych do 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 przypadku require-trusted-types-for 'script' używanie zaufanych typów jest wymagane. Użycie dowolnego niebezpiecznego interfejsu DOM API z ciągiem znaków spowoduje błąd.
    
  
    3. 



Obsługiwane przeglądarki



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Więcej informacji

X-Content-Type-Options

Gdy złośliwy dokument HTML jest wyświetlany z Twojej domeny (np. obraz przesłany do usługi do przesyłania zdjęć zawiera prawidłowy znacznik HTML), niektóre przeglądarki uznają go za aktywny dokument i pozwolą na wykonywanie skryptów w kontekście aplikacji, co spowoduje błąd skryptów między witrynami.

X-Content-Type-Options: nosniff zapobiega mu, informując przeglądarkę, że typ MIME ustawiony w nagłówku Content-Type dla danej odpowiedzi jest prawidłowy. Ten nagłówek jest zalecany w przypadku wszystkich zasobów.

Przykład użycia

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

Zalecamy użycie X-Content-Type-Options: nosniff w przypadku wszystkich zasobów wyświetlanych z Twojego serwera wraz z odpowiednim nagłówkiem Content-Type.

X-Content-Type-Options: nosniff

Przykładowe nagłówki wysyłane z dokumentem HTML

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

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Źródło

Więcej informacji

X-Frame-Options

Jeśli szkodliwa witryna może umieścić Twoją witrynę w elemencie iframe, osoby przeprowadzające ataki mogą wywołać niezamierzone działania użytkownika za pomocą funkcji clickjacking. W niektórych przypadkach ataki z wykorzystaniem widma dają też złośliwym witrynom szansę poznać treść umieszczonego dokumentu.

X-Frame-Options wskazuje, czy przeglądarka może renderować stronę w trybie <frame>, <iframe>, <embed> lub <object>. Zalecamy, aby wszystkie dokumenty wysyłały ten nagłówek, aby wskazać, czy można je umieszczać w innych dokumentach.

Przykład użycia

X-Frame-Options: DENY
Jak korzystać z nagłówka X-Frame-Options

Wszystkie dokumenty, które nie są przeznaczone do umieszczania w innych dokumentach, powinny mieć nagłówek X-Frame-Options.

W tej prezentacji możesz zobaczyć, jak poniższe konfiguracje wpływają na wczytywanie elementu iframe. Zmień menu X-Frame-Options i kliknij przycisk Załaduj ponownie element iframe.

Chroni Twoją witrynę przed umieszczeniem w innych witrynach

odmówić umieszczenia w żadnym innym dokumencie.

X-Frame-Options: DENY 
X-Frame-Options: DENY

Chroni witrynę przed umieszczaniem jej przez dowolne witryny między domenami.

Zezwalanie na umieszczanie tylko w dokumentach z tego samego źródła.

X-Frame-Options: SAMEORIGIN

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Źródło

Więcej informacji

Zasady dotyczące zasobów z innych domen (CORP)

Osoba przeprowadzająca atak może umieścić zasoby z innego źródła, np. z Twojej witryny, aby uzyskać o nich informacje, wykorzystując wycieki danych z innych witryn.

Cross-Origin-Resource-Policyzmniejsza to ryzyko, podając zestaw witryn, z których może być ładowany. Nagłówek może mieć jedną z 3 wartości: same-origin, same-site lub cross-origin. Zalecamy, aby wszystkie zasoby wysyłały ten nagłówek, aby wskazać, czy zezwalają na wczytywanie ich przez inne witryny.

Przykład użycia

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

Zalecamy, aby wszystkie zasoby były udostępniane pod jednym z tych 3 nagłówków.

W tej prezentacji możesz zobaczyć, jak poniższe konfiguracje wpływają na ładowanie zasobów w środowisku Cross-Origin-Embedder-Policy: require-corp. Aby zobaczyć efekt, zmień menu cross-Origin-Resource-Policy i kliknij przycisk Załaduj ponownie element iframe lub Załaduj obraz ponownie.

Zezwalaj na ładowanie zasobów cross-origin

Zalecamy, aby usługi podobne do CDN stosowały tag cross-origin do zasobów (ponieważ są one zwykle ładowane przez strony z różnych źródeł), chyba że są już dostarczane za pomocą CORS, co ma podobny efekt.

Cross-Origin-Resource-Policy: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

Ogranicz ładowanie zasobów z same-origin

Tag same-origin należy zastosować do zasobów, które mają być wczytywane tylko przez strony z tego samego źródła. Należy go zastosować do zasobów zawierających informacje poufne 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 wczytywać bezpośrednio, na przykład przez przejście do adresu URL w nowym oknie przeglądarki. Zasada Cross-Origin Resource Sharing chroni zasób tylko 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 zastosowanie reguły same-site do zasobów podobnych do wymienionych powyżej, które mają być wczytywane przez inne subdomeny Twojej witryny.

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Źródło

Więcej informacji

Zasada dotycząca otwierającego z innej domeny (COOP)

Witryna atakującego może otworzyć inną witrynę w wyskakującym okienku, aby poznać informacje o tej witrynie, wykorzystując wycieki między witrynami w sieci. W niektórych przypadkach może to też umożliwiać przeprowadzanie ataków typu side-channel na podstawie Spectre.

Nagłówek Cross-Origin-Opener-Policy umożliwia dokumentowi odseparowanie się od okien między domenami, które zostały otwarte za pomocą window.open() lub linku z target="_blank" bez rel="noopener". W rezultacie każda osoba, która otworzy dokument w innej domenie, nie będzie miała do niego dostępu i nie będzie mogła z nim wchodzić w interakcję.

Przykład użycia

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

W tym demonstracyjnym pliku możesz sprawdzić, jak te konfiguracje wpływają na komunikację z oknem wyskakującym z innej domeny. Zmień menu Cross-Origin-Opener-Policy zarówno w dokumentach, jak i w wyskakujących oknach, kliknij przycisk Otwórz wyskakujące okienko, a potem kliknij Wyślij postMessage, aby sprawdzić, czy wiadomość została faktycznie dostarczona.

Izolowanie dokumentu z okien między domenami

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

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

Izolowanie dokumentu z okien między źródłami, ale zezwalanie na wyskakujące okienka

Ustawienie same-origin-allow-popups pozwala dokumentowi zachować odwołanie do okienek wyskakujących, chyba że ustawiono w nich opcję COOP z wartością same-origin lub same-origin-allow-popups. Oznacza to, że same-origin-allow-popups może nadal chronić dokument przed odniesieniami, gdy jest otwierany jako wyskakujące okienko, ale może też komunikować się z własnymi wyskakującymi okienkami.

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

Zezwalanie na odwoływanie się do dokumentu przez okna między domenami

unsafe-none to wartość domyślna, ale możesz wyraźnie wskazać, że ten dokument może być otwierany przez okno z innej domeny i zachować wzajemny dostęp.

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

Zgłaszanie wzorców niezgodnych z COOP

Możesz otrzymywać raporty, gdy coOP uniemożliwi interakcje z różnymi okresami za pomocą interfejsu Reporting API.

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

COOP obsługuje też tryb tylko do raportowania, dzięki czemu możesz otrzymywać raporty bez blokowania komunikacji między dokumentami w różnych domenach.

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 odróżnieniu od innych elementów w tym artykule współdzielenie zasobów między serwerami z różnych domen (CORS) nie jest nagłówkiem, ale mechanizmem przeglądarki, który prosi o dostęp do zasobów z innych domen i go zezwala.

Domyślnie przeglądarki wymuszają zasadę dotyczącą tej samej domeny, aby uniemożliwić stronie dostęp do zasobów z innych domen. Na przykład podczas wczytywania obrazu z innej domeny, mimo że jest on wyświetlany na stronie internetowej, kod JavaScript na stronie nie ma dostępu do danych obrazu. Dostawca zasobu może złagodzić ograniczenia i zezwolić innym witrynom na odczyt zasobu, akceptując CORS.

Przykład użycia

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

Zanim zapoznasz się z sposobem konfigurowania CORS, warto poznać różnicę między typami żądań. W zależności od szczegółów żądania żądanie może być klasyfikowane jako proste lub żądanie wstępne.

Kryteria prostego żądania:

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

Pozostałe żądania są klasyfikowane jako żądania z wstępnym przefiltrowaniem. Więcej informacji znajdziesz w artykule na temat współdzielenia zasobów pomiędzy serwerami z różnych domen (CORS) – HTTP | MDN.

Proste żądanie

Jeśli żądanie spełnia kryteria żądania prostego, przeglądarka wysyła żądanie z innej domeny z nagłówkiem Origin, który wskazuje origin żądania.

Przykład nagłówka żądania

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

Przykład nagłówka odpowiedzi

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com wskazuje, że https://example.com ma dostęp do zawartości odpowiedzi. Zasoby, które mają być czytelne dla każdej witryny, mogą ustawić w nagłówku *. W takim przypadku przeglądarka wymaga jedynie przesłania żądania bez danych logowania.
  • Access-Control-Allow-Credentials: true wskazuje, że zasób może być ładowany przez żądania zawierające dane logowania (pliki cookie). W przeciwnym razie uwierzytelnione żądania będą odrzucane, nawet jeśli źródło żądania jest obecne w nagłówku Access-Control-Allow-Origin.

W tej prezentacji możesz zobaczyć, jak proste żądanie wpływa na ładowanie zasobów w środowisku Cross-Origin-Embedder-Policy: require-corp. Aby zobaczyć efekt, kliknij pole wyboru Udostępnianie zasobów w wielu domenach i przycisk Ponowne wczytywanie obrazu.

Żądania z wstępnym ładowaniem

Prośba o prześwietlenie poprzedza żądanie OPTIONS, które ma na celu sprawdzenie, czy można wysłać następne żądanie.

Przykład nagłówka żą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 tego żądania za pomocą metody POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type zezwala żądającemu na ustawienie nagłówków HTTP X-PINGOTHER i Content-Type w kolejnym żądaniu.

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 wskazuje, że kolejne żądania można wysyłać za pomocą metod POST, GET i OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type oznacza, że kolejne żądania mogą zawierać nagłówki X-PINGOTHER i Content-Type.
  • Access-Control-Max-Age: 86400 oznacza, że wynik żądania wstępnego może być przechowywany w pamięci podręcznej przez 86 400 sekund.

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3,5.
  • Safari: 4.

Źródło

Więcej informacji

Zasady umieszczania zasobów z innych domen (COEP)

Aby ograniczyć możliwość ataków typu Spectre polegających na kradzieży zasobów z innych witryn, funkcje takie jak SharedArrayBuffer lub performance.measureUserAgentSpecificMemory() są domyślnie wyłączone.

Cross-Origin-Embedder-Policy: require-corp uniemożliwia wczytywanie zasobów z innych domen, takich jak obrazy, skrypty, arkusze stylów, ramki iframe i inne, chyba że zasoby te zostały wyraźnie wybrane do wczytania za pomocą nagłówków CORS lub CORP. CoEP można połączyć z usługąCross-Origin-Opener-Policy, aby włączyć w dokumencie izolację zasobów z innych domen.

Użyj Cross-Origin-Embedder-Policy: require-corp, gdy chcesz włączyć izolację między domenami w dokumencie.

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 poinstruować przeglądarkę, aby blokowała wczytywanie zasobów, które nie zostały zaakceptowane za pomocą CORS lub CORP.

Jak działa model COEP

W tym demo możesz sprawdzić, jak poszczególne konfiguracje wpływają na wczytywanie zasobów. Zmień menu Zasady umieszczania zasobów z innych domen, Zasady dotyczące zasobów z innych domen, pole wyboru Tylko raport itp., aby sprawdzić, jak te zmiany wpływają na wczytywanie zasobów. Otwórz też demo punktu końcowego raportowania, aby sprawdzić, czy zablokowane zasoby są zgłaszane.

Włącz izolację między domenami

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

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

Zgłaszanie zasobów niezgodnych z COEP

Za pomocą interfejsu Reporting API możesz otrzymywać raporty o zablokowanych zasobach spowodowanych przez koszt własny sprzedaży.

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

COEP obsługuje też tryb tylko do zgłaszania, dzięki czemu możesz otrzymywać zgłoszenia bez blokowania ładowania 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

HTTP Strict Transport Security (HSTS)

Komunikacja przez zwykłe połączenie HTTP nie jest szyfrowana, przez co przesyłane dane są dostępne dla podsłuchujących na poziomie sieci.

Nagłówek Strict-Transport-Security informuje przeglądarkę, że nie powinna ładować witryny przez HTTP, tylko używać protokołu HTTPS. Gdy to zrobisz, przeglądarka będzie używać HTTPS zamiast HTTP, by uzyskiwać dostęp do domeny bez przekierowania przez czas zdefiniowany w nagłówku.

Przykład użycia

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

Wszystkie witryny, które przechodzą z HTTP na HTTPS, powinny odpowiadać nagłówkiem Strict-Transport-Security, gdy otrzymają żądanie w protokole HTTP. 

Strict-Transport-Security: max-age=31536000

Obsługiwane przeglądarki

Obsługa przeglądarek

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Źródło

Więcej informacji

Więcej informacji