Access-Control-Allow-Origin: *
Bei Anfragen ohne Anmeldeinformationen kann der Literalwert " *" als Platzhalter angegeben werden;
Der Wert weist Browser an, anfordernden Code von jedem beliebigen Ursprung für den Zugriff auf die Ressource zuzulassen.
Access-Control-Allow-Origin: < origin>
Gibt einen Ursprung an. Es kann nur ein einziger Ursprung angegeben werden.
Wenn der Server Clients mit mehreren Ursprüngen unterstützt,
muss er den Ursprung für den spezifischen Client zurückgeben, der die Anfrage stellt.
Beispiel
Access-Control-Allow-Origin: https://beispiel.org
Access-Control-Allow-Origin: null
Gibt den Ursprung "null" an.
Hinweis:
null sollte nicht verwendet werden :
Es mag sicher erscheinen, zurückzugeben Access-Control-Allow-Origin: "null",
aber die Serialisierung des Ursprungs jeder Ressource, die ein nicht hierarchisches Schema (wie data:oder file:)
und Sandbox-Dokumente verwendet, ist als "null" definiert.
Viele Benutzeragenten gewährt solchen Dokumenten Zugriff auf eine Antwort mit einem Access-Control-Allow-Origin: "null"Header,
und jeder Ursprung kann ein feindliches Dokument mit einem "Null"-Origin erstellen.
Der "Null"-Wert für den ACAO-Header sollte daher vermieden werden."
default-src 'none';
Es wird empfohlen, mit einer angemessen gesperrten Richtlinie zu beginnen
default-src https:;
Inline-Code deaktiviert und https erfordert
Laden von Ressourcen (Bilder, Schriftarten, Skripte usw.) über https zulassen
default-src https: 'unsafe-inline';
Verhindert das Ressourcen versehentlich über http geladen werden.
Es bietet jedoch keinen XSS-Schutz.
base-uri 'self';
Beschränkung der URLs im Base-Tag.
block-all-mixed-content;
Verhindert das Laden über HTTP, wenn die Seite HTTPS benutzt..
child-src 'self';
Legt die Quelle der Daten innerhalb von Frames fest.
connect-src 'self';
Legt die Quellen fest mit denen sich die Seite verbinden darf.
default-src 'none'; frame-ancestors 'none'
Deaktivieren Sie das Laden aller Ressourcen und deaktivieren Sie das Framing,
was für die Verwendung von APIs empfohlen wird
default-src 'self'
cdn.beispiel.de;
Bestimmt alles, was nicht durch andere Regeln festgelegt wurde.
default-src 'self'; img-src 'self' https://beispiele.com; object-src 'none'
Unsicheres Inline/Eval deaktivieren,
nur Ressourcen vom gleichen Ursprung laden,
außer auch Bilder von beispiele zulassen
Deaktiviert auch die Ausführung von Plugins
default-src *; object-src 'none'
Deaktivieren Sie die Verwendung von unsicherem Inline/Eval,
erlauben Sie alles andere außer der Plugin-Ausführung
font-src
font.beispiel.de;
Die Quellen der Schriften für die Seite.
form-action 'self';
Endpunkte von Formularen.
frame-ancestors
frame-ancestors 'self' https://www.example.org;
frame-ancestors 'none';
Legt fest, welche Domains Frames und iFrames einfügen dürfen.
frame-ancestors my-trusty-site.com
Gehen Sie wie folgt vor, um eine vertrauenswürdige Domäne (my-trusty-site.com) zuzulassen:
frame-src 'self';
Bestimmt die Quellen von Frames.
img-src 'self'
img.beispiel.de;
Die Quellen von denen Bilder geladen werden dürfen.
img-src domain.example.com
Ermöglicht das Laden von Ressourcen vom angegebenen Domänennamen.
img-src *.example.com
Ermöglicht das Laden von Ressourcen von jeder Subdomain unter example.com.
img-src https:
Ermöglicht das Laden von Ressourcen nur über HTTPS in jeder Domäne.
img-src https://example.com
Ermöglicht das Laden von Ressourcen nur über HTTPS,
das der angegebenen Domäne entspricht.
img-src 'self' data:
Ermöglicht das Laden von Ressourcen über das Datenschema
(z. B. Base64-codierte Bilder).
default-src 'none'; frame-ancestors 'none'
Deaktivieren Sie das Laden aller Ressourcen und deaktivieren Sie das Framing,
was für die Verwendung von APIs empfohlen wird
Legt fest von wo Manifests geladen werden dürfen.
media-src
media.beispiel.de;
Bestimmt woher Audio- und Video-Dateien stammen dürfen.
navigate-to
beispiel.de;
Legt fest, wohin aus dem Dokument navigiert werden darf.
object-src 'none'
Verhindert das Laden von Ressourcen aus beliebigen Quellen.
object-src 'self';
Legt die Quellen von Flash und ähnlichen Formaten bzw. Plugins fest.
plugin-types
application/pdf;
Legt über MIME-Types fest, welche Plugins über < object> oder < embed> aufgerufen werden dürfen.
prefetch-src 'none';
Welche Quellen mit rel="prefetch" oder rel="prerender" geladen werden dürfen.
script-src 'self'
Ermöglicht das Laden von Ressourcen vom gleichen Ursprung
(gleiches Schema, Host und Port).
script-src 'unsafe-inline'
Ermöglicht die Verwendung von Inline-Quellelementen wie Stilattributen,
Onclick- oder Skript-Tag-Bodys
(abhängig vom Kontext der Quelle, auf die sie angewendet werden)
und javascript:URIs
script-src 'unsafe-eval'
Ermöglicht unsichere dynamische Codeauswertung wie JavaScripteval()
script-src 'sha256-xyz...'
script-src 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc=';
Ermöglicht die Ausführung eines Inline-Skripts oder CSS,
wenn sein Hash mit dem angegebenen Hash im Header übereinstimmt.
Unterstützt derzeit SHA256, SHA384 oder SHA512.
CSP-Stufe 2
script-src 'nonce-rAnd0m'
Ermöglicht die Ausführung eines Inline-Skripts oder CSS,
wenn das Skript < script nonce="rAnd0m">-Tag (z. B.: ) ein Nonce-Attribut enthält,
das mit dem im CSP-Header angegebenen Nonce übereinstimmt.
Die Nonce sollte eine sichere zufällige Zeichenfolge sein und nicht wiederverwendet werden.
CSP-Stufe 2
script-src 'strict-dynamic'
Ermöglicht einem erlaubten Skript, zusätzliche Skripte über nicht vom Parser
eingefügte Skriptelemente zu laden
(zum Beispiel document.createElement('script');ist erlaubt).
CSP-Stufe 3
script-src 'unsafe-hashes' 'sha256-abc...'
Ermöglicht das Aktivieren von Skripten in Event-Handlern
(z . B. onclick).
Gilt nicht für javascript:oder Inline- < script>
CSP Level 3
worker-src 'self';
Ein Website-Administrator möchte Inhalte von einer vertrauenswürdigen Domäne
und allen ihren Unterdomänen zulassen
(es muss nicht dieselbe Domäne sein, auf die der CSP eingestellt ist).
Dies ist der Standardwert.
Ermöglicht das Hinzufügen des Dokuments zur Browsing-Kontextgruppe seines Öffners,
es sei denn, der Öffner selbst hat einen COOP von same-originoder same-origin-allow-popups.
Behält Verweise auf neu geöffnete Fenster oder Registerkarten bei,
die entweder COOP nicht festlegen oder die Isolation durch Festlegen eines COOP von deaktivieren unsafe-none.
Cross-Origin-Opener-Policy: same-origin
Isoliert den Browsing-Kontext ausschließlich auf Dokumente gleichen Ursprungs.
Ursprungsübergreifende Dokumente werden nicht im selben Browserkontext geladen.
Bestimmte Funktionen hängen von der Cross-Origin-Isolation ab.
Bestimmte Funktionen wie SharedArrayBufferObjekte oder Performance.now()mit ungedrosselten Timern sind nur verfügbar,
wenn Ihr Dokument einen COOP-Header mit dem Wert same-originvalue hat.
Beispiel
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy
same-site
Nur Anforderungen von derselben Site können die Ressource lesen.
Warnung:
Dies ist weniger sicher als eine origin .
Der Algorithmus zum Überprüfen, ob zwei Ursprünge die gleiche Site sind,
ist im HTML-Standard definiert und beinhaltet das Überprüfen der registrierbaren Domain .
same-origin
Nur Anfragen vom selben Ursprung (dh Schema + Host + Port) können die Ressource lesen.
cross-origin
Anfragen von jedem Ursprung (sowohl vom selben Standort als auch standortübergreifend) können die Ressource lesen.
Dies ist nützlich, wenn COEP verwendet wird
Expect-CT
enforce (erzwingen)
Die optionale enforce Direktive steuert, ob der Browser die Richtlinie erzwingen
oder als Nur-Bericht-Modus behandeln soll. Die Direktive hat keinen Wert,
also fügen Sie sie einfach ein oder nicht, je nachdem,
ob der Browser die Richtlinie erzwingen oder nur darüber berichten soll oder nicht.
max-age (max-alter)
Die erforderliche max-age Anweisung gibt die Anzahl der Sekunden an,
die der Browser zwischenspeichern und die empfangene Richtlinie anwenden soll,
unabhängig davon, ob sie erzwungen oder nur gemeldet wird.
report-uri (Seiten melden)
Favorit, die report-uri Direktive gibt an, wohin der Browser Berichte senden soll,
wenn er keine gültigen CT-Informationen erhält.
Dieser wird als absoluter URI angegeben.
Bereitstellen des Headers
Wie bei jedem neuen Mechanismus sollten zunächst alle Sites dies im Nur-Bericht-Modus einsetzen,
um das Wasser zu testen und sicherzustellen, dass es keine Fehler verursacht. enforce Das bedeutet,
dass Sie die Direktive weglassen und auf setzen max-agesollten 0.
Hier ist ein Beispiel:
Expect-CT: max-age=0, report-uri="https://{$subdomain}.report-uri.com/r/d/ct/reportOnly"
Feature-Policy
Die Ursprungszulassungsliste kann mehrere verschiedene Werte annehmen:
*:
Die Funktion ist in Browsing-Kontexten der obersten Ebene und in verschachtelten Browsing-Kontexten (Iframes) zulässig.
'self':
Die Funktion ist in Browsing-Kontexten der obersten Ebene und in verschachtelten Browsing-Kontexten mit demselben Ursprung zulässig.
Es ist in ursprungsübergreifenden Dokumenten in verschachtelten Browsing-Kontexten nicht zulässig.
'none':
Die Funktion ist in Browsing-Kontexten der obersten Ebene und in verschachtelten Browsing-Kontexten nicht zulässig.
:
bestimmte Ursprünge, für die die Richtlinie aktiviert werden soll (z . B. https://example.com).
Beispiel:
camera 'none'; fullscreen 'none'; geolocation 'none'; microphone 'none'; payment 'none'; speaker 'none'; usb 'none'; vibrate 'none'; vr 'none';
HTTP-Public-Key-Pinning
Hier ist ein Beispiel für einen gültigen HPKP-Header, der Pins für drei verschiedene öffentliche Schlüssel setzt.
Diese Richtlinie gilt für ein Jahr über alle Subdomains des aktuellen Ursprungs:
Was ist die max-age?
Die max-age gibt dem Browser an, wie lange er sich den HSTS-Header nach der ersten Verbindung merken soll.
Beispiel:
Du hast einen HSTS-Header mit einer max-age Wert von einem Jahr.
Nun ruft ein Besucher deine Webseite zum ersten Mal am 23.03.2022 auf.
Der HSTS-Header teilt dem Browser nun mit, dass er Verbindungen zu deiner Webseite
ausschließlich über eine verschlüsselte Verbindung herstellen darf und merkt das für den Zeitraum der max-age vor.
Nun am 23.03.2023 (1 Jahr später) läuft der Header (nur lokal beim Websitebesucher) ab.
Bei der nächsten Verbindung wird der Browser also zuerst wieder versuchen eine unverschlüsselte Verbindung aufzubauen
und muss erneut auf https weitergeleitet werden.
Darum: Um sich jedes mal den SSL-Handshake zu sparen macht es Sinn den max-age Wert so hoch zu setzen,
dass der HSTS-Header so lang wie möglich gespeicher wird, damit nur selten weitergeleitet werden muss.
Allerdings: wenn Sie SSL nur ausprobieren oder in Zukunft ihre Webseite vielleicht wieder ohne SSL zu betreiben,
so sollten Sie den max-age Wert nicht zu hoch setzen
Der Permissions-Policy-Header hieß früher »Feature-Policy« und wurde im Mai 2020 umbenannt.
Feature-Policy: geolocation 'self'
In anderen Fällen kann es sinnvoll sein, diese Richtlinie etwas zu lockern.
Wir können unserem eigenen Ursprung erlauben, die Geolokalisierungs-API zu verwenden,
aber verhindern, dass Inhalte von Drittanbietern darauf zugreifen,
indem wir Folgendes in der Zulassungsliste festlegen 'self':
Permissions-Policy: publickey-credentials-get=("https://example.com")
Wenn Sie eine genauere Kontrolle wünschen, können Sie bestimmte URLs auf die Whitelist setzen, die die Website des RP einbetten dürfen:
Dabei https://example.com handelt es sich um die URL der Seite, die die Website des RP in die einbettet < iframe>
Dieser Header steuert, ob der Referrer-Wert bei ausgehenden Links übergeben werden darf.
Das heißt, darf der Browser einer Seite mitteilen, von welcher Seite der Benutzer gekommen ist.
Mit dem Wert »no-referrer« verbietet man das komplett.
Dieser Header ist nicht direkt für die »Sicherheit« der Website verantwortlich
aber in Bezug auf den Datenschutz schon interessant.
Es gibt drei Optionen für die zulässigen ORIGINs jedes Features.
Permissions-Policy: microphone=(*)
(Mikrofon wird auf dieser Seite und allen gerahmten Seiten erlaubt)
Permissions-Policy: microphone=(self)
(Mikrofon wird auf dieser Seite und allen gerahmten Seiten erlaubt, wenn gleicher Ursprung)
Permissions-Policy: microphone=()
(Mikrofon wird auf dieser Seite und allen gerahmten Seiten nicht zugelassen)
Die HTTP-Header werden zur Kommunikation zwischen Client und Server verwendet.
HTTP-Header ermöglichen es Client und Server, zusätzliche Informationen mit einer HTTP-Anforderung oder -Antwort zu übergeben.
X-Forwarded-Proto (XPF)-Header wird verwendet, um das Protokoll zu identifizieren,
das der Client für die Verbindung mit einem Proxy oder Load Balancer verwendet hat.
Es kann HTTP oder HTTPS sein.
Ihr Serverzugriffsprotokoll enthält normalerweise Informationen über das zwischen Server und Load Balancer verwendete Protokoll,
aber es enthält keine Informationen über das zwischen Client und Load Balancer verwendete Protokoll.
Um Informationen darüber zu erhalten, welches Protokoll zwischen Client und Load Balancer verwendet wird,
können wir den X-Forwarded-Proto- Request-Header verwenden.
Mit diesem Header kann der Client eine HTTP-Anforderung an eine Nur-HTTPS-Ressource stellen.
# Microsoft
Front-End-Https: on
X-Forwarded-Protocol: http
X-Forwarded-Ssl: on
X-Url-Scheme: http
X-Frame-Options: DENY
Wenn Sie angeben DENY, schlägt der Browserversuch, die Seite in einem Frame zu laden,
nicht nur fehl, wenn er von anderen Sites geladen wird,
sondern schlägt auch fehl, wenn er von derselben Site geladen wird.
X-Frame-Options: SAMEORIGIN
Wenn Sie andererseits angeben SAMEORIGIN,
können Sie die Seite immer noch in einem Frame verwenden,
solange die Site, die sie in einem Frame enthält,
dieselbe ist wie die, die die Seite bereitstellt.
X-Frame-Options: ALLOW-FROM https://example.com/
Dies ist eine veraltete Direktive, die in modernen Browsern nicht mehr funktioniert.
(Die Verwendung ergibt das gleiche Verhalten wie das Weglassen des Headers.)
Verwenden Sie es nicht.
Der Content-Security-Policy HTTP-Header hat eine frame-ancestors Direktive,
die Sie stattdessen verwenden können.
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies X-Powered-By
X-XSS-Protection
X-XSS-Protection: 0: XSS-Schutz deaktivieren
X-XSS-Protection: 1: XSS-Schutz erzwingen (nützlich, wenn der XSS-Schutz vom Benutzer deaktiviert wurde)
X-XSS-Protection: 1; mode=block
Aktivieren des Filters, um die Webseite im Falle eines Angriffs zu blockieren
Das Token mode=block verhindert, dass Browser (IE8+ und Webkit-Browser) Seiten rendern (anstatt zu bereinigen),
wenn ein potenzieller XSS-Reflektionsangriff (= nicht persistent) erkannt wird.