Diese Seite wurde von der Cloud Translation API übersetzt.

Kurzübersicht zu Sicherheitsheadern

Hier erfahren Sie mehr über Header, mit denen Sie Ihre Website schützen können, und können die wichtigsten Details schnell finden.

Eiji Kitamura

Artur Janc

Maud Nalpas

In diesem Artikel werden die wichtigsten Sicherheitsheader aufgeführt, die Sie zum Schutz Ihrer Website verwenden können. Er enthält Informationen zu webbasierten Sicherheitsfunktionen und zu ihrer Implementierung auf Ihrer Website sowie als Referenz, wenn Sie eine Erinnerung benötigen.

Empfohlene Sicherheitsheader für Websites, die vertrauliche Nutzerdaten verarbeiten:: Content Security Policy (CSP); Vertrauenswürdige Typen
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 informieren und erfahren, warum Sie diese Sicherheitsheader verwenden sollten.

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 Schwachstellen bei Injektionen schützen

Sicherheitslücken für Injections treten auf, wenn nicht vertrauenswürdige Daten, die von Ihrer Anwendung verarbeitet werden, ihr Verhalten beeinflussen und häufig zur Ausführung von von Angreifern kontrollierten Skripts führen können. Die häufigste Sicherheitslücke, die durch Injection-Fehler verursacht wird, ist Cross-Site-Scripting (XSS) in verschiedenen Formen, darunter reflektiertes XSS, gespeichertes XSS, DOM-basiertes XSS und andere Varianten.

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

Zu den traditionellen Abwehrmaßnahmen gegen Einschleusungen gehören die einheitliche Verwendung von HTML-Vorlagensystemen mit automatischer Escape-Codierung, die Vermeidung der Verwendung von gefährlichen 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 der Content Security Policy (CSP) können Sie festlegen, welche Skripts von Ihrer Anwendung ausgeführt werden können, um das Risiko von Injections zu verringern.
Verwenden Sie vertrauenswürdige Typen, 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 Websiteressourcen falsch interpretiert, was zur Skriptausführung führen kann.

Ihre Website von anderen Websites isolieren

Da das Web offen ist, können Websites so miteinander interagieren, dass die Sicherheitserwartungen einer Anwendung verletzt werden. Dazu gehört auch, dass Sie unerwartet authentifizierte Anfragen stellen oder Daten von einer anderen Anwendung in das Dokument des Angreifers einbetten, wodurch der Angreifer Anwendungsdaten ändern oder lesen kann.

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

Mit X-Frame-Options können Sie verhindern, dass Ihre Dokumente von einer schädlichen Website eingebettet werden.
Verwende die Cross-Origin Resource Policy (CORP), um zu verhindern, dass die Ressourcen deiner Website in eine ursprungsübergreifende 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.
Verwende Cross-Origin Resource Sharing (CORS), um den Zugriff auf die Ressourcen deiner Website über ursprungsübergreifende Dokumente zu steuern.

Post-Spectre Web Development ist eine gute Wahl, wenn Sie sich für diese Header interessieren.

Sicher eine leistungsstarke Website erstellen

Spectre fügt alle geladenen Daten in dieselbe Browserkontextgruppe ein, die trotz der Richtlinie für denselben Ursprung möglicherweise lesbar ist. Browser schränken Funktionen ein, die möglicherweise die Sicherheitslücke hinter einer speziellen Umgebung ausnutzen, die als ursprungsübergreifende Isolierung bezeichnet wird. Mit der ursprungsübergreifenden Isolierung können Sie leistungsstarke Funktionen wie SharedArrayBuffer verwenden.

Verwende die Cross-Origin Embedder Policy (COEP) mit COOP, um die ursprungsübergreifende Isolierung 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 Abhörer über die Interaktionen des Nutzers mit der Anwendung erfahren.

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

Verwende HTTP Strict Transport Security (HSTS), um Inhalte konsequent über HTTPS bereitzustellen.

Content Security Policy (CSP)

Cross-Site Scripting (XSS) ist ein Angriff, bei dem eine Sicherheitslücke auf einer Website das Einschleusen und Ausführen eines schädlichen Skripts ermöglicht.

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

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

