Hier finden Sie weitere Informationen zu Headern, die zum Schutz Ihrer Website beitragen und einen schnellen Überblick über die wichtigsten Details geben.
In diesem Artikel werden die wichtigsten Sicherheitsheader aufgeführt, mit denen Sie Ihrer Website. Hier erfahren Sie, wie Sie mit webbasierten Sicherheitsfunktionen implementieren Sie diese auf Ihrer Website sowie als Referenz, wenn Sie eine Erinnerung benötigen.
- Empfohlene Sicherheitsheader für Websites, auf denen vertrauliche Nutzerdaten verarbeitet werden:
- Content Security Policy (CSP)
- Vertrauenswürdige Typen
- Empfohlene Sicherheitsheader für alle Websites:
- 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-Richtlinie (COEP)
Bevor Sie sich mit den Sicherheitsheadern befassen, sollten Sie sich über bekannte Bedrohungen im Web informieren und warum Sie diese Sicherheitsheader verwenden sollten.
Website vor Injection-Sicherheitslücken schützen
Injection-Sicherheitslücken entstehen, wenn nicht vertrauenswürdige Daten Anwendungen ihr Verhalten beeinflussen und häufig dazu führen, dass von Angreifern kontrollierte Skripts. Die häufigste Schwachstelle, die durch Injektion verursacht wird Bugs sind websiteübergreifend Scripting (XSS) in verschiedenen Formen, darunter reflektierte XSS gespeicherten XSS DOM-basiert XSS und andere Varianten.
Über eine XSS-Sicherheitslücke erhält ein Angreifer in der Regel vollständigen Zugriff auf Nutzerdaten. die von der Anwendung verarbeitet werden, sowie allen anderen Informationen, die im selben Web- „origin“.
Herkömmliche Abwehrmaßnahmen gegen Injektionen beinhalten die konsequente Verwendung von Autoescaping HTML-Vorlagensystemen und die Verwendung von gefährlichem JavaScript APIs und die ordnungsgemäße Verarbeitung von Nutzerdaten durch Hosting in einer separaten Domain hochladen und nutzergesteuerten HTML-Code bereinigen.
- Mit Content Security Policy (CSP) steuern, welche Skripts die von Ihrer Anwendung ausgeführt werden, um das Risiko von Injektionen zu verringern.
- Verwenden Sie vertrauenswürdige Typen, um die Bereinigung von Daten zu erzwingen, die an gefährliche JavaScript-APIs.
- Verwenden Sie X-Content-Type-Options, um zu verhindern, dass der Browser die MIME-Typen Ihrer Website-Ressourcen falsch interpretiert werden, was zu die Ausführung des Skripts.
Isolieren Ihrer Website von anderen Websites
Die Offenheit des Internets ermöglicht es Websites, auf eine Weise miteinander zu interagieren, die Sicherheitserwartungen einer Anwendung verletzen. Dazu gehören unerwarteterweise Authentifizierte Anfragen stellen oder Daten aus einer anderen Anwendung in die Dokument eines Angreifers und kann Anwendungsdaten ändern oder lesen.
Zu den häufigsten Sicherheitslücken, die die Web-Isolierung erschweren, gehören: Clickjacking, websiteübergreifend Anforderungsfälschung (CSRF), websiteübergreifend Script Inclusion (XSSI) und verschiedene Websiteübergreifende Datenlecks.
- Mit X-Frame-Options können Sie verhindern, dass Ihre Dokumente von einem bösartigen Website.
- Verwenden Sie die Cross-Origin Resource Policy (CORP), um zu verhindern, dass Ressourcen nicht in eine ursprungsübergreifende Website eingebunden werden können.
- Verwenden Sie die Cross-Origin Opener Policy (COOP), um die um die Fenster vor Interaktionen schädlicher Websites zu schützen.
- Nutzen Sie Cross-Origin Resource Sharing (CORS), um den Zugriff auf Ihre aus ursprungsübergreifenden Dokumenten abrufen können.
Post-Spectre-Web Entwicklung ist ein gutes Lesematerial. wenn Sie sich für diese Überschriften interessieren.
Eine leistungsstarke Website sicher erstellen
Spectre speichert alle geladenen Daten
in derselben Browserkontextgruppe potenziell lesbar
trotz der Same-Origin-Policy. Browser schränken Funktionen ein
die möglicherweise die Schwachstelle hinter einer speziellen Umgebung ausnutzen könnte,
„Cross-Origin Isolation“ (ursprungsübergreifende Isolierung) Mit der ursprungsübergreifenden Isolierung können Sie
leistungsstarke Funktionen wie SharedArrayBuffer
nutzen.
- Nutzen Sie die Richtlinie für Cross-Origin Embedder Policy (COEP) in Verbindung mit COOP, um aktivieren Sie die ursprungsübergreifende Isolierung.
Traffic auf Ihrer Website verschlüsseln
Verschlüsselungsprobleme treten auf, wenn eine Anwendung Daten nicht vollständig Transit, sodass abhörende Angreifer mehr über die Interaktionen des Nutzers erfahren können. mit der Anwendung.
Unzureichende Verschlüsselung kann in folgenden Fällen auftreten: fehlende HTTPS-Nutzung,
gemischte Inhalte, wobei Cookies ohne die Secure
Attribut
(oder __Secure
)
Präfix)
oder laxe CORS-Validierung
Logik.
- Verwenden Sie HTTP Strict Transport Security (HSTS), um Ihre über HTTPS zu verwalten.
Content Security Policy (CSP)
Cross-Site-Scripting (XSS) ist ein Angriff. wo eine Schwachstelle auf einer Website das Einschleusen eines schädlichen Skripts und ausgeführt haben.
Content-Security-Policy
bietet eine zusätzliche Ebene zur Abwehr von XSS-Angriffen
die durch die Seite
ausgeführt werden können.
Es wird empfohlen, die strikte CSP mit einer der folgenden Methoden zu aktivieren:
- Wenn Sie Ihre HTML-Seiten auf dem Server rendern, verwenden Sie eine Nonce-basierte strikte CSP.
- Wenn Ihr HTML-Code statisch oder im Cache bereitgestellt werden muss, zum Beispiel wenn es sich Single-Page-Anwendung sollten Sie eine Hash-basierte strikte CSP verwenden.
Verwendungsbeispiel: Nonce-basierte CSP
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
Empfohlene Verwendungen
1. Nonce-basierte strikte CSP verwenden {: #nonce-based-csp}
Wenn Sie Ihre HTML-Seiten auf dem Server rendern, verwenden Sie eine Nonce-basierte strikte CSP.
Generieren Sie einen neuen Skript-Nonce-Wert für jede serverseitige Anfrage und legen Sie folgenden Header:
Serverkonfigurationsdatei
Content-Security-Policy: script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';
Um die Skripts in HTML zu laden, legen Sie das Attribut nonce
aller
<script>
-Tags in 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 eine gute Nonce-basierte strikte CSP. Beispiel. Verwende die Entwicklertools, um zu sehen, wie sie verwendet wird.
2. Hash-basierte strikte CSP verwenden {: #hash-based-csp}
Wenn Ihr HTML-Code statisch oder im Cache bereitgestellt werden muss, z. B. wenn Sie 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 da die meisten Browser keine externe Hash-Technologie unterstützen. Skripts verwenden.
index.html
<script> ...// your script1, inlined </script> <script> ...// your script2, inlined </script>
Informationen zum Laden externer Skripts finden Sie unter „Quellskripts dynamisch laden“ unter Option B: Hash-basierter CSP-Antwortheader.
CSP-Evaluator ist ein gutes Tool, Ihre CSP bewerten, aber gleichzeitig ein gutes nonce-basiertes, striktes CSP-Beispiel. Verwende die Entwicklertools, um zu sehen, wie sie verwendet wird.
Unterstützte Browser
Weitere Hinweise zur CSP
frame-ancestors
Schutz Ihrer Website vor Clickjacking – einem Risiko, das entsteht, wenn Sie nicht vertrauenswürdigen Websites, um Ihre eigenen einzubetten. Wenn Sie eine einfachere Lösung bevorzugen, können SieX-Frame-Options
, um das Laden zu blockieren, aberframe-ancestors
gibt eine erweiterte Konfiguration, mit der nur bestimmte Ursprünge als Einbettungen zugelassen werden.- Möglicherweise haben Sie eine CSP verwendet, um sicherzustellen, dass alle Ressourcen Ihrer Website über HTTPS geladen werden. Dies hat weniger relevant werden: Heutzutage blockieren die meisten Browser gemischte Inhalte.
- Sie können eine CSP auch unter Nur Bericht Modus an.
- Wenn Sie eine CSP nicht als Header auf Serverseite festlegen können, können Sie sie auch als Meta-Tag Tag. Sie können den Nur-Bericht-Modus nicht für Meta-Tags verwenden. kann sich ändern).
Weitere Informationen
Vertrauenswürdige Typen
DOM-basiert
XSS ist ein
Angriff, bei dem schädliche Daten an eine Senke übergeben werden, die dynamischen Code unterstützt
wie eval()
oder .innerHTML
.
Vertrauenswürdige Typen bieten Tools zum Schreiben, Prüfen und Verwalten ohne DOM XSS. Sie können über CSP aktiviert werden und JavaScript-Code ist standardmäßig sicher, indem gefährliche Web-APIs nur ein spezielles Objekt – einen vertrauenswürdigen Typ.
Zum Erstellen dieser Objekte können Sie Sicherheitsrichtlinien definieren, mit denen Sie sicherstellen können, dass Sicherheitsregeln (z. B. Maskierung oder Bereinigung) einheitlich angewendet werden. bevor die Daten in das DOM geschrieben werden. Nur dann sind diese Richtlinien mit dem potenziell DOM XSS eingeführt werden könnte.
Anwendungsbeispiele
Content-Security-Policy: require-trusted-types-for 'script'
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\</g, '<').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 Verwendungen
-
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ürrequire-trusted-types-for
-Anweisung.Natürlich können Sie vertrauenswürdige Typen mit anderen CSP-Anweisungen kombinieren:
Zusammenführen eines nicht CE-basierten CSP mit vertrauenswürdigen Typen:
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 Richtliniennamen für vertrauenswürdige Typen einschränken, indem Sie zusätzliche <code>Trusted-Typen</code> festlegen. (z. B. <code>trusted-types myPolicy</code>). Dies 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 ein
Anforderung. Die Verwendung einer gefährlichen DOM API mit einem String führt zu einer
Fehler.
Unterstützte Browser
Weitere Informationen
- DOM-basierte Sicherheitslücken beim Cross-Site-Scripting mit „Trusted“
Typen
- CSP: request-trusted-types-for - HTTP |
MDN
- CSP: vertrauenswürdige Typen – HTTP |
MDN
- Demo zu vertrauenswürdigen Typen – öffnen Sie den Entwicklertools Inspector
was geschieht
X-Content-Type-Options
Wenn ein schädliches HTML-Dokument von Ihrer Domain bereitgestellt wird, z. B. wenn ein Bild, das in einen Fotodienst hochgeladen wurde, gültige HTML-Auszeichnung enthält), einige Browser behandelt es als aktives Dokument und ermöglicht es, Skripts im Kontext der Anwendung, was zu einem Cross-Site-Scripting führt. Fehler
X-Content-Type-Options: nosniff
verhindert dies, indem der Browser angewiesen wird,
MIME-Typ, der im
Der Content-Type
-Header für eine bestimmte Antwort ist korrekt. Dieser Header ist
empfohlen für alle Ihre Ressourcen.
Verwendungsbeispiel
X-Content-Type-Options: nosniff
Empfohlene Verwendungen
X-Content-Type-Options: nosniff
wird für alle Ressourcen empfohlen von
deinem Server zusammen mit dem richtigen Content-Type
-Header an.
Beispiel-Header, die mit dem HTML-Code eines Dokuments gesendet werden
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
Weitere Informationen
X-Frame-Options
Wenn eine bösartige Website Ihre Website als iFrame einbetten kann, ist möglicherweise können Angreifer unbeabsichtigte Aktionen des Nutzers Clickjacking In einigen Fälle Spectre-Typ bösartige Websites eine Chance, mehr über den Inhalt eines eingebetteten Dokuments zu erfahren.
X-Frame-Options
gibt an, ob ein Browser rendern dürfen
eine Seite in einem <frame>
, <iframe>
, <embed>
oder <object>
. Alle Dokumente
wird empfohlen, diesen Header zu senden, um anzugeben, ob sie
in anderen Dokumenten eingebettet.
Verwendungsbeispiel
X-Frame-Options: DENY
Empfohlene Verwendungen
Alle Dokumente, die nicht zum Einbetten vorgesehen sind, sollten den Header X-Frame-Options
verwenden.
Sie können ausprobieren, wie sich die folgenden Konfigurationen auf das Laden eines iFrames auf diesem
Demo X-Frame-Options
ändern
Drop-down-Menü und klicken Sie auf die Schaltfläche iFrame neu laden.
Schützt Ihre Website vor Einbettung in andere Websites
Das Einbetten durch andere Dokumente ablehnen.
X-Frame-Options: DENY
Schützt Ihre Website vor Einbettung auf ursprungsübergreifenden Websites
Nur Einbettung von Dokumenten mit demselben Ursprung zulassen.
X-Frame-Options: SAMEORIGIN
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
Weitere Informationen
Cross-Origin Resource Policy (CORP)
Ein Angreifer kann Ressourcen aus einer anderen Quelle einbetten, z. B. von Ihrer Website, durch die Nutzung webbasierter websiteübergreifender Leaks.
Cross-Origin-Resource-Policy
mindert dieses Risiko, indem es die Menge von
Websites, auf denen es geladen werden kann. Der Header hat einen von drei Werten:
same-origin
, same-site
und cross-origin
. Alle Ressourcen sind
wird empfohlen, diesen Header zu senden, um anzugeben, ob das Laden durch
anderen Websites.
Verwendungsbeispiel
Cross-Origin-Resource-Policy: same-origin
Empfohlene Verwendungen
Es wird empfohlen, alle Ressourcen mit einer der folgenden Optionen bereitzustellen: drei Überschriften.
Sie können ausprobieren, wie sich die folgenden Konfigurationen auf das Laden von Ressourcen in einem
Cross-Origin-Embedder-Policy: require-corp
-Umgebung in diesem
. Ändern Sie die
Cross-Origin-Resource-Policy aus und klicken Sie auf die Schaltfläche
iFrame oder Aktualisieren Sie das Bild, um den Effekt zu sehen.
Laden von Ressourcen zulassen cross-origin
Es wird empfohlen, CDN-ähnliche Dienste cross-origin
auf Ressourcen anzuwenden
(da sie normalerweise von ursprungsübergreifenden Seiten geladen werden), sofern sie nicht bereits ausgeliefert werden
über CORS, was einen ähnlichen Effekt hat.
Cross-Origin-Resource-Policy: cross-origin
Aus same-origin
zu ladende Ressourcen begrenzen
same-origin
sollte auf Ressourcen angewendet werden, die nur zum Laden bestimmt sind
Seiten desselben Ursprungs. Sie sollten dies auf Ressourcen anwenden, die sensible
Informationen über den Nutzer oder die Antworten einer API, die aufgerufen werden soll,
die denselben Ursprung haben.
Denken Sie daran, dass Ressourcen mit diesem Header weiterhin direkt geladen werden können, indem Sie die URL in einem neuen Browserfenster aufrufen. Cross-Origin-Ressource Eine Richtlinie schützt die Ressource nur vor dem Einbetten durch andere Websites.
Cross-Origin-Resource-Policy: same-origin
Aus same-site
zu ladende Ressourcen begrenzen
Es wird empfohlen, same-site
auf Ressourcen anzuwenden, die dem obigen Beispiel ähneln
aber von anderen Subdomains Ihrer Website geladen werden sollen.
Cross-Origin-Resource-Policy: same-site
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
Weitere Informationen
Cross-Origin Opener-Richtlinie (COOP)
Die Website eines Angreifers kann eine andere Website in einem Pop-up-Fenster öffnen, um mehr darüber zu erfahren. durch die Nutzung webbasierter websiteübergreifender Leaks. In einigen Fällen kann auch das Side-Channel-Angriffe auf der Grundlage von Spectre
Mit dem Cross-Origin-Opener-Policy
-Header kann ein Dokument
aus ursprungsübergreifenden Fenstern, die über window.open()
geöffnet wurden, oder einem Link mit
target="_blank"
ohne rel="noopener"
. Daher kann jeder ursprungsübergreifende Opener
des Dokuments haben keinen Verweis darauf und können nicht mit anderen
damit verbunden.
Verwendungsbeispiel
Cross-Origin-Opener-Policy: same-origin-allow-popups
Empfohlene Verwendungen
Sie können ausprobieren, wie sich die folgenden Konfigurationen auf die Kommunikation mit einem ursprungsübergreifendes Pop-up-Fenster in dieser Demo. Ändern Sie das Drop-down-Menü Cross-Origin-Opener-Policy für das Dokument. und Pop-up-Fenster öffnen, klicken Sie auf die Schaltfläche Pop-up öffnen und dann auf Send a postMessage, um festzustellen, ob die Nachricht tatsächlich zugestellt wird.
Dokument von ursprungsübergreifenden Fenstern isolieren
Wenn du „same-origin
“ festlegst, wird das Dokument vom ursprungsübergreifenden isoliert
Dokumentfenstern.
Cross-Origin-Opener-Policy: same-origin
Dokument von ursprungsübergreifenden Fenstern isolieren, aber Pop-ups zulassen
Mit der Einstellung same-origin-allow-popups
kann ein Dokument einen Verweis auf
seine Popup-Fenster angezeigt werden, es sei denn, sie setzen COOP auf same-origin
oder
same-origin-allow-popups
Das bedeutet, dass same-origin-allow-popups
immer noch
verhindern, dass das Dokument beim Öffnen als Pop-up-Fenster referenziert wird, aber
mit eigenen Pop-ups kommunizieren können.
Cross-Origin-Opener-Policy: same-origin-allow-popups
Zulassen, dass von ursprungsübergreifenden Fenstern auf ein Dokument verwiesen wird
unsafe-none
ist der Standardwert, aber Sie können explizit angeben,
Dokument kann über ein ursprungsübergreifendes Fenster geöffnet werden und hat den gegenseitigen Zugriff.
Cross-Origin-Opener-Policy: unsafe-none
Berichtsmuster nicht mit COOP kompatibel
Sie können Berichte erhalten, wenn COOP fensterübergreifende Interaktionen mit dem Reporting API
Cross-Origin-Opener-Policy: same-origin; report-to="coop"
COOP unterstützt auch einen Berichtsmodus, sodass Sie Berichte ohne die die Kommunikation zwischen ursprungsübergreifenden Dokumenten blockieren.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
Weitere Informationen
Cross-Origin Resource Sharing (CORS)
Im Gegensatz zu anderen Elementen in diesem Artikel ist Cross-Origin Resource Sharing (CORS) sondern ein Browsermechanismus, der den Zugriff auf ursprungsübergreifenden Ressourcen.
Standardmäßig erzwingen Browser die Same-Origin-Richtlinie, verhindern, dass eine Webseite auf ursprungsübergreifende Ressourcen zugreift. Wenn zum Beispiel ein ursprungsübergreifendes Bild geladen, obwohl es auf der Webseite angezeigt wird visuell ist, hat der JavaScript-Code auf der Seite keinen Zugriff auf die Bilddaten. Der Ressourcenanbieter kann Einschränkungen lockern und anderen Websites erlauben, Daten zu lesen die Ressource durch Aktivieren von CORS.
Verwendungsbeispiel
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Bevor wir uns mit der Konfiguration von CORS befassen, sollten Sie sich mit den Anfragetypen unterscheiden. Je nach Anfragedetails als einfache Anfrage oder Preflight-Anfrage klassifiziert sein müssen.
Kriterien für eine einfache Anfrage:
- Die Methode ist
GET
,HEAD
oderPOST
. - Die benutzerdefinierten Header enthalten nur
Accept
,Accept-Language
,Content-Language
undContent-Type
. Content-Type
istapplication/x-www-form-urlencoded
,multipart/form-data
odertext/plain
.
Alles andere wird als Preflight-Anfrage klassifiziert. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing (CORS) - HTTP | MDN
Empfohlene Verwendungen
Einfache Anfrage
Wenn eine Anfrage die Kriterien der einfachen Anfrage erfüllt, sendet der Browser eine
ursprungsübergreifenden Anfrage mit einem Origin
-Header, der die anfragende
Ursprung.
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 derhttps://example.com
kann auf den Inhalt der Antwort zugreifen. Beabsichtigte Ressourcen lesbar sein, können Sie diesen Header auf*
setzen. In diesem Fall wird der fordert der Browser nur eine Anfrage ohne AnmeldedatenAccess-Control-Allow-Credentials: true
gibt an, dass Anfragen, die Anmeldedaten (Cookies) dürfen die Ressource laden. Andernfalls werden authentifizierte Anfragen abgelehnt, auch wenn der anfragende UrsprungAccess-Control-Allow-Origin
-Header enthalten ist.
Sie können ausprobieren, wie sich die einfache Anfrage auf das Laden von Ressourcen unter einer
Cross-Origin-Embedder-Policy: require-corp
-Umgebung in diesem
. Klicken Sie auf das
Kästchen Cross-Origin Resource Sharing und dann auf Bild neu laden.
um den Effekt zu sehen.
Preflight-Anfragen
Einer Preflight-Anfrage ist eine OPTIONS
-Anfrage vorangestellt, um zu prüfen, ob der
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
Access-Control-Request-Method: POST
ermöglicht das Senden der folgenden Anfrage mit der MethodePOST
.Access-Control-Request-Headers: X-PINGOTHER, Content-Type
lässt Folgendes zu: die HTTP-HeaderX-PINGOTHER
undContent-Type
im nachfolgende Anfrage.
Beispiele 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 können mit den MethodenPOST
,GET
undOPTIONS
gestellt werden.Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
steht für nachfolgendes Anfragen können die HeaderX-PINGOTHER
undContent-Type
enthalten.Access-Control-Max-Age: 86400
gibt an, dass das Ergebnis des Preflight-Anfragens -Anfrage 86.400 Sekunden im Cache gespeichert werden.
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
Weitere Informationen
Cross-Origin Embedder-Richtlinie (COEP)
Um die Fähigkeit von spektrebasierten
Diebstahl ursprungsübergreifender Ressourcen, Funktionen wie SharedArrayBuffer
oder
performance.measureUserAgentSpecificMemory()
sind standardmäßig deaktiviert.
Cross-Origin-Embedder-Policy: require-corp
verhindert, dass Dokumente und Worker
wie Bilder, Skripts, Stylesheets, iFrames und
andere, es sei denn, diese Ressourcen wurden explizit über CORS geladen.
oder CORP-Header. COEP kann kombiniert mitCross-Origin-Opener-Policy
, um ein Dokument für die ursprungsübergreifende Isolierung zu aktivieren.
Zum Aktivieren Cross-Origin-Embedder-Policy: require-corp
verwenden
ursprungsübergreifende Isolierung für Ihr Dokument an.
Verwendungsbeispiel
Cross-Origin-Embedder-Policy: require-corp
Anwendungsbeispiele
COEP verwendet einen einzelnen Wert von require-corp
. Wenn Sie diesen Header senden, können Sie
den Browser anweisen, das Laden von Ressourcen zu blockieren, die nicht über
CORS oder CORP
Sie können ausprobieren, wie sich die folgenden Konfigurationen auf das Laden von Ressourcen Ändern Sie die Cross-Origin-Embedder-Policy auswählen, wird die Drop-down-Menü Cross-Origin-Resource-Policy, Kästchen Nur Bericht usw. um zu sehen, wie sie sich auf das Laden von Ressourcen auswirken. Öffnen Sie außerdem den Endpunkt für die Berichterstellung. Demo, um zu sehen, ob die blockierten Ressourcen gemeldet.
Ursprungsübergreifende Isolierung aktivieren
Aktivieren Sie die ursprungsübergreifende Isolierung durch Senden
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
Berichtsressourcen, die nicht mit COEP kompatibel sind
Über die Berichterstellung können Sie Berichte zu blockierten Ressourcen erhalten, die durch COEP verursacht wurden der API erstellen.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP unterstützt auch den Berichterstellungsmodus, sodass Sie Berichte erhalten können, ohne das Laden von Ressourcen blockiert.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
Weitere Informationen
HTTP Strict Transport Security (HSTS)
Die Kommunikation über eine einfache HTTP-Verbindung ist nicht verschlüsselt. übertragene Daten, die für Abhörer auf Netzwerkebene zugänglich sind.
Der Strict-Transport-Security
-Header informiert den Browser, dass er nie geladen werden soll.
mit HTTP und HTTPS verwenden. Sobald diese festgelegt ist, verwendet der Browser
über HTTPS statt über HTTP auf die Domain ohne Weiterleitung für einen bestimmten Zeitraum zugreifen zu können
die im Header definiert sind.
Verwendungsbeispiel
Strict-Transport-Security: max-age=31536000
Empfohlene Verwendungen
Alle Websites, die von HTTP zu HTTPS wechseln, sollten mit einer
Strict-Transport-Security
-Header, wenn eine Anfrage mit HTTP empfangen wird.
Strict-Transport-Security: max-age=31536000
Unterstützte Browser
Unterstützte Browser
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">
- <ph type="x-smartling-placeholder">