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

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

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

W tym artykule znajdziesz listę najważniejszych nagłówków zabezpieczeń, których możesz użyć do ochrony swojej witryny. Korzystaj z niej, aby poznać funkcje zabezpieczeń internetowych i dowiedzieć się, jak je wdrożyć w swojej witrynie. Możesz też do niej wracać, gdy będziesz potrzebować przypomnienia.

Nagłówki zabezpieczeń zalecane w przypadku witryn, które przetwarzają dane wrażliwe użytkowników:
Content Security Policy (CSP)
Trusted Types
Nagłówki zabezpieczeń zalecane w przypadku 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ń w przypadku witryn o zaawansowanych możliwościach:
Współdzielenie zasobów pomiędzy serwerami z różnych domen (CORS)
Zasady osadzania z różnych domen (COEP)
Znane zagrożenia w internecie
Zanim przejdziesz do nagłówków bezpieczeństwa, dowiedz się więcej o znanych zagrożeniach w internecie i o tym, dlaczego warto używać tych nagłówków.

Zanim przejdziesz do nagłówków bezpieczeństwa, dowiedz się więcej o znanych zagrożeniach w internecie i o tym, dlaczego warto używać tych nagłówków.

Ochrona witryny przed lukami w zabezpieczeniach związanymi z wstrzykiwaniem kodu

Luki w zabezpieczeniach związane z wstrzykiwaniem pojawiają się, gdy niezaufane dane przetwarzane przez aplikację mogą wpływać na jej działanie i zwykle prowadzą do uruchomienia skryptów kontrolowanych przez osobę przeprowadzającą atak. Najczęstszą luką w zabezpieczeniach spowodowaną przez błędy wstrzykiwania jest skryptowanie między witrynami (XSS) w różnych formach, w tym odzwierciedlony XSS, przechowywany XSS, XSS oparty na DOM i inne warianty.

Luka w zabezpieczeniach XSS może zwykle zapewnić atakującemu pełny dostęp do danych użytkownika przetwarzanych przez aplikację i wszelkich innych informacji hostowanych w tym samym pochodzeniu internetowym.

Tradycyjne metody ochrony przed atakami typu injection obejmują konsekwentne stosowanie systemów szablonów HTML z automatycznym unikaniem znaków specjalnych, unikanie niebezpiecznych interfejsów JavaScript API oraz prawidłowe przetwarzanie danych użytkowników przez hostowanie przesyłanych plików w osobnej domenie i oczyszczanie kontrolowanego przez użytkownika kodu HTML.

  • Używaj standardu Content Security Policy (CSP), aby kontrolować, które skrypty mogą być wykonywane przez aplikację, i zmniejszać ryzyko wstrzyknięć.
  • Używaj Trusted Types, aby wymuszać czyszczenie danych przekazywanych do niebezpiecznych interfejsów JavaScript API.
  • Użyj X-Content-Type-Options, aby zapobiec błędnej interpretacji przez przeglądarkę typów MIME zasobów witryny, co może prowadzić do wykonania skryptu.

Izolowanie witryny od innych witryn

Otwartość internetu umożliwia witrynom wchodzenie ze sobą w interakcje w sposób, który może naruszać oczekiwania aplikacji dotyczące bezpieczeństwa. Może to obejmować nieoczekiwane wysyłanie uwierzytelnionych żądań lub osadzanie danych z innej aplikacji w dokumencie osoby przeprowadzającej atak, co umożliwia jej modyfikowanie lub odczytywanie danych aplikacji.

Typowe luki w zabezpieczeniach, które podważają izolację witryn, to clickjacking, fałszowanie żądań z innych witryn (CSRF), ataki typu cross-site script inclusion (XSSI) i różne wycieki danych z innych witryn.

Jeśli interesują Cię te nagłówki, warto przeczytać artykuł Post-Spectre Web Development.

Bezpieczne tworzenie zaawansowanych witryn