Wenn Sie Ihre HTML-Seiten auf dem Server rendern, sollten Sie eine Nonce-basierte, strikte CSP verwenden.
Wenn Ihr HTML-Code statisch oder im Cache bereitgestellt werden muss, z. B. bei einer Anwendung mit nur einer Seite, sollten Sie eine strikte hashbasierte CSP verwenden.

Verwendungsbeispiel: eine Nonce-basierte CSP

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

CSP verwenden

Empfohlene Anwendungsfälle

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

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

Generieren Sie für jede Anfrage auf 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 in HTML die Skripts zu laden, setze das nonce-Attribut 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 Nonce-basiertes, striktes Beispiel für eine CSP. Mit den Entwicklertools kannst du sehen, wie sie verwendet werden.

2. Strikte Hash-basierte CSP verwenden {: #hash-based-csp}

Wenn Ihr HTML-Code statisch oder im Cache bereitgestellt werden muss, z. B. wenn Sie eine Single-Page-Anwendung erstellen, verwenden Sie eine strikte hashbasierte 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: Hash-basierter CSP-Antwortheader unter „Quellskripts dynamisch laden“.

Der CSP Evaluator ist ein gutes Tool, um Ihre CSP zu evaluieren, und gleichzeitig ein gutes, nonce-basiertes Beispiel für eine strikte CSP. Mit den Entwicklertools kannst du sehen, wie sie verwendet werden.

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 ignoriert werden, die strict-dynamic unterstützen. Weitere Informationen finden Sie unter Alternativen zur Unterstützung von Safari und älteren Browsern hinzufügen. * strict-dynamic wird in Safari noch nicht unterstützt. Aber eine strikte CSP wie in den obigen Beispielen ist für alle Ihre Nutzer sicherer als eine CSP mit Zulassungsliste (und deutlich sicherer als gar keine CSP). Selbst in Safari schützt eine strenge CSP Ihre Website vor einigen Arten von XSS-Angriffen, da bestimmte unsichere Muster in der CSP nicht zulässig sind.

Weitere Hinweise zur CSP

Die Anweisung frame-ancestors schützt Ihre Website vor Clickjacking – ein Risiko, das entsteht, wenn Sie Ihre Website nicht vertrauenswürdigen Websites einbetten. Wenn du eine einfachere Lösung bevorzugst, kannst du X-Frame-Options verwenden, um das Laden zu blockieren. frame-ancestors bietet jedoch eine erweiterte Konfiguration, um nur bestimmte Ursprünge als Einbettungen zuzulassen.
Möglicherweise hast du eine CSP verwendet, um sicherzustellen, dass alle Ressourcen deiner Website über HTTPS geladen werden. Das ist nicht mehr so relevant: Heutzutage blockieren die meisten Browser gemischte Inhalte.
Sie können eine CSP auch im Nur-Berichtsmodus festlegen.
Wenn du eine CSP nicht serverseitig als Header festlegen kannst, hast du auch die Möglichkeit, sie als Meta-Tag festzulegen. Hinweis: Der Nur-Bericht-Modus kann nicht für Meta-Tags verwendet werden. Dies kann sich jedoch ändern.

Mehr dazu

Vertrauenswürdige Typen

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

Vertrauenswürdige Typen bieten Tools zum Schreiben, für die Sicherheitsüberprüfung und Wartung von Anwendungen ohne DOM XSS. Sie können über CSP aktiviert werden und JavaScript-Code standardmäßig sicher machen, indem gefährliche Web-APIs so eingeschränkt werden, dass sie nur ein spezielles Objekt – einen vertrauenswürdigen Typ – akzeptieren.

Zum Erstellen dieser Objekte können Sie Sicherheitsrichtlinien definieren, mit denen Sie sicherstellen können, dass Sicherheitsregeln (z. B. Escape-Sequenzen oder Bereinigungen) konsistent angewendet werden, bevor die Daten in das DOM geschrieben werden. Diese Richtlinien sind dann die einzigen Stellen im Code, an denen möglicherweise DOM XSS eingeführt werden könnte.

Verwendungsbeispiele

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

Empfohlene Anwendungsfälle

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

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

So wird eine Nonce-basierte CSP (siehe oben) mit vertrauenswürdigen Typen zusammengeführt:

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 Namen von Richtlinien für vertrauenswürdige Typen einschränken, indem Sie eine zusätzliche <code>Trusted-Typen</code>-Anweisung festlegen (z. B. <code>Trusted-types myPolicy</code>). Das ist jedoch keine Voraussetzung.  </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 zulässiger Richtlinien für vertrauenswürdige Typen nicht durch Festlegen der Anweisung trusted-types einschränken. 
  
  
    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 eine Voraussetzung. Die Verwendung einer gefährlichen DOM API mit einem String führt zu einem Fehler.
  

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
Mehr dazu

  DOM-basierte Cross-Site-Scripting-Sicherheitslücken mit vertrauenswürdigen Typen verhindern
  CSP: required-Trusted-types-for – HTTP | MDN
  CSP: Trusted-types – HTTP | MDN
  Demo zu vertrauenswürdigen Typen – öffnen Sie den DevTools Inspector und sehen Sie sich an, 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ültige HTML-Markups enthält), behandeln einige Browser es als aktives Dokument und lassen die Ausführung von Skripts im Kontext der Anwendung zu, was zu einem websiteübergreifenden Scripting-Fehler führt.

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

