Kurzübersicht zu Sicherheitsheadern

Hier erhalten Sie weitere Informationen zu Headern, die zum Schutz Ihrer Website beitragen und einen schnellen Überblick über die wichtigsten Details geben.

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

In diesem Artikel werden die wichtigsten Sicherheitsheader aufgeführt, die Sie zum Schutz Ihrer Website verwenden können. Sie können damit webbasierte Sicherheitsfunktionen kennenlernen, erfahren, wie Sie sie auf Ihrer Website implementieren, und als Referenz verwenden, wenn Sie eine Erinnerung benötigen.

Sicherheits-Header, die für Websites empfohlen werden, auf denen vertrauliche Nutzerdaten verarbeitet werden:
Content Security Policy (CSP)
Vertrauenswürdige Typen
Für alle Websites empfohlene Sicherheits-Header:
X-Content-Type-Options
X-Frame-Options
Cross-Origin Resource Policy (CORP)
Cross-Origin Opener Policy (COOP)
HTTP Strict Transport Security (HSTS)
Sicherheits-Header für Websites mit erweiterten Funktionen:
Cross-Origin Resource Sharing (CORS)
Cross-Origin Embedder Policy (COEP)
Bekannte Bedrohungen im Web
Bevor Sie sich mit den Sicherheitsheadern befassen, informieren Sie sich über bekannte Bedrohungen im Web und warum Sie diese Sicherheitsheader verwenden sollten.

Bevor Sie sich mit Sicherheits-Headern befassen, sollten Sie sich über bekannte Bedrohungen im Web informieren und darüber, warum Sie diese Sicherheits-Header verwenden sollten.

Ihre Website vor Injection-Sicherheitslücken schützen

Injection-Sicherheitslücken entstehen, wenn nicht vertrauenswürdige Daten, die von Ihrer Anwendung verarbeitet werden, ihr Verhalten beeinträchtigen und häufig zur Ausführung von von Angreifern kontrollierten Skripts führen. Die häufigste Sicherheitslücke, die durch Injection-Bugs verursacht wird, ist Cross-Site-Scripting (XSS) in seinen verschiedenen Formen, einschließlich reflektiertem XSS, gespeichertem XSS, DOM-basiertem XSS und anderen Varianten.

Eine XSS-Sicherheitslücke kann einem Angreifer in der Regel vollständigen Zugriff auf von der Anwendung verarbeitete Nutzerdaten und alle anderen Informationen gewähren, die am selben Web-Ursprung gehostet werden.

Herkömmliche Abwehrmaßnahmen gegen Injektionen beinhalten die konsequente Verwendung von HTML-Vorlagensystemen mit automatischem Escaping, die Vermeidung gefährlicher JavaScript APIs und die ordnungsgemäße Verarbeitung von Nutzerdaten durch das Hosten von Dateiuploads in einer separaten Domain und die Bereinigung von nutzergesteuertem HTML-Code.

  • Mit einer Content Security Policy (CSP) können Sie steuern, welche Scripts von Ihrer Anwendung ausgeführt werden dürfen, um das Risiko von Injections zu verringern.
  • Verwenden Sie Trusted Types, um die Bereinigung von Daten zu erzwingen, die an gefährliche JavaScript-APIs übergeben werden.
  • Verwenden Sie X-Content-Type-Options, um zu verhindern, dass der Browser die MIME-Typen der Ressourcen Ihrer Website falsch interpretiert, was zur Ausführung von Scripts führen kann.

Website von anderen Websites isolieren

Aufgrund der Offenheit des Webs können Websites auf eine Weise miteinander interagieren, die gegen die Sicherheitsanforderungen einer Anwendung verstößt. Dazu gehören unerwartete authentifizierte Anfragen oder das Einbetten von Daten aus einer anderen Anwendung in das Dokument des Angreifers, wodurch er Anwendungsdaten ändern oder lesen kann.

Zu den gängigen Sicherheitslücken, die die Webisolation untergraben, gehören Clickjacking, Cross-Site-Request-Forgery (CSRF), Cross-Site-Script-Inclusion (XSSI) und verschiedene Cross-Site-Lecks.

Post-Spectre Web Development ist ein empfehlenswerter Artikel, wenn Sie sich für diese Header interessieren.

Eine leistungsstarke Website sicher erstellen

