Hier erfahren Sie mehr über Header, mit denen Sie Ihre Website schützen können, und können die wichtigsten Details schnell finden.
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)
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';
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
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 duX-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, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
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 Anweisungrequire-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 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<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, '>');
}
});
}
-
Richtlinie anwenden
Verwenden Sie die Richtlinie, wenn Sie Daten in das DOM schreiben:
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
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
Mehr dazu
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.
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
Unterstützte Browser
Mehr dazu
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
Unterstützte Browser
Mehr dazu
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.
Cross-Origin-Opener-Policy: unsafe-none
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
Mehr dazu
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
Mehr dazu
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
Mehr dazu
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
Mehr dazu
Weitere Informationen