Verwendungsbeispiel
X-Content-Type-Options: nosniff


  
    
    Verwendung von X-Content-Type-Options


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

Beispielheader, die mit einem Dokument-HTML-Code gesendet wurden
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  64
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  50
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  11
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

  X-Content-Type-Options – HTTP-MDN

    
  


X-Frame-Optionen

Wenn eine schädliche Website Ihre Website als iFrame einbetten kann, können Angreifer unter Umständen mit Clickjacking unbeabsichtigte Aktionen des Nutzers auslösen. In manchen Fällen ermöglichen Spectre-Angriffe schädliche Websites, mehr über den Inhalt eines eingebetteten Dokuments zu erfahren.

X-Frame-Options gibt an, ob ein Browser eine Seite in einem <frame>-, <iframe>-, <embed>- oder <object>-Objekt rendern darf. Es wird empfohlen, alle Dokumente zu senden, um anzugeben, ob sie in andere Dokumente eingebettet werden können.

Hinweis : Wenn Sie eine detailliertere Kontrolle benötigen und z. B. nur einem bestimmten Ursprung das Einbetten des Dokuments erlauben möchten, verwenden Sie die CSP-Anweisung frame-ancestors.  

Verwendungsbeispiel
X-Frame-Options: DENY


  
    
    Verwendung von X-Frame-Options


    
      Empfohlene Anwendungsfälle
Alle Dokumente, die nicht für das Einbetten vorgesehen sind, sollten den X-Frame-Options-Header verwenden.
In dieser Demo kannst du 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 der Einbettung durch andere Websites
Einbetten durch andere Dokumente ablehnen.

X-Frame-Options: DENY

Schützt Ihre Website vor der Einbettung durch ursprungsübergreifende Websites
Einbetten nur in Dokumenten mit demselben Ursprung zulassen.
X-Frame-Options: SAMEORIGIN

 Wenn Dokumente standardmäßig eingebettet werden können, müssen Webentwickler explizit DENY oder SAMEORIGIN senden, um die Einbettung zu beenden und sich vor Side-Channel-Angriffen zu schützen. Das Chrome-Team erwägt, das Einbetten von Dokumenten standardmäßig zu blockieren, damit Websites auch dann sicher sind, wenn der Header nicht explizit festgelegt wird. In dieser neuen Welt müssen Dokumente ausdrücklich eingebettet werden. 
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

  X-Frame-Options – HTTP

    
  


Cross-Origin Resource Policy (CORP)

Ein Angreifer kann Ressourcen eines anderen Ursprungs einbetten, z. B. von deiner Website, um durch Ausnutzen von webbasierten websiteübergreifenden Leaks Informationen über diese zu erhalten.

Cross-Origin-Resource-Policy verringert dieses Risiko, indem die Gruppe von Websites angegeben wird, über die das Gerät geladen werden kann. Der Header enthält einen von drei Werten: same-origin, same-site oder cross-origin. Es wird empfohlen, alle Ressourcen zu senden, um anzugeben, ob sie von anderen Websites geladen werden dürfen.

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


  
    
    So verwenden Sie CORP


    
      Empfohlene Anwendungsfälle
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 den Effekt zu sehen.

