Kurzübersicht zu Sicherheitsheadern

Hier finden Sie weitere Informationen zu Headern, die Ihre Website schützen können, und können schnell die wichtigsten Details nachschlagen.

Eiji Kitamura

Artur Janc

Maud Nalpas

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

Für Websites, auf denen vertrauliche Nutzerdaten verarbeitet werden, werden die folgenden Sicherheitsheader empfohlen:: Content Security Policy (CSP); Trusted Types
Für alle Websites empfohlene Sicherheitsheader:: X-Content-Type-Options; X-Frame-Options; Cross-Origin Resource Policy (CORP); Cross-Origin Opener Policy (COOP); HTTP Strict Transport Security (HSTS)
Sicherheitsheader für Websites mit erweiterten Funktionen:: Cross-Origin Resource Sharing (CORS); Cross-Origin Embedder Policy (COEP)

Bekannte Bedrohungen im Web

Bevor Sie sich mit Sicherheitsheadern befassen, sollten Sie sich über bekannte Bedrohungen im Web und die Gründe für die Verwendung dieser Sicherheitsheader informieren.

Website vor Injection-Sicherheitslücken schützen

Sicherheitslücken durch Einschleusung entstehen, wenn nicht vertrauenswürdige Daten, die von Ihrer Anwendung verarbeitet werden, ihr Verhalten beeinflussen können und in der Regel 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 Reflected XSS, Stored XSS, DOM-based XSS und anderen Varianten.

Eine XSS-Sicherheitslücke kann einem Angreifer in der Regel vollständigen Zugriff auf Nutzerdaten geben, die von der Anwendung verarbeitet werden, sowie auf alle anderen Informationen, die im selben Webursprung gehostet werden.

Zu den herkömmlichen Schutzmaßnahmen gegen Injections gehören die konsequente Verwendung von HTML-Vorlagensystemen mit automatischer Escapierung, das Vermeiden der Verwendung gefährlicher JavaScript-APIs und die ordnungsgemäße Verarbeitung von Nutzerdaten durch Hosten von Datei-Uploads in einer separaten Domain und Bereinigen von nutzergesteuertem HTML.

Verwenden Sie die Content Security Policy (CSP), um zu steuern, welche Scripts von Ihrer Anwendung ausgeführt werden können, um das Risiko von Injections zu minimieren.
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

Die Offenheit des Webs ermöglicht es Websites, auf eine Weise miteinander zu interagieren, die die Sicherheitserwartungen einer Anwendung verletzen kann. Dazu gehört auch, dass unerwartet authentifizierte Anfragen gestellt oder Daten aus einer anderen Anwendung in das Dokument des Angreifers eingebettet werden, wodurch der Angreifer Anwendungsdaten ändern oder lesen kann.

Häufige Sicherheitslücken, die die Webisolation untergraben, sind Clickjacking, Cross-Site-Request-Forgery (CSRF), Cross-Site-Script-Inclusion (XSSI) und verschiedene Cross-Site-Leaks.

Verwenden Sie X-Frame-Options, um zu verhindern, dass Ihre Dokumente in eine bösartige Website eingebettet werden.
Verwenden Sie die Cross-Origin Resource Policy (CORP), um zu verhindern, dass die Ressourcen Ihrer Website von einer ursprungsübergreifenden Website eingebunden werden.
Verwenden Sie die Cross-Origin Opener Policy (COOP), um die Fenster Ihrer Website vor Interaktionen durch schädliche Websites zu schützen.
Mit Cross-Origin Resource Sharing (CORS) können Sie den Zugriff auf die Ressourcen Ihrer Website über ursprungsübergreifende Dokumente steuern.

Der Artikel Post-Spectre Web Development ist eine gute Lektüre, wenn Sie sich für diese Header interessieren.

Leistungsstarke Websites sicher erstellen

