CSPViolationReportBody: effectiveDirective-Eigenschaft

Die schreibgeschützte Eigenschaft effectiveDirective des CSPViolationReportBody-Interfaces ist ein String, der die effektive Content Security Policy (CSP)-Direktive darstellt, die verletzt wurde.

Beachten Sie, dass dies die spezifische Direktive enthält, die tatsächlich verletzt wurde, wie z.B. script-src-elem bei Verstößen im Zusammenhang mit Skriptelementen, und nicht die ursprünglich festgelegte Richtlinie, die möglicherweise die allgemeinere default-src war.

Wert

Ein String, der die effektive Content-Security-Policy-Direktive darstellt, die verletzt wurde.

Beispiele

CSP-Verletzung durch Inline-Skript

Dieses Beispiel löst eine CSP-Verletzung mithilfe eines Inline-Skripts aus und meldet die Verletzung mit einem ReportingObserver. Insbesondere protokolliert es die effectiveDirective und die originalPolicy, um den Unterschied klar zu machen.

HTML

Die nachfolgende HTML-Datei verwendet das <meta>-Element, um die Content-Security-Policy default-src auf self zu setzen, was Skripte und andere Ressourcen erlaubt, von derselben Domain geladen zu werden, aber keine Inline-Skripts ausführt. Das Dokument enthält auch ein Inline-Skript, das eine CSP-Verletzung auslösen sollte.

html

<!doctype html>
<html lang="en">
  <head>
    <meta
      http-equiv="Content-Security-Policy"
      content="default-src 'self'; report-to csp-endpoint" />
    <meta
      http-equiv="Reporting-Endpoints"
      content="csp-endpoint='https://example.com/csp-reports'" />
    <script src="main.js"></script>
    <title>CSP: Violation due to inline script</title>
  </head>
  <body>
    <h1>CSP: Violation due to inline script</h1>
    <script>
      const int = 4;
    </script>
  </body>
</html>

JavaScript (main.js)

Das obige Dokument lädt auch das externe Skript main.js, das unten gezeigt wird. Da dies von derselben Domain wie das HTML geladen wird, wird es nicht von der CSP blockiert.

Das Skript erstellt einen neuen ReportingObserver, um Berichte über Inhaltsverletzungen des Typs "csp-violation" zu beobachten. Jedes Mal, wenn die Callback-Funktion aufgerufen wird, erhalten wir den Body des ersten Eintrags im Berichtsarray und verwenden ihn, um die effectiveDirective und originalPolicy der Verletzung in der Konsole zu protokollieren.

// main.js
const observer = new ReportingObserver(
  (reports, observer) => {
    console.log(`effectiveDirective: ${reports[0].body.effectiveDirective}`);
    // effectiveDirective: script-src-elem
    console.log(`originalPolicy: ${reports[0].body.originalPolicy}`);
    // originalPolicy: default-src 'self'; report-to csp-endpoint
  },
  {
    types: ["csp-violation"],
    buffered: true,
  },
);

observer.observe();

Beachten Sie, dass es zwar mehrere Berichte im zurückgegebenen Array geben kann, wir aus Gründen der Kürze jedoch nur die Werte des ersten Elements protokollieren.

Ergebnisse

Die Konsolenausgabe für den obigen Code ist:

effectiveDirective: script-src-elem
originalPolicy: default-src 'self'; report-to csp-endpoint

Beachten Sie, dass die originalPolicy mit dem <meta>-Inhalt der Content-Security-Policy-Direktive im HTML übereinstimmt und angibt, dass die Richtlinie standardmäßig self ist (default-src 'self').

Die effectiveDirective ist script-src-elem, die gültige Quellen für JavaScript-<script>-Elemente festlegt. Dies ist die spezifische Direktive, die tatsächlich verletzt wurde, obwohl default-src in der Richtlinie festgelegt war.

Spezifikationen

Specification
Content Security Policy Level 3 # dom-cspviolationreportbody-effectivedirective

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch

SecurityPolicyViolationEvent.effectiveDirective