Laden von Ressourcen zulassen cross-origin
CDN-ähnliche Dienste sollten cross-origin auf Ressourcen anwenden, da sie normalerweise von ursprungsübergreifenden Seiten geladen werden, es sei denn, sie werden bereits über CORS bereitgestellt, was einen ähnlichen Effekt hat.

Cross-Origin-Resource-Policy: cross-origin

Begrenzen Sie Ressourcen, die aus same-origin geladen werden sollen
same-origin sollte auf Ressourcen angewendet werden, die nur von Seiten mit derselben Herkunft geladen werden sollen. Dies sollten Sie auf Ressourcen anwenden, die vertrauliche Informationen über den Nutzer oder Antworten einer API enthalten, die nur vom selben Ursprung aus aufgerufen werden soll.
Ressourcen mit diesem Header können weiterhin direkt geladen werden, z. B. wenn die URL in einem neuen Browserfenster aufgerufen wird. Die Cross-Origin Resource Policy schützt die Ressource nur vor dem Einbetten durch andere Websites.

Cross-Origin-Resource-Policy: same-origin

Begrenzen Sie Ressourcen, die aus same-site geladen werden sollen
same-site wird für Ressourcen empfohlen, die den obigen ä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 Understanding „same-site“ und „same-origin“. 
Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  73
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  74
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

  Bereitstellung ursprungsübergreifender Ressourcenrichtlinien erwägen
  Website mit COOP und COEP „ursprungsübergreifend isoliert“ gestalten
  Warum Sie „ursprungsübergreifend“ für leistungsstarke Funktionen benötigen

    
  


Cross-Origin Opener Policy (COOP)

Die Website eines Angreifers kann eine andere Website in einem Pop-up-Fenster öffnen, um durch Ausnutzung webbasierter websiteübergreifender Leaks Informationen darüber zu erhalten. In einigen Fällen können dadurch auch Seitenkanalangriffe auf der Grundlage von Spectre ausgenutzt werden.

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 werden. Daher enthält kein ursprungsübergreifendes Öffnen des Dokuments keinen Verweis darauf und kann nicht mit ihm interagieren.

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


  
    
    COOP verwenden


    
      Empfohlene Anwendungsfälle
In dieser Demo können Sie mit einem ursprungsübergreifenden Pop-up-Fenster ausprobieren, wie sich die folgenden Konfigurationen auf die Kommunikation auswirken.
  Ändern Sie das Drop-down-Menü Cross-Origin-Opener-Policy sowohl für das Dokument als auch das Pop-up-Fenster. Klicken Sie auf die Schaltfläche Open a pop (Pop-up öffnen) und dann auf Send a postMessage, um zu sehen, ob die Nachricht tatsächlich zugestellt wird.
Dokument aus ursprungsübergreifenden Fenstern isolieren
Mit der 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, es sei denn, sie legen COOP mit same-origin oder same-origin-allow-popups fest. Das bedeutet, dass same-origin-allow-popups das Dokument weiterhin vor Verweisen schützen kann, wenn es als Pop-up-Fenster geöffnet wird, aber seine Kommunikation mit seinen eigenen Pop-ups zulässt.


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

Zulassen, dass in ursprungsübergreifenden Fenstern auf ein Dokument verwiesen wird
unsafe-none ist der Standardwert. Sie können jedoch explizit angeben, dass dieses Dokument in einem ursprungsübergreifenden Fenster geöffnet werden kann und der gegenseitige Zugriff beibehalten wird.

 Wenn unsafe-none der Standardwert ist, müssen die Webentwickler explizit same-origin oder same-origin-allow-popups senden, um ihre Website vor Side-Channel-Angriffen zu schützen. 
Cross-Origin-Opener-Policy: unsafe-none