Spectre umieszcza wszystkie wczytane dane w tej samej grupie kontekstu przeglądania, co potencjalnie umożliwia ich odczytanie pomimo zasad dotyczących tego samego pochodzenia. Przeglądarki ograniczają funkcje, które mogą wykorzystywać lukę w zabezpieczeniach w specjalnym środowisku zwanym „izolacją z różnych źródeł”. Dzięki izolacji między źródłami możesz korzystać z zaawansowanych funkcji, takich jak SharedArrayBuffer.

Szyfrowanie ruchu w witrynie

Problemy z szyfrowaniem pojawiają się, gdy aplikacja nie szyfruje w pełni danych podczas przesyłania, co umożliwia atakującym podsłuchiwanie interakcji użytkownika z aplikacją.

Niewystarczające szyfrowanie może wystąpić w tych przypadkach: nieużywanie protokołu HTTPS, treści mieszane, ustawianie plików cookie bez atrybutu Secure (lub prefiksu __Secure) albo nieścisła logika weryfikacji CORS.

Content Security Policy (CSP)

Cross-site scripting (XSS) to atak, w którym luka w zabezpieczeniach witryny umożliwia wstrzyknięcie i wykonanie złośliwego skryptu.

Content-Security-Policy stanowi dodatkową warstwę zabezpieczeń przed atakami XSS, ponieważ ogranicza skrypty, które mogą być wykonywane na stronie.

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

  • Jeśli renderujesz strony HTML na serwerze, użyj ścisłego CSP opartego na jednorazowym kodzie.
  • Jeśli kod HTML musi być dostarczany statycznie lub buforowany, np. w przypadku aplikacji jednostronicowej, użyj ścisłej zasady CSP opartej na haszowaniu.

Przykład użycia: CSP oparty na jednorazowym kodzie

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