Spectre ordnet alle geladenen Daten derselben Browserkontextgruppe zu, die trotz der Richtlinie zum gleichen Ursprung potenziell lesbar ist. Browser schränken Funktionen ein, die die Sicherheitslücke in einer speziellen Umgebung namens Cross-Origin-Isolation ausnutzen könnten. Mit der plattformübergreifenden Isolation können Sie leistungsstarke Funktionen wie SharedArrayBuffer nutzen.

Traffic auf Ihre Website verschlüsseln

Verschlüsselungsprobleme treten auf, wenn eine Anwendung Daten nicht vollständig verschlüsselt. Angreifer können dann die Interaktionen der Nutzer mit der Anwendung mithören.

Unzureichende Verschlüsselung kann in folgenden Fällen auftreten: kein HTTPS, gemischte Inhalte, das Festlegen von Cookies ohne das Attribut Secure (oder das Präfix __Secure) oder die laxe CORS-Validierungslogik.

Content Security Policy (CSP)

Ein Cross-Site-Scripting-Angriff (XSS) ist ein Angriff, bei dem eine Sicherheitslücke auf einer Website dazu führt, dass ein schädliches Script eingefügt und ausgeführt wird.

Content-Security-Policy bietet eine zusätzliche Ebene zur Abwehr von XSS-Angriffen. Dabei wird eingeschränkt, welche Skripts von der Seite ausgeführt werden können.

Wir empfehlen, die strikte CSP mit einem der folgenden Ansätze zu aktivieren:

  • Wenn Sie Ihre HTML-Seiten auf dem Server rendern, verwenden Sie eine strikte CSP, die auf Nonce-Werten beruht.
  • Wenn Ihr HTML-Code statisch bereitgestellt oder im Cache gespeichert werden muss, z. B. bei einer Single-Page-Anwendung, verwenden Sie eine hashbasierte strenge CSP.

Beispiel für die Verwendung: Ein noncebasierter CSP

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