Hinweis : Features wie SharedArrayBuffer oder performance.measureUserAgentSpecificMemory() sind standardmäßig deaktiviert. Einige Browser ermöglichen die Verwendung in „ursprungsübergreifend isolierten“ Kontexten, wofür Sie COOP- und COEP-Header festlegen müssen. Weitere Informationen finden Sie im Artikel Website mit COOP und COEP „ursprungsübergreifend isoliert“ gestalten. 
Berichtmuster nicht mit COOP kompatibel
Sie können Berichte erhalten, wenn COOP fensterübergreifende Interaktionen mit der Reporting API verhindert.
Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP unterstützt auch einen reinen Berichtsmodus, sodass Sie Berichte empfangen können, ohne die Kommunikation zwischen ursprungsübergreifenden Dokumenten zu blockieren.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

  Warum Sie „ursprungsübergreifend“ für leistungsstarke Funktionen benötigen

    
  


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 ursprungsübergreifende Ressourcen anfordert und erlaubt.

Standardmäßig erzwingen Browser die Same-Origin-Policy, um zu verhindern, dass eine Webseite auf ursprungsübergreifende Ressourcen zugreift. Wenn beispielsweise ein ursprungsübergreifendes Bild geladen wird, obwohl es auf der Webseite visuell angezeigt wird, hat der JavaScript-Code auf der Seite keinen Zugriff auf die Bilddaten.
Der Ressourcenanbieter kann 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


  
    
    So verwenden Sie CORS


    
      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.
Empfohlene Anwendungsfälle
Einfache Anfrage
Wenn eine Anfrage die einfachen Anfragekriterien 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 https://example.com auf den Inhalt der Antwort zugreifen kann. Bei Ressourcen, die für jede Website lesbar sein sollen, kann dieser Header auf * gesetzt werden. In diesem Fall muss der Browser die Anfrage nur ohne Anmeldedaten stellen.
  
  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 auf das Kästchen Cross-Origin Resource Sharing und dann auf die Schaltfläche Bild neu laden, um den Effekt zu sehen.

Preflight-Anfragen
Einer Preflight-Anfrage wird eine OPTIONS-Anfrage vorangestellt, 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 ausgeführt werden.
  Mit Access-Control-Request-Headers: X-PINGOTHER, Content-Type kann der Sender 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 ausgeführt 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 86.400 Sekunden im Cache gespeichert werden kann.

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  3,5
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

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

    
  


Cross-Origin Embedder Policy (COEP)

Damit Spectre-basierte Angriffe ursprungsübergreifende Ressourcen nicht 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, das Laden dieser Ressourcen wurde explizit über CORS- oder CORP-Header aktiviert. COEP kann mit Cross-Origin-Opener-Policy kombiniert werden, um die ursprungsübergreifende Isolierung für ein Dokument 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


  
    
    So verwendest du COEP


    
      Verwendungsbeispiele
COEP verwendet den einzelnen Wert require-corp. Mit diesem Header können Sie den Browser anweisen, Laderessourcen 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 Nur Bericht usw., um zu sehen, wie sich diese auf das Laden von Ressourcen auswirken. Öffnen Sie außerdem die Demo zum Berichtsendpunkt, um zu sehen, ob die blockierten Ressourcen gemeldet wurden.

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

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

Ressourcen melden, die nicht mit 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 reinen Berichtsmodus, sodass Sie Berichte empfangen können, ohne das Laden von Ressourcen zu blockieren.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

  Website mit COOP und COEP „ursprungsübergreifend isoliert“ gestalten
  Warum Sie „ursprungsübergreifend“ für leistungsstarke Funktionen benötigen
  Leitfaden zum Aktivieren der ursprungsübergreifenden Isolierung

    
  


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 informiert den Browser darüber, dass die Website nie über HTTP geladen und stattdessen HTTPS verwendet werden soll. Danach verwendet der Browser HTTPS anstelle von HTTP, um für eine im Header definierte Dauer ohne Weiterleitung auf die Domain zuzugreifen.

Verwendungsbeispiel
Strict-Transport-Security: max-age=31536000


  
    
    HSTS verwenden


    
      Empfohlene Anwendungsfälle
Alle Websites, die von HTTP zu HTTPS wechseln, sollten mit einem Strict-Transport-Security-Header antworten, wenn eine HTTP-Anfrage empfangen wird.

Strict-Transport-Security: max-age=31536000

Unterstützte Browser

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Unterstützte Browser
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  7
  
  
        
        
        Quelle
        
      
    
    
    
  
Mehr dazu

  Strict-Transport-Security – HTTP

    
  


Weitere Informationen


Post-Spectre-Webentwicklung