1. Używanie ścisłej strategii CSP opartej na jednorazowym kodzie {: #nonce-based-csp}

Jeśli renderujesz strony HTML na serwerze, użyj ścisłego CSP opartego na jednorazowym kodzie.

Wygeneruj nową wartość nonce skryptu dla każdego żądania po stronie serwera i ustaw ten nagłówek:

plik konfiguracyjny serwera,

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

Aby wczytać skrypty w HTML, ustaw atrybut nonce wszystkich tagów <script> na 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 ścisłej strategii CSP opartej na jednorazowym kodzie. Użyj Narzędzi deweloperskich, aby sprawdzić, jak jest używany.

2. Używanie rygorystycznej zasady CSP opartej na haszowaniu {: #hash-based-csp}

Jeśli Twój kod HTML musi być wyświetlany statycznie lub buforowany, np. w przypadku tworzenia aplikacji jednostronicowej, użyj ścisłej strategii CSP opartej na haszowaniu.

plik konfiguracyjny serwera,

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

W HTML-u musisz wstawić skrypty w kodzie, aby zastosować zasady oparte na haszowaniu, 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ę „Dynamiczne wczytywanie skryptów źródłowych” w części Opcja B. Nagłówek odpowiedzi CSP oparty na haszowaniu.

CSP Evaluator to dobre narzędzie do oceny CSP, a zarazem dobry przykład rygorystycznych CSP opartych na identyfikatorze liczby jednorazowej. Użyj Narzędzi deweloperskich, aby sprawdzić, jak jest używany.

Obsługiwane przeglądarki

Inne informacje o CSP

Więcej informacji

Zaufane typy

Atak XSS oparty na DOM polega na przekazaniu złośliwych danych do miejsca docelowego, które obsługuje dynamiczne wykonywanie kodu, np. eval() lub .innerHTML.

Trusted Types udostępnia narzędzia do pisania, sprawdzania pod kątem bezpieczeństwa i utrzymywania aplikacji wolnych od ataków typu XSS opartych na DOM. Można je włączyć za pomocą CSP. Zapewniają one domyślne bezpieczeństwo kodu JavaScript, ograniczając niebezpieczne interfejsy API do akceptowania tylko specjalnego obiektu – zaufanego typu.

Aby utworzyć te obiekty, możesz zdefiniować zasady bezpieczeństwa, które zapewnią spójne stosowanie reguł bezpieczeństwa (takich jak usuwanie znaków specjalnych lub oczyszczanie) przed zapisaniem danych w DOM. Te zasady są jedynymi miejscami w kodzie, które mogą potencjalnie wprowadzić DOM XSS.

Przykłady użycia

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. Wymuszanie zaufanych typów w przypadku niebezpiecznych elementów DOM Nagłówek CSP i Trusted Types: 

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

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

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

Łączenie powyższej strategii CSP opartej na jednorazowym kodzie z dyrektywą Trusted Types: 

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 dodatkową dyrektywę <code>trusted-types</code> (np. <code>trusted-types myPolicy</code>). Nie jest to jednak wymagane.  </aside>


    
  
  1. 
    
    Definiowanie zasady
    
    
    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 zasady 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 przypadku require-trusted-types-for 'script' używanie zaufanego typu 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 Twojej domeny zostanie wyświetlony złośliwy dokument HTML (np. jeśli obraz przesłany do usługi zdjęć zawiera prawidłowy znacznik HTML), niektóre przeglądarki potraktują go jako aktywny dokument i pozwolą mu wykonywać skrypty w kontekście aplikacji, co doprowadzi do błędu związanego z cross-site scriptingiem.

X-Content-Type-Options: nosniff zapobiega temu, 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ładowe użycie

X-Content-Type-Options: nosniff
Jak używać nagłówka X-Content-Type-Options

X-Content-Type-Options: nosniff jest zalecany w przypadku wszystkich zasobów wyświetlanych z serwera wraz z prawidłowym nagłówkiem Content-Type.

X-Content-Type-Options: nosniff

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

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

Obsługiwane przeglądarki

Browser Support

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

Source

Więcej informacji

X-Frame-Options

Jeśli złośliwa witryna może osadzić Twoją witrynę jako ramkę iframe, może to umożliwić atakującym wywoływanie niezamierzonych działań użytkownika za pomocą clickjackingu. W niektórych przypadkach ataki typu Spectre dają złośliwym witrynom możliwość poznania zawartości umieszczonego dokumentu.

X-Frame-Options określa, czy przeglądarka powinna mieć możliwość renderowania strony w <frame>, <iframe>, <embed> lub <object>. Wszystkie dokumenty powinny wysyłać ten nagłówek, aby wskazać, czy zezwalają na osadzanie w innych dokumentach.

Przykładowe użycie

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

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

Możesz sprawdzić, jak te konfiguracje wpływają na wczytywanie elementu iframe w tym demo. Zmień menu X-Frame-Options i kliknij przycisk Odśwież element iframe.

Ochrona witryny przed osadzaniem w innych witrynach

Odmów osadzania w innych dokumentach.

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

Chroni witrynę przed osadzaniem przez inne witryny

Zezwalaj na umieszczanie tylko w dokumentach z tej samej domeny.

X-Frame-Options: SAMEORIGIN

Obsługiwane przeglądarki

Browser Support

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

Source

Więcej informacji

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

Osoba atakująca 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-Policy zmniejsza to ryzyko, wskazując zestaw witryn, w których może być wczytywany. Nagłówek przyjmuje jedną z 3 wartości: same-origin, same-site i cross-origin. Wszystkie zasoby powinny wysyłać ten nagłówek, aby wskazać, czy zezwalają na wczytywanie przez inne witryny.

Przykładowe użycie

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

Zalecamy, aby wszystkie zasoby były wyświetlane z użyciem jednego z tych 3 nagłówków.

Możesz sprawdzić, jak te konfiguracje wpływają na wczytywanie zasobów w środowisku Cross-Origin-Embedder-Policy: require-corp na tej wersji demonstracyjnej. Zmień menu Cross-Origin-Resource-Policy i kliknij przycisk Ponownie załaduj element iframe lub Ponownie załaduj obraz, aby zobaczyć efekt.

Zezwalaj na ładowanie zasobów cross-origin

Zalecamy, aby usługi podobne do CDN stosowały atrybut cross-origin do zasobów (ponieważ są one zwykle wczytywane przez strony z innych domen), 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 zasoby do załadowania z same-origin

Atrybut same-origin należy stosować do zasobów, które mają być wczytywane tylko przez strony z tej samej domeny. Należy stosować to ustawienie w przypadku zasobów, które zawierają informacje wrażliwe 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 nadal można wczytywać bezpośrednio, np. otwierając adres URL w nowym oknie przeglądarki. Zasady dotyczące zasobów z innych domen chronią tylko przed osadzaniem zasobów w innych witrynach.

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

Ogranicz zasoby do załadowania z same-site

same-site zaleca się stosować w przypadku zasobów podobnych do powyższych, ale przeznaczonych do wczytywania przez inne subdomeny witryny.

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

Obsługiwane przeglądarki

Browser Support

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

Source

Więcej informacji

Zasady dotyczące otwierającego z innej domeny (COOP)

Witryna osoby przeprowadzającej atak może otworzyć inną witrynę w wyskakującym okienku, aby uzyskać informacje na jej temat, wykorzystując internetowe wycieki danych z innych witryn. W niektórych przypadkach może to również umożliwić wykorzystanie ataków na kanały boczne opartych na Spectre.

Nagłówek Cross-Origin-Opener-Policy umożliwia dokumentowi odizolowanie się od okien z innych domen otwieranych za pomocą window.open() lub linku z atrybutem target="_blank" bez atrybutu rel="noopener". W rezultacie otwierające dokument okno z innej domeny nie będzie miało do niego odwołania i nie będzie mogło z nim wchodzić w interakcje.

Przykładowe użycie

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

Możesz sprawdzić, jak te konfiguracje wpływają na komunikację z wyskakującym okienkiem z innej domeny, korzystając z tej wersji demonstracyjnej. Zmień ustawienie w menu Cross-Origin-Opener-Policy zarówno w przypadku dokumentu, jak i wyskakującego okienka. Kliknij przycisk Otwórz wyskakujące okienko, a potem Wyślij postMessage, aby sprawdzić, czy wiadomość została dostarczona.

Izolowanie dokumentu od okien z innych domen

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 od okien z innej domeny, ale zezwalanie na wyskakujące okienka

Ustawienie same-origin-allow-popups pozwala dokumentowi zachować odniesienie do wyskakujących okienek, chyba że ustawiono COOP z wartością same-origin lub same-origin-allow-popups. Oznacza to, że same-origin-allow-popups nadal może chronić dokument przed odwoływaniem się do niego, gdy jest otwierany w wyskakującym okienku, ale zezwalać 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 wyraźnie wskazać, że ten dokument może być otwierany przez okno z innej domeny i zachowywać wzajemny dostęp.

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

Zgłaszanie wzorców niezgodnych z COOP

Możesz otrzymywać raporty, gdy COOP uniemożliwia interakcje między oknami z interfejsem API do raportowania.

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 z różnych domen.

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

Obsługiwane przeglądarki

Browser Support

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

Source

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 mechanizm CORS (Cross-Origin Resource Sharing) nie jest nagłówkiem, ale mechanizmem przeglądarki, który żąda dostępu do zasobów z innych domen i na niego zezwala.

Domyślnie przeglądarki egzekwują zasadę tego samego pochodzenia, aby uniemożliwić stronie internetowej dostęp do zasobów z innej domeny. Na przykład gdy załadowany jest obraz z innej domeny, mimo że jest on wyświetlany na stronie internetowej, JavaScript na tej stronie nie ma dostępu do danych obrazu. Dostawca zasobu może złagodzić ograniczenia i umożliwić innym witrynom odczytywanie zasobu, akceptując CORS.

Przykładowe użycie

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

Zanim dowiesz się, jak skonfigurować CORS, warto poznać różnicę między typami żądań. W zależności od szczegółów żądania zostanie ono zaklasyfikowane jako proste żądanie 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.
  • Wartość Content-Type to application/x-www-form-urlencoded, multipart/form-data lub text/plain.

Wszystkie pozostałe żądania są klasyfikowane jako żądania wstępne. Więcej informacji znajdziesz w artykule Współdzielenie zasobów pomiędzy serwerami z różnych domen (CORS) – HTTP | MDN.

Proste żądanie

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

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 zawartości odpowiedzi. Zasoby, które mają być czytelne dla dowolnej witryny, mogą ustawić ten nagłówek na wartość *. W takim przypadku przeglądarka będzie wymagać, aby żądanie było wysyłane bez danych logowania.
  • Symbol Access-Control-Allow-Credentials: true oznacza, że żądania zawierające dane logowania (pliki cookie) mogą wczytywać zasób. W przeciwnym razie uwierzytelnione żądania będą odrzucane, nawet jeśli źródło żądania jest obecne w nagłówku Access-Control-Allow-Origin.

Możesz sprawdzić, jak proste żądanie wpływa na wczytywanie zasobów w Cross-Origin-Embedder-Policy: require-corpśrodowisku na tej wersji demonstracyjnej. Zaznacz pole wyboru mechanizm CORS i kliknij przycisk Reload the image (Ponownie załaduj obraz), aby zobaczyć efekt.

Żądania wstępne

Żądanie wstępne jest poprzedzone żądaniem OPTIONS, które sprawdza, czy można wysłać 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 tego żądania za pomocą metody POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type umożliwia osobie wysyłającej żądanie 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 oznacza, ż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

Browser Support

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

Source

Więcej informacji

Zasady umieszczania zasobów z innych domen (COEP)

Aby ograniczyć możliwość ataków opartych na Spectre w celu kradzieży zasobów z innych domen, funkcje takie jak SharedArrayBuffer czy performance.measureUserAgentSpecificMemory() są domyślnie wyłączone.

Cross-Origin-Embedder-Policy: require-corp uniemożliwia dokumentom i procesom wczytywanie zasobów z innej domeny, takich jak obrazy, skrypty, arkusze stylów, elementy iframe i inne, chyba że te zasoby wyraźnie zezwalają na wczytywanie za pomocą nagłówków CORS lub CORP. COEP można połączyć zCross-Origin-Opener-Policy aby włączyć w dokumencie izolację z innych domen.

Użyj Cross-Origin-Embedder-Policy: require-corp, jeśli chcesz włączyć izolację od zasobów z innych domen w dokumencie.

Przykładowe użycie

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

Przykłady użycia

COEP przyjmuje jedną 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 COEP

Możesz sprawdzić, jak te konfiguracje wpływają na wczytywanie zasobów, korzystając z tej wersji demonstracyjnej. Zmień menu Cross-Origin-Embedder-Policy, menu Cross-Origin-Resource-Policy, pole wyboru Report Only itp., aby zobaczyć, jak wpływają one 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 różnych domen, wysyłając 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

Zgłaszanie zasobów niezgodnych z COEP

Za pomocą interfejsu Reporting API możesz otrzymywać raporty o zablokowanych zasobach z powodu COEP.

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

COEP obsługuje też tryb tylko do raportowania, dzięki czemu możesz otrzymywać raporty bez blokowania ładowania zasobów.

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

Obsługiwane przeglądarki

Browser Support

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

Source

Więcej informacji

HTTP Strict Transport Security (HSTS)

Komunikacja za pomocą zwykłego połączenia HTTP nie jest szyfrowana, co sprawia, że przesyłane dane są dostępne dla osób podsłuchujących na poziomie sieci.

Nagłówek Strict-Transport-Security informuje przeglądarkę, że nigdy nie powinna wczytywać witryny za pomocą protokołu HTTP, tylko HTTPS. Po ustawieniu tego nagłówka przeglądarka będzie używać protokołu HTTPS zamiast HTTP, aby uzyskać dostęp do domeny bez przekierowania przez czas określony w nagłówku.

Przykładowe użycie

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 HTTP. 

Strict-Transport-Security: max-age=31536000

Obsługiwane przeglądarki

Browser Support

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

Source

Więcej informacji

Więcej informacji