Bei Spectre können alle Daten, die in dieselbe Browsing Context Group geladen werden, trotz der Same-Origin-Policy möglicherweise gelesen werden. Browser schränken Funktionen ein, die möglicherweise die Sicherheitslücke hinter einer speziellen Umgebung namens Cross-Origin Isolation ausnutzen könnten. Mit der ursprungsübergreifenden Isolation können Sie leistungsstarke Funktionen wie SharedArrayBuffer verwenden.

Verwenden Sie die Cross-Origin-Embedder-Policy (COEP) zusammen mit COOP, um die ursprungsübergreifende Isolation zu aktivieren.

Traffic auf Ihrer Website verschlüsseln

Verschlüsselungsprobleme treten auf, wenn eine Anwendung Daten während der Übertragung nicht vollständig verschlüsselt. So können Angreifer, die die Kommunikation abhören, Informationen über die Interaktionen des Nutzers mit der Anwendung erhalten.

Eine unzureichende Verschlüsselung kann in den folgenden Fällen auftreten: keine Verwendung von HTTPS, gemischte Inhalte, Setzen von Cookies ohne das Secure-Attribut (oder das __Secure-Präfix) oder nachlässige CORS-Validierungslogik.

Verwenden Sie HTTP Strict Transport Security (HSTS), um Ihre Inhalte immer über HTTPS bereitzustellen.

Content Security Policy (CSP)

Cross-Site-Scripting (XSS) ist ein Angriff, bei dem eine Sicherheitslücke auf einer Website es ermöglicht, ein schädliches Skript einzufügen und auszuführen.

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

Wir empfehlen, die strikte CSP mit einer der folgenden Methoden zu aktivieren:

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

Beispiel für die Verwendung: nonce-basiertes CSP

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

CSP verwenden

Empfohlene Verwendung

