Kurzübersicht zu Sicherheitsheadern

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

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

In diesem Artikel werden die wichtigsten Sicherheitsheader aufgeführt, 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)
Bekannte Bedrohungen im Web
Informieren Sie sich über bekannte Bedrohungen im Web, bevor Sie sich mit den Sicherheitsheadern befassen und warum Sie diese Sicherheitsheader verwenden sollten.

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.

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.

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.

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';
CSP verwenden

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

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

Generieren Sie 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 Hash-basierte 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 die externe Hash-Technologie nicht 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

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 akzeptiert werden 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, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
Vertrauenswürdige Typen verwenden

  1. Vertrauenswürdige Typen für gefährliche DOM-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 require-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 &#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 zusätzliche <code>Trusted-Typen</code> festlegen. (z. B. <code>trusted-types myPolicy</code>). Dies ist jedoch keine Voraussetzung.  </aside>


    
  
  1. 
    
    Richtlinie definieren
    
    
    Richtlinie:
    
   
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    
    
  
    2. 
  
  2. 
    
    Richtlinie anwenden
    
    
    Verwenden Sie die Richtlinie, wenn Sie Daten in das DOM schreiben:
    
   
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    
    
    Bei require-trusted-types-for 'script' ist die Verwendung eines vertrauenswürdigen Typs ein
      Anforderung. Die Verwendung einer gefährlichen DOM API mit einem String führt zu einer
      Fehler.
    
  
    3. 



Unterstützte Browser



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Weitere Informationen

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ültiges HTML-Markup 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
So verwenden Sie X-Content-Type-Options

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

X-Content-Type-Options: nosniff

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

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

Unterstützte Browser

Unterstützte Browser

  • 64
  • 12
  • 50
  • 11

Quelle

Weitere Informationen

X-Frame-Optionen

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
Verwendung von X-Frame-Options

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 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 
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

  • 4
  • 12
  • 4
  • 4

Quelle

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
Verwendung von CORP

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 
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 
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: SameSite 
Cross-Origin-Resource-Policy: same-site

Unterstützte Browser

Unterstützte Browser

  • 73
  • 79
  • 74
  • 12

Quelle

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 nichts.

Verwendungsbeispiel

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

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-Richtlinie: Same-Origin 
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-Richtlinie: Same-origin-allow-popups 
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-Richtlinie: unsicher-none 
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

  • 83
  • 83
  • 79
  • 15.2

Quelle

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
CORS verwenden

Bevor Sie sich mit der Konfiguration von CORS befassen, sollten Sie sich mit der 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 oder POST.
  • Die benutzerdefinierten Header enthalten nur Accept, Accept-Language, Content-Language und Content-Type.
  • Content-Type ist application/x-www-form-urlencoded, multipart/form-data oder text/plain.

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

Einfache Anfrage

Wenn eine Anfrage die Kriterien der einfachen Anfrage erfüllt, sendet der Browser eine ursprungsübergreifender 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 der https://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 Anmeldedaten
  • Access-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 Ursprung Access-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 Methode POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type lässt Folgendes zu: die HTTP-Header X-PINGOTHER und Content-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 Methoden POST, GET und OPTIONS gestellt werden.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type steht für nachfolgendes Anfragen können die Header X-PINGOTHER und Content-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

  • 4
  • 12
  • 3,5
  • 4

Quelle

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
Verwendung von COEP

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

Funktionsweise von COEP

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

  • 83
  • 83
  • 79
  • 15.2

Quelle

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
HSTS verwenden

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

  • 4
  • 12
  • 4
  • 7

Quelle

Weitere Informationen

Weitere Informationen