Integrity-Policy header
Experimentell: Dies ist eine experimentelle Technologie
Überprüfen Sie die Browser-Kompatibilitätstabelle sorgfältig vor der Verwendung auf produktiven Webseiten.
Der HTTP Integrity-Policy
Response-Header ermöglicht es Webseitenadministratoren sicherzustellen, dass alle vom Benutzeragenten geladenen Ressourcen (eines bestimmten Typs) Subresource Integrity-Garantien haben.
Wenn gesetzt, blockiert der Benutzeragent Anfragen zu bestimmten Request-Zielen, die Integritätsmetadaten auslassen, und blockiert ebenfalls Anfragen im no-cors-Modus gänzlich.
Meldungen über Verstöße können auch gesendet werden, wenn der Header einen Reporting-Endpunktnamen enthält, der mit einem über den Reporting-Endpoints
Header deklarierten Endpunkt übereinstimmt.
Berichte werden mithilfe der Reporting API erstellt und können auch in der Seite beobachtet werden, für die die Integritätspolitik durchgesetzt wird, mit einem ReportingObserver
.
Das Format des Berichtskörpers wird durch das IntegrityViolationReportBody
-Dictionary angegeben (eine JSON-serialisierte Form dieses Körpers wird in POST-Anfragen zu den Reporting-Serverendpunkten gesendet).
Dies hilft, Manipulationen von abgerufenen Subressourcen zu verhindern.
Header-Typ | Response-Header |
---|---|
Verbotener Request-Header | nein |
Syntax
Integrity-Policy: blocked-destinations=(<destination>),sources=(<source>),endpoints=(<endpoint>)
Die Header-Werte sind als strukturierte Feld-Dictionaries mit den folgenden Schlüsseln definiert:
blocked-destinations
-
Eine Liste von Request-Zielen, die gültige Integritätsmetadaten enthalten müssen. Erlaubte Werte sind:
sources
Optional-
Eine Liste von Integritätsquellen, die Integritätsmetadaten enthalten müssen. Erlaubte Werte sind:
inline
-
Die Quelle der Integritätsmetadaten ist inline im Inhalt, wie zum Beispiel das integrity-Attribut. Dies ist der Standardwert.
Da dies der Standardwert und der einzige Wert ist, ist das Weglassen von
sources
gleichbedeutend mit der Angabe vonsources=(inline)
.
endpoints
Optional-
Eine Liste von Berichterstattungsendpunktnamen, die angeben, wohin Berichte gesendet werden. Die Berichterstattungsendpunkte müssen in einem
Reporting-Endpoints
Header definiert sein.
Beispiele
>Blockieren und Berichten, wenn Skripte keine Integritätsmetadaten haben
Dieses Beispiel zeigt ein Dokument, das blockiert und berichtet, wenn ein <script>
(oder HTMLScriptElement
) kein integrity
-Attribut angibt, oder wenn eine Skript-Ressource im no-cors-Modus angefordert wird.
Beachten Sie, dass der in Integrity-Policy
verwendete integrity-endpoint
im Reporting-Endpoints
Header definiert ist.
Reporting-Endpoints: integrity-endpoint="https://example.com/integrity", backup-integrity-endpoint="https://report-provider.example/integrity"
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint backup-integrity-endpoint)
Der Berichts-Payload könnte folgendermaßen aussehen.
{
"type": "integrity-violation",
"url": "https://example.com",
"body": {
"documentURL": "https://example.com",
"blockedURL": "https://example.com/main.js",
"destination": "script",
"reportOnly": false
}
}
Spezifikationen
Specification |
---|
Subresource Integrity> # integrity-policy-section> |
Browser-Kompatibilität
Loading…