1. Strikte CSP auf Nonce-Basis verwenden {: #nonce-based-csp}

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

Generieren Sie für jede Anfrage serverseitig 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';

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

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. Verwenden Sie die Entwicklertools, um zu sehen, wie sie 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 strikte 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 Skripts finden Sie im Abschnitt Option B: Hashbasierter CSP-Antwortheader unter „Quellskripts dynamisch laden“.

CSP Evaluator ist ein gutes Tool, um Ihre CSP zu bewerten, und gleichzeitig ein gutes Beispiel für eine nonce-basierte strikte CSP. Verwenden Sie die Entwicklertools, um zu sehen, wie sie verwendet wird.

Unterstützte Browser

* https: ist ein Fallback für Safari und unsafe-inline ist ein Fallback für sehr alte Browserversionen. https: und unsafe-inline machen Ihre Richtlinie nicht weniger sicher, da sie von Browsern, die strict-dynamic unterstützen, ignoriert werden. Weitere Informationen finden Sie unter Fallbacks hinzufügen, um Safari und ältere Browser zu unterstützen. * Safari unterstützt strict-dynamic noch nicht. Ein strenger CSP wie in den obigen Beispielen ist jedoch für alle Ihre Nutzer sicherer als ein Allowlist-CSP (und viel sicherer als gar kein CSP). Auch in Safari schützt eine strenge CSP Ihre Website vor bestimmten Arten von XSS-Angriffen, da das Vorhandensein der CSP bestimmte unsichere Muster verbietet.

Weitere Hinweise zu CSP

frame-ancestors schützt Ihre Website vor Clickjacking. Dieses Risiko entsteht, wenn Sie nicht vertrauenswürdigen Websites erlauben, Ihre Website einzubetten. Wenn Sie eine einfachere Lösung bevorzugen, können Sie X-Frame-Options verwenden, um das Laden zu blockieren. Mit frame-ancestors haben Sie jedoch eine erweiterte Konfiguration, mit der Sie nur bestimmte Ursprünge als Einbettungen zulassen können.
Möglicherweise haben Sie einen CSP verwendet, um sicherzustellen, dass alle Ressourcen Ihrer Website über HTTPS geladen werden. Das ist weniger relevant geworden, da die meisten Browser heutzutage Mixed Content blockieren.
Sie können auch einen CSP im Modus „Nur Bericht“ festlegen.
Wenn Sie serverseitig keine CSP als Header festlegen können, können Sie sie auch als Meta-Tag festlegen. Der Nur-Bericht-Modus kann nicht für Meta-Tags verwendet werden. Das kann sich jedoch ändern.

Weitere Informationen

Vertrauenswürdige Typen

DOM-basiertes XSS ist ein Angriff, bei dem schädliche Daten in eine Senke übergeben werden, die die dynamische Codeausführung unterstützt, z. B. eval() oder .innerHTML.

Trusted Types bieten die Tools, mit denen Sie Anwendungen ohne DOM-XSS schreiben, sicherheitsüberprüfen und warten können. Sie können über CSP aktiviert werden und machen JavaScript-Code standardmäßig sicher, indem gefährliche Web-APIs so eingeschränkt werden, dass sie nur ein spezielles Objekt akzeptieren: einen Trusted Type.

Um diese Objekte zu erstellen, können Sie Sicherheitsrichtlinien definieren, in denen Sie dafür sorgen, dass Sicherheitsregeln (z. B. Escaping oder Bereinigung) konsistent angewendet werden, bevor die Daten in das DOM geschrieben werden. Diese Richtlinien sind dann die einzigen Stellen im Code, an denen DOM-XSS auftreten kann.

Beispiele für die Verwendung

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;

Trusted Types verwenden

Empfohlene Verwendung

Vertrauenswürdige Typen für gefährliche DOM-Senken erzwingen CSP- und Header für vertrauenswürdige Typen:
```
Content-Security-Policy: require-trusted-types-for 'script'
```
Derzeit ist 'script' der einzige zulässige Wert für die require-trusted-types-for-Anweisung.

Sie können Trusted Types natürlich mit anderen CSP-Direktiven kombinieren:

Zusammenführen eines nonce-basierten CSP aus dem obigen Beispiel mit vertrauenswürdigen Typen:

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 die zulässigen Richtliniennamen für vertrauenswürdige Typen einschränken, indem Sie eine zusätzliche <code>trusted-types</code>-Anweisung festlegen (z. B. <code>trusted-types myPolicy</code>). Dies ist jedoch nicht erforderlich.  </aside>


  
    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, '>');
    }
  });
}
    Hinweis : Sie können Richtlinien mit beliebigen Namen definieren, sofern Sie die Namen der zulässigen Richtlinien für vertrauenswürdige Typen nicht durch Festlegen der Anweisung trusted-types einschränken. 
  
  
    Richtlinie anwenden
    Richtlinie beim Schreiben von Daten in das DOM verwenden:
    
// 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.
  

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
Weitere Informationen

  DOM-basiertes Cross-Site-Scripting mit vertrauenswürdigen Typen verhindern
  CSP: require-trusted-types-for – HTTP |
      MDN
  CSP: trusted-types – HTTP |
      MDN
  Trusted Types-Demo: Öffnen Sie den DevTools-Inspektor, um zu sehen, was passiert.



X-Content-Type-Options

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

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 Ihre Ressourcen empfohlen.

Beispiel für die Verwendung
X-Content-Type-Options: nosniff


  
    
    X-Content-Type-Options verwenden


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

Beispiel für Header, die mit einem Dokument-HTML gesendet werden
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  X-Content-Type-Options – HTTP MDN

    
  


X-Frame-Options

Wenn eine schädliche Website Ihre Website als iFrame einbetten kann, können Angreifer möglicherweise mit Clickjacking unbeabsichtigte Aktionen des Nutzers auslösen. In einigen Fällen können Spectre-Angriffe dazu führen, dass schädliche Websites Informationen zum Inhalt eines eingebetteten Dokuments erhalten.