1. Nonce-basierte strikte CSP verwenden {: #nonce-based-csp}

Wenn Sie Ihre HTML-Seiten auf dem Server rendern, verwenden Sie eine Nonce-basierte strikte CSP.

Generieren Sie für jede Anfrage auf der Serverseite einen neuen Script-Nonce-Wert und legen Sie den folgenden Header fest:

Serverkonfigurationsdatei

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

Um die Skripts in HTML zu laden, setzen Sie das Attribut nonce aller <script>-Tags auf denselben {RANDOM1}-String.

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>

Google Fotos ist ein gutes Beispiel für eine strikte CSP, die auf Nonce-Werten beruht. Mit den DevTools können Sie sehen, wie es verwendet wird.

2. Hashbasierte strenge CSP verwenden {: #hash-based-csp}

Wenn Ihr HTML-Code statisch bereitgestellt oder im Cache gespeichert werden muss, z. B. wenn Sie eine Single-Page-Anwendung erstellen, verwenden Sie eine hashbasierte strenge CSP.

Serverkonfigurationsdatei

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

In HTML müssen Sie Ihre Skripts inline einfügen, um eine hashbasierte Richtlinie anzuwenden, da die meisten Browser das Hashen externer Skripts nicht unterstützen.

index.html

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

Informationen zum Laden externer Scripts finden Sie im Abschnitt Option B: Hash-basierter CSP-Antwortheader unter „Externe Scripts dynamisch laden“.

Der CSP-Evaluator ist ein gutes Tool zur Bewertung Ihrer CSP, aber gleichzeitig auch ein gutes Beispiel für eine noncebasierte strenge CSP. Verwende die Entwicklertools, um zu sehen, wie sie verwendet wird.

Unterstützte Browser

Weitere Hinweise zu CSP

Weitere Informationen

Vertrauliche Typen

Bei einem DOM-basierten XSS-Angriff werden schädliche Daten an einen Empfänger übergeben, der die dynamische Codeausführung unterstützt, z. B. eval() oder .innerHTML.

Trusted Types bieten die Tools zum Erstellen, Sicherheitsüberprüfen und Verwalten von Anwendungen ohne DOM-XSS. Sie können über CSP aktiviert werden und JavaScript-Code standardmäßig sicher machen. Gefährliche Web-APIs akzeptieren dabei nur ein bestimmtes Objekt – einen vertrauenswürdigen Typ.

Zum Erstellen dieser Objekte können Sie Sicherheitsrichtlinien definieren, mit denen Sie dafür sorgen können, dass Sicherheitsregeln (z. B. Entkommentierung oder Bereinigung) konsequent angewendet werden, bevor die Daten in das DOM geschrieben werden. Diese Richtlinien sind dann die einzigen Stellen im Code, an denen potenziell DOM-XSS auftreten kann.

Anwendungsbeispiele

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;
Vertrauenswürdige Typen verwenden

  1. Vertrauenswürdige Typen für gefährliche DOM-Auffangstellen erzwingen CSP- und Trusted Types-Header: 

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

    Derzeit ist 'script' der einzige zulässige Wert für die require-trusted-types-for-Richtlinie.

    Natürlich können Sie vertrauenswürdige Typen mit anderen CSP-Anweisungen kombinieren:

So führen Sie eine noncebasierte CSP aus dem Beispiel oben mit vertrauenswürdigen Typen zusammen: 

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>Hinweis: </b> Sie können zulässige Richtliniennamen für vertrauenswürdige Typen einschränken, indem Sie eine zusätzliche Richtlinie <code>trusted-types</code> festlegen (z. B. <code>trusted-types myPolicy</code>). Dies ist jedoch keine Voraussetzung.  </aside>


    
  
  1. 
    
    Richtlinie definieren
    
    
    Richtlinie:
    
    
    // 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. 
    
    Richtlinie anwenden
    
    
    Verwenden Sie die Richtlinie, wenn Sie Daten in das DOM schreiben:
    
    
    // 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;
    
    
    Bei require-trusted-types-for 'script' ist die Verwendung eines vertrauenswürdigen Typs erforderlich. Die Verwendung einer gefährlichen DOM API mit einem String führt zu einem Fehler.
    
  
    3. 



Unterstützte Browser



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Weitere Informationen

X-Content-Type-Options

Wenn ein schädliches HTML-Dokument von Ihrer Domain ausgeliefert wird (z. B. wenn ein auf einen Fotodienst hochgeladenes Bild gültiges HTML-Markup enthält), behandeln einige Browser es als aktives Dokument und erlauben die Ausführung von Scripts im Kontext der Anwendung. Dies führt zu einem Cross-Site-Scripting-Fehler.

X-Content-Type-Options: nosniff verhindert dies, indem der Browser angewiesen wird, dass der MIME-Typ, der im Content-Type-Header für eine bestimmte Antwort festgelegt ist, korrekt ist. Dieser Header wird für alle Ressourcen empfohlen.

Beispiel

X-Content-Type-Options: nosniff
X-Content-Type-Options verwenden

X-Content-Type-Options: nosniff wird für alle Ressourcen, die von deinem Server bereitgestellt werden, zusammen mit dem richtigen Content-Type-Header empfohlen.

X-Content-Type-Options: nosniff

Beispiel-Header, die mit dem HTML-Code eines Dokuments gesendet werden

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

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

X-Frame-Options

Wenn eine schädliche Website Ihre Website als Iframe einbetten kann, können Angreifer mit Clickjacking unbeabsichtigte Aktionen des Nutzers auslösen. Außerdem können Spectre-Angriffe in einigen Fällen schädlichen Websites die Möglichkeit geben, den Inhalt eines eingebetteten Dokuments zu erfahren.

X-Frame-Options gibt an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern darf. Wir empfehlen, für alle Dokumente diese Kopfzeile zu senden, um anzugeben, ob sie von anderen Dokumenten eingebettet werden dürfen.

Beispiel

X-Frame-Options: DENY
Verwendung von X-Frame-Options

Für alle Dokumente, die nicht eingebettet werden sollen, sollte der X-Frame-Options-Header verwendet werden.

In dieser Demo können Sie ausprobieren, wie sich die folgenden Konfigurationen auf das Laden eines iFrames auswirken. Ändern Sie das Drop-down-Menü X-Frame-Options und klicken Sie auf die Schaltfläche Iframe neu laden.

Schützt Ihre Website vor dem Einbetten in anderen Websites

Verhindern, dass das Video in anderen Dokumenten eingebettet wird.

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

Schützt Ihre Website vor dem Einbetten durch websites mit unterschiedlichen Ursprüngen

Einbetten nur durch Dokumente desselben Ursprungs zulassen.

X-Frame-Options: SAMEORIGIN

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

Cross-Origin Resource Policy (CORP)

Ein Angreifer kann Ressourcen aus einer anderen Quelle, z. B. von Ihrer Website, einbetten, um Informationen über sie zu erhalten, indem er webbasierte websiteübergreifende Lecks ausnutzt.

Cross-Origin-Resource-Policy minimiert dieses Risiko, indem die Websites angegeben werden, von denen aus es geladen werden kann. Der Header kann einen der drei Werte haben: same-origin, same-site und cross-origin. Wir empfehlen, für alle Ressourcen diese Kopfzeile zu senden, um anzugeben, ob sie von anderen Websites geladen werden dürfen.

Verwendungsbeispiel

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

Es wird empfohlen, alle Ressourcen mit einem der folgenden drei Header zu senden.

In dieser Demo können Sie testen, wie sich die folgenden Konfigurationen auf das Laden von Ressourcen in einer Cross-Origin-Embedder-Policy: require-corp-Umgebung auswirken. Ändern Sie das Drop-down-Menü Cross-Origin-Resource-Policy und klicken Sie auf die Schaltfläche Iframe neu laden oder Bild neu laden, um den Effekt zu sehen.

Ressourcen laden lassen cross-origin

Es wird empfohlen, dass CDN-ähnliche Dienste cross-origin auf Ressourcen anwenden, da sie in der Regel von seitenübergreifenden Ressourcen geladen werden, es sei denn, sie werden bereits über CORS ausgeliefert, was eine ähnliche Wirkung hat.

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

Ressourcen, die aus der same-origin geladen werden sollen, begrenzen

same-origin sollte auf Ressourcen angewendet werden, die nur von Seiten desselben Ursprungs geladen werden sollen. Sie sollten dies auf Ressourcen anwenden, die vertrauliche Informationen über den Nutzer enthalten, oder auf Antworten einer API, die nur von derselben Quelle aufgerufen werden soll.

Ressourcen mit diesem Header können weiterhin direkt geladen werden, z. B. indem Sie die URL in einem neuen Browserfenster aufrufen. Die Richtlinie für die ursprungsübergreifende Ressourcenfreigabe schützt die Ressource nur vor dem Einbetten durch andere Websites.

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

Aus same-site zu ladende Ressourcen begrenzen

same-site wird empfohlen, auf Ressourcen anzuwenden, die den oben genannten ähneln, aber von anderen Subdomains Ihrer Website geladen werden sollen.

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

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

Cross-Origin-Opener-Richtlinie (COOP)

Die Website eines Angreifers kann eine andere Website in einem Pop-up-Fenster öffnen, um Informationen darüber zu erhalten, indem sie webbasierte websiteübergreifende Datenlecks ausnutzt. In einigen Fällen ermöglicht dies möglicherweise auch die Ausnutzung von Side-Channel-Angriffen auf der Grundlage von Spectre.

Mit der Cross-Origin-Opener-Policy-Header-Information kann ein Dokument sich von fenstern mit unterschiedlichen Ursprüngen isolieren, die über window.open() oder einen Link mit target="_blank" ohne rel="noopener" geöffnet wurden. Daher hat jedes ursprungsübergreifende Öffnen des Dokuments keinen Verweis darauf und kann nicht mit ihm interagieren.

Beispiel

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

In dieser Demo können Sie testen, wie sich die folgenden Konfigurationen auf die Kommunikation mit einem Pop-up-Fenster mit unterschiedlichen Ursprüngen auswirken. Ändern Sie das Drop-down-Menü Cross-Origin-Opener-Policy sowohl für das Dokument als auch für das Pop-up-Fenster, klicken Sie auf die Schaltfläche Pop-up öffnen und dann auf postMessage senden, um zu sehen, ob die Nachricht tatsächlich zugestellt wird.

Dokumente von ursprungsübergreifenden Fenstern isolieren

Wenn Sie same-origin festlegen, wird das Dokument von ursprungsübergreifenden Dokumentfenstern isoliert.

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

Ein Dokument von ursprungsübergreifenden Fenstern isolieren, aber Pop-ups zulassen

Wenn same-origin-allow-popups festgelegt ist, kann ein Dokument eine Referenz zu seinen Pop-up-Fenster beibehalten, es sei denn, COOP wurde mit same-origin oder same-origin-allow-popups festgelegt. Das bedeutet, dass same-origin-allow-popups weiterhin verhindern kann, dass auf das Dokument verwiesen wird, wenn es als Pop-up-Fenster geöffnet wird. Es kann jedoch mit eigenen Pop-ups kommunizieren.

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

Zulassen, dass auf ein Dokument von ursprungsübergreifenden Fenstern verwiesen wird

unsafe-none ist der Standardwert. Sie können aber angeben, dass dieses Dokument in einem herkunftsübergreifenden Fenster geöffnet werden kann und der gegenseitige Zugriff beibehalten werden soll.

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

Muster melden, die nicht mit der Kampagnenoptimierung für Conversions kompatibel sind

Sie können Berichte erhalten, wenn durch COOP fensterübergreifende Interaktionen mit der Reporting API verhindert werden.

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

COOP unterstützt auch einen reinen Meldemodus, sodass Sie Berichte erhalten können, ohne die Kommunikation zwischen seitenübergreifenden Dokumenten zu blockieren.

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

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

Cross-Origin Resource Sharing (CORS)

Im Gegensatz zu anderen Elementen in diesem Artikel ist Cross-Origin Resource Sharing (CORS) kein Header, sondern ein Browsermechanismus, der den Zugriff auf Ressourcen verschiedener Herkunft anfordert und zulässt.

Standardmäßig erzwingen Browser die Same-Origin-Richtlinie, um zu verhindern, dass eine Webseite auf Ressourcen unterschiedlicher Herkunft zugreift. Wenn beispielsweise ein Bild mit unterschiedlichen Ursprüngen geladen wird, hat das JavaScript auf der Seite keinen Zugriff auf die Daten des Bildes, auch wenn es visuell auf der Webseite angezeigt wird. Der Ressourcenanbieter kann die Einschränkungen lockern und anderen Websites erlauben, die Ressource zu lesen, indem er CORS aktiviert.

Verwendungsbeispiel

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
CORS verwenden

Bevor Sie sich mit der Konfiguration von CORS befassen, sollten Sie den Unterschied zwischen den Anfragetypen kennen. Abhängig von den Anfragedetails wird eine Anfrage als einfache Anfrage oder als Preflight-Anfrage klassifiziert.

Kriterien für eine einfache Anfrage:

  • Die Methode ist GET, HEAD oder POST.
  • Die benutzerdefinierten Header enthalten nur Accept, Accept-Language, Content-Language und Content-Type.
  • Content-Type ist application/x-www-form-urlencoded, multipart/form-data oder text/plain.

Alles andere wird als Preflight-Anfrage klassifiziert. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing (CORS) – HTTP | MDN.

Einfache Anfrage

Wenn eine Anfrage die Kriterien für einfache Anfragen erfüllt, sendet der Browser eine ursprungsübergreifende Anfrage mit einem Origin-Header, der den Ursprung der Anfrage angibt.

Beispiel für einen Anfrageheader

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

Beispiel für einen Antwortheader

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com gibt an, dass der https://example.com auf den Inhalt der Antwort zugreifen kann. Bei Ressourcen, die von jeder Website gelesen werden sollen, kann dieser Header auf * gesetzt werden. In diesem Fall muss die Anfrage vom Browser nur ohne Anmeldedaten gestellt werden.
  • Access-Control-Allow-Credentials: true gibt an, dass Anfragen mit Anmeldedaten (Cookies) die Ressource laden dürfen. Andernfalls werden authentifizierte Anfragen abgelehnt, auch wenn der anfragende Ursprung im Access-Control-Allow-Origin-Header vorhanden ist.

In dieser Demo können Sie testen, wie sich die einfache Anfrage auf das Laden von Ressourcen in einer Cross-Origin-Embedder-Policy: require-corp-Umgebung auswirkt. Klicken Sie auf das Kästchen Cross-Origin Resource Sharing (Ressourcenfreigabe zwischen verschiedenen Ursprüngen) und dann auf die Schaltfläche Bild neu laden, um den Effekt zu sehen.

Preflight-Anfragen

Vor einer Preflight-Anfrage wird eine OPTIONS-Anfrage gesendet, um zu prüfen, ob die nachfolgende Anfrage gesendet werden darf.

Beispiel für einen Anfrageheader

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Mit Access-Control-Request-Method: POST kann die folgende Anfrage mit der Methode POST gestellt werden.
  • Mit Access-Control-Request-Headers: X-PINGOTHER, Content-Type kann der Anfragende die HTTP-Header X-PINGOTHER und Content-Type in der nachfolgenden Anfrage festlegen.

Beispiel für Antwortheader

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 gibt an, dass nachfolgende Anfragen mit den Methoden POST, GET und OPTIONS gestellt werden können.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type gibt an, dass nachfolgende Anfragen die Header X-PINGOTHER und Content-Type enthalten können.
  • Access-Control-Max-Age: 86400 gibt an, dass das Ergebnis der Preflight-Anfrage für 86.400 Sekunden im Cache gespeichert werden kann.

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

Cross-Origin-Embedder-Richtlinie (COEP)

Damit spektrebasierte Angriffe ursprungsübergreifende Ressourcen nicht mehr stehlen können, sind Features wie SharedArrayBuffer oder performance.measureUserAgentSpecificMemory() standardmäßig deaktiviert.

Cross-Origin-Embedder-Policy: require-corp verhindert, dass Dokumente und Worker ursprungsübergreifende Ressourcen wie Bilder, Skripts, Stylesheets, iFrames und andere laden, es sei denn, diese Ressourcen wurden explizit über CORS- oder CORP-Header geladen. COEP kann mitCross-Origin-Opener-Policy kombiniert werden, um für ein Dokument die Isolation verschiedener Ursprünge zu aktivieren.

Verwenden Sie Cross-Origin-Embedder-Policy: require-corp, wenn Sie die ursprungsübergreifende Isolierung für Ihr Dokument aktivieren möchten.

Verwendungsbeispiel

Cross-Origin-Embedder-Policy: require-corp
COEP verwenden

Anwendungsbeispiele

COEP nimmt einen einzelnen Wert von require-corp an. Durch Senden dieses Headers können Sie den Browser anweisen, das Laden von Ressourcen zu blockieren, die nicht über CORS oder CORP aktiviert werden.

Funktionsweise von COEP

In dieser Demo können Sie ausprobieren, wie sich die folgenden Konfigurationen auf das Laden von Ressourcen auswirken. Ändern Sie das Drop-down-Menü Cross-Origin-Embedder-Policy, das Drop-down-Menü Cross-Origin-Resource-Policy, das Kästchen Nur melden usw., um zu sehen, wie sich das auf das Laden von Ressourcen auswirkt. Öffnen Sie auch die Demo für den Berichtsendepunkt, um zu sehen, ob die blockierten Ressourcen gemeldet werden.

Ursprungsübergreifende Isolierung aktivieren

Aktiviere die ursprungsübergreifende Isolierung, indem du Cross-Origin-Embedder-Policy: require-corp zusammen mit Cross-Origin-Opener-Policy: same-origin sendest. 

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

Ressourcen melden, die nicht mit dem COEP kompatibel sind

Mit der Reporting API können Sie Berichte zu blockierten Ressourcen erhalten, die durch COEP verursacht wurden.

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

COEP unterstützt auch den Modus „Nur Berichte“, sodass Sie Berichte erhalten können, ohne Ressourcen zum Laden zu blockieren.

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

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

HTTP Strict Transport Security (HSTS)

Die Kommunikation über eine einfache HTTP-Verbindung ist nicht verschlüsselt, sodass die übertragenen Daten für Abhörer auf Netzwerkebene zugänglich sind.

Der Strict-Transport-Security-Header gibt dem Browser an, dass er die Website nie über HTTP laden und stattdessen HTTPS verwenden soll. Danach verwendet der Browser HTTPS anstelle von HTTP, um ohne Weiterleitung für eine im Header definierte Dauer auf die Domain zuzugreifen.

Beispiel

Strict-Transport-Security: max-age=31536000
HSTS verwenden

Alle Websites, die von HTTP zu HTTPS wechseln, sollten beim Empfang einer HTTP-Anfrage mit einem Strict-Transport-Security-Header antworten. 

Strict-Transport-Security: max-age=31536000

Unterstützte Browser

Unterstützte Browser

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

Quelle

Weitere Informationen

Weitere Informationen