X-Frame-Options gibt an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern darf. Alle Dokumente: Es wird empfohlen, diesen Header zu senden, um anzugeben, ob das Einbetten in andere Dokumente zulässig ist.

Hinweis : Wenn Sie eine detailliertere Steuerung benötigen, z. B. wenn nur ein bestimmter Ursprung das Dokument einbetten darf, verwenden Sie die CSP-Anweisung frame-ancestors.  

Beispiel für die Verwendung
X-Frame-Options: DENY


  
    
    X-Frame-Options verwenden


    
      Empfohlene Verwendung
Für alle Dokumente, die nicht eingebettet werden sollen, muss 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 davor, von anderen Websites eingebettet zu werden
Verhindern, dass das Dokument in andere Dokumente eingebettet wird.

X-Frame-Options: DENY
Schützt Ihre Website davor, von beliebigen Websites mit anderem Ursprung eingebettet zu werden
Einbetten nur durch Same-Origin-Dokumente zulassen.
X-Frame-Options: SAMEORIGIN
 Da Dokumente standardmäßig eingebettet werden können, müssen Webentwickler explizit DENY oder SAMEORIGIN senden, um das Einbetten zu verhindern und sich vor Side-Channel-Angriffen zu schützen. Das Chrome-Team erwägt, standardmäßig auf das Blockieren von Dokumenteinbettungen umzustellen, damit Websites auch dann sicher sind, wenn der Header nicht explizit festgelegt wird. In dieser neuen Welt müssten Dokumente explizit für die Einbettung freigegeben werden. 
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  X-Frame-Options – HTTP

    
  


Cross-Origin-Resource-Policy (CORP)

Ein Angreifer kann Ressourcen von einem anderen Ursprung, z. B. von Ihrer Website, einbetten, um Informationen über sie zu erhalten, indem er webbasierte Cross-Site-Leaks ausnutzt.

Cross-Origin-Resource-Policy minimiert dieses Risiko, indem es angibt, von welchen Websites es geladen werden kann. Der Header kann einen von drei Werten annehmen: same-origin, same-site und cross-origin. Es wird empfohlen, dass alle Ressourcen diesen Header senden, um anzugeben, ob sie von anderen Websites geladen werden dürfen.

Beispiel für die Verwendung
Cross-Origin-Resource-Policy: same-origin


  
    
    CORP verwenden


    
      Empfohlene Verwendung
Es wird empfohlen, alle Ressourcen mit einem der folgenden drei Header bereitzustellen.
In dieser Demo können Sie ausprobieren, 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 die Änderung zu sehen.

Ressourcen dürfen geladen werden cross-origin
Es wird empfohlen, dass CDN-ähnliche Dienste cross-origin auf Ressourcen anwenden, da diese in der Regel von seitenübergreifenden Seiten geladen werden, sofern sie nicht bereits über CORS bereitgestellt werden, was einen ähnlichen Effekt hat.

Cross-Origin-Resource-Policy: cross-origin
Laden von Ressourcen aus same-origin einschränken
same-origin sollte auf Ressourcen angewendet werden, die nur von Seiten mit demselben Ursprung geladen werden sollen. Sie sollten dies auf Ressourcen anwenden, die vertrauliche Informationen über den Nutzer enthalten, oder auf Antworten einer API, die nur vom selben Ursprung aufgerufen werden soll.
Beachten Sie, dass Ressourcen mit diesem Header weiterhin direkt geladen werden können, z. B. durch Aufrufen der URL in einem neuen Browserfenster. Die Cross-Origin Resource Policy schützt die Ressource nur davor, von anderen Websites eingebettet zu werden.

Cross-Origin-Resource-Policy: same-origin
Laden von Ressourcen aus same-site einschränken
same-site wird für Ressourcen empfohlen, die den oben genannten ähneln, aber von anderen Subdomains Ihrer Website geladen werden sollen.

Cross-Origin-Resource-Policy: same-site
Hinweis : Weitere Informationen zum Unterschied zwischen „same-origin“ und „same-site“ finden Sie unter „Same-site“ und „same-origin“. 
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  Cross-Origin Resource Policy bereitstellen
  Website mit COOP und COEP „cross-origin isolated“ machen
  Warum ist „ursprungsübergreifend isoliert“ für leistungsstarke Funktionen erforderlich?

    
  


Cross-Origin-Opener-Policy (COOP)

Die Website eines Angreifers kann eine andere Website in einem Pop-up-Fenster öffnen, um Informationen darüber zu erhalten, indem webbasierte Cross-Site-Leaks ausgenutzt werden. In einigen Fällen kann dies auch die Ausnutzung von Nebenkanalangriffen auf Grundlage von Spectre ermöglichen.

Mit dem Header Cross-Origin-Opener-Policy kann ein Dokument sich von ursprungsübergreifenden Fenstern isolieren, die über window.open() oder einen Link mit target="_blank" ohne rel="noopener" geöffnet wurden. Daher hat jeder ursprungsübergreifende Öffner des Dokuments keinen Verweis darauf und kann nicht damit interagieren.

Beispiel für die Verwendung
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    COOP verwenden


    
      Empfohlene Verwendung
In dieser Demo können Sie ausprobieren, wie sich die folgenden Konfigurationen auf die Kommunikation mit einem Pop-up-Fenster mit ursprungsübergreifendem Zugriff 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 prüfen, ob die Nachricht tatsächlich zugestellt wird.
Dokument von ursprungsübergreifenden Fenstern isolieren
Durch die Einstellung same-origin wird das Dokument von ursprungsübergreifenden Dokumentfenstern isoliert.

Cross-Origin-Opener-Policy: same-origin
Dokument von ursprungsübergreifenden Fenstern isolieren, aber Pop‑ups zulassen
Wenn same-origin-allow-popups festgelegt ist, kann ein Dokument einen Verweis auf seine Pop-up-Fenster beibehalten, sofern für diese nicht COOP mit same-origin oder same-origin-allow-popups festgelegt ist. Das bedeutet, dass same-origin-allow-popups das Dokument weiterhin davor schützen kann, referenziert zu werden, wenn es als Pop-up-Fenster geöffnet wird, aber die Kommunikation mit eigenen Pop-ups zulässt.


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 explizit angeben, dass dieses Dokument von einem herkunftsübergreifenden Fenster geöffnet werden kann und der gegenseitige Zugriff erhalten bleibt.

 unsafe-none ist die Standardeinstellung. Das bedeutet, dass Webentwickler same-origin oder same-origin-allow-popups explizit senden müssen, um ihre Website vor Side-Channel-Angriffen zu schützen. 
Cross-Origin-Opener-Policy: unsafe-none
Hinweis : Funktionen wie SharedArrayBuffer oder performance.measureUserAgentSpecificMemory() sind standardmäßig deaktiviert. In einigen Browsern können Sie sie in „cross-origin isolated“-Kontexten verwenden. Dazu müssen Sie die COOP- und COEP-Header festlegen. Weitere Informationen finden Sie unter Website mit COOP und COEP „cross-origin isolated“ machen. 
Berichtsmuster, die nicht mit COOP kompatibel sind
Sie können Berichte erhalten, wenn COOP die Fensterübergreifende Interaktion mit der Reporting API verhindert.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP unterstützt auch einen reinen Berichtsmodus, sodass Sie Berichte erhalten können, ohne die Kommunikation zwischen ursprungsübergreifenden Dokumenten tatsächlich zu blockieren.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  Warum ist „ursprungsübergreifend isoliert“ für leistungsstarke Funktionen erforderlich?

    
  


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 mit unterschiedlichen Ursprüngen anfordert und zulässt.

Standardmäßig erzwingen Browser die Same-Origin-Richtlinie, um zu verhindern, dass eine Webseite auf ursprungsübergreifende Ressourcen zugreift. Wenn beispielsweise ein bildquellenübergreifendes Bild geladen wird, kann das JavaScript auf der Seite nicht auf die Daten des Bildes zugreifen, obwohl es auf der Webseite angezeigt wird.
Der Ressourcenanbieter kann Einschränkungen aufheben und anderen Websites erlauben, die Ressource zu lesen, indem er CORS aktiviert.

Beispiel für die Verwendung
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true


  
    
    CORS verwenden


    
      Bevor Sie sich ansehen, wie CORS konfiguriert wird, ist es hilfreich, die Unterscheidung zwischen Anfragetypen zu verstehen. Je nach den Details der Anfrage wird sie als einfache Anfrage oder als Preflight-Anfrage klassifiziert.
Kriterien für eine einfache Anfrage:

  Die Methode ist GET, HEAD oder POST.
  Die benutzerdefinierten Headern 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.
Empfohlene Verwendung
Einfache Anfrage
Wenn eine Anfrage die Kriterien für eine einfache Anfrage erfüllt, sendet der Browser eine ursprungsübergreifende Anfrage mit einem Origin-Header, der den anfragenden Ursprung 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. Für Ressourcen, die von jeder Website gelesen werden können, kann dieser Header auf * gesetzt werden. In diesem Fall muss die Anfrage vom Browser nur ohne Anmeldedaten gesendet werden.
  
  Access-Control-Allow-Credentials: true gibt an, dass Anfragen, die Anmeldedaten (Cookies) enthalten, 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 ausprobieren, wie sich die einfache Anfrage auf das Laden von Ressourcen in einer Cross-Origin-Embedder-Policy: require-corp-Umgebung auswirkt. Klicken Sie das Kästchen Cross-Origin Resource Sharing an und klicken Sie auf die Schaltfläche Bild neu laden, um den Effekt zu sehen.

Preflight-Anfragen
Einer Preflight-Anfrage geht eine OPTIONS-Anfrage voraus, 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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  Cross-Origin Resource Sharing (CORS)
  Cross-Origin Resource Sharing (CORS) – HTTP |
      MDN

    
  


Cross-Origin-Embedder-Richtlinie (COEP)

Um die Wahrscheinlichkeit zu verringern, dass bei Spectre-basierten Angriffen Ressourcen zwischen verschiedenen Ursprüngen gestohlen werden, sind Funktionen wie SharedArrayBuffer oder performance.measureUserAgentSpecificMemory() standardmäßig deaktiviert.

Cross-Origin-Embedder-Policy: require-corp verhindert, dass Dokumente und Worker Ressourcen mit Ursprungsübergang wie Bilder, Skripts, Stylesheets und iFrames laden, sofern diese Ressourcen nicht explizit über CORS- oder CORP-Header geladen werden. COEP kann mitCross-Origin-Opener-Policykombiniert werden, um ein Dokument für die ursprungsübergreifende Isolation zu aktivieren.

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

Beispiel für die Verwendung
Cross-Origin-Embedder-Policy: require-corp


  
    
    COEP verwenden


    
      Beispiele für die Nutzung
COEP akzeptiert nur den Wert require-corp. Durch das Senden dieses Headers können Sie den Browser anweisen, Ressourcen zu blockieren, die nicht über CORS oder CORP aktiviert werden.


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 Report Only usw., um zu sehen, wie sich die Änderungen auf das Laden von Ressourcen auswirken. Öffnen Sie außerdem die Demoseite für den Reporting-Endpunkt, um zu prüfen, ob die blockierten Ressourcen gemeldet werden.

Cross-Origin Isolation aktivieren
Aktivieren Sie die ursprungsübergreifende Isolierung, indem Sie Cross-Origin-Embedder-Policy: require-corp zusammen mit Cross-Origin-Opener-Policy: same-origin senden.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Mit COEP inkompatible Ressourcen melden
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 Nur-Bericht-Modus. So können Sie Berichte erhalten, ohne das Laden von Ressourcen zu blockieren.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  Website mit COOP und COEP „cross-origin isolated“ machen
  Warum ist „ursprungsübergreifend isoliert“ für leistungsstarke Funktionen erforderlich?
  Leitfaden zum Aktivieren der ursprungsübergreifenden Isolierung

    
  


HTTP Strict Transport Security (HSTS)

Die Kommunikation über eine einfache HTTP-Verbindung ist nicht verschlüsselt. Die übertragenen Daten sind daher für Lauscher auf Netzwerkebene zugänglich.

Der Strict-Transport-Security-Header informiert den Browser, dass die Website niemals über HTTP geladen werden soll, sondern stattdessen HTTPS verwendet werden soll. Sobald der Header festgelegt ist, verwendet der Browser für den Zugriff auf die Domain HTTPS anstelle von HTTP, ohne dass eine Weiterleitung erfolgt. Die Dauer wird im Header definiert.

Beispiel für die Verwendung
Strict-Transport-Security: max-age=31536000


  
    
    HSTS verwenden


    
      Empfohlene Verwendung
Alle Websites, die von HTTP zu HTTPS migriert werden, sollten mit einem Strict-Transport-Security-Header antworten, wenn eine Anfrage mit HTTP empfangen wird.

Strict-Transport-Security: max-age=31536000
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Weitere Informationen

  Strict-Transport-Security – HTTP

    
  


Weitere Informationen


Webentwicklung nach Spectre

Kurzübersicht zu Sicherheitsheadern Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Website vor Injection-Sicherheitslücken schützen

Website von anderen Websites isolieren

Leistungsstarke Websites sicher erstellen

Traffic auf Ihrer Website verschlüsseln

Content Security Policy (CSP)

Empfohlene Verwendung

1. Strikte CSP auf Nonce-Basis verwenden {: #nonce-based-csp}

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

Unterstützte Browser

Weitere Hinweise zu CSP

Weitere Informationen

Vertrauenswürdige Typen

Empfohlene Verwendung

Unterstützte Browser

Weitere Informationen

X-Content-Type-Options

Empfohlene Verwendung

Unterstützte Browser

Weitere Informationen

X-Frame-Options

Empfohlene Verwendung

Schützt Ihre Website davor, von anderen Websites eingebettet zu werden

Schützt Ihre Website davor, von beliebigen Websites mit anderem Ursprung eingebettet zu werden

Unterstützte Browser

Weitere Informationen

Cross-Origin-Resource-Policy (CORP)

Empfohlene Verwendung

Ressourcen dürfen geladen werden cross-origin

Laden von Ressourcen aus same-origin einschränken

Laden von Ressourcen aus same-site einschränken

Unterstützte Browser

Weitere Informationen

Cross-Origin-Opener-Policy (COOP)

Empfohlene Verwendung

Dokument von ursprungsübergreifenden Fenstern isolieren

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

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

Berichtsmuster, die nicht mit COOP kompatibel sind

Unterstützte Browser

Weitere Informationen

Cross-Origin Resource Sharing (CORS)

Empfohlene Verwendung

Einfache Anfrage

Preflight-Anfragen

Unterstützte Browser

Weitere Informationen

Cross-Origin-Embedder-Richtlinie (COEP)

Beispiele für die Nutzung

Cross-Origin Isolation aktivieren

Mit COEP inkompatible Ressourcen melden

Unterstützte Browser

Weitere Informationen

HTTP Strict Transport Security (HSTS)

Empfohlene Verwendung

Unterstützte Browser

Weitere Informationen

Weitere Informationen

Kurzübersicht zu Sicherheitsheadern

Ressourcen dürfen geladen werden `cross-origin`

Laden von Ressourcen aus `same-origin` einschränken

Laden von Ressourcen aus `same-site` einschränken