Content Security Policy

Mit einer Content Security Policy können Sie das Risiko und die Auswirkungen von Cross-Site-Scripting-Angriffen in modernen Browsern erheblich reduzieren.

Joe Medley

Mike West

Das Sicherheitsmodell des Webs basiert auf einer Same-Origin-Richtlinie. Beispiel: Code von https://mybank.com darf nur auf die Daten von https://mybank.com zugreifen und https://evil.example.com darf niemals Zugriff erhalten. Theoretisch ist jede Quelle vom Rest des Webs getrennt, was Entwicklern eine sichere Sandbox bietet. In der Praxis haben Angreifer jedoch mehrere Möglichkeiten gefunden, das System zu unterwandern.

Bei Cross-Site-Scripting-Angriffen (XSS) wird beispielsweise die Richtlinie zum gleichen Ursprung umgangen, indem eine Website dazu gebracht wird, schädlichen Code zusammen mit den beabsichtigten Inhalten zu senden. Das ist ein großes Problem, da Browser allen Code, der auf einer Seite angezeigt wird, als legitimen Teil des Sicherheitsursprungs dieser Seite vertrauen. Der XSS-Spickzettel bietet einen alten, aber repräsentativen Überblick über die Methoden, mit denen Angreifer möglicherweise bösartigen Code einschleusen, um gegen dieses Vertrauen zu verstoßen. Wenn ein Angreifer einen beliebigen Code einschleust, hat er die Nutzersitzung manipuliert und Zugriff auf private Daten erhalten.

Auf dieser Seite wird die Content Security Policy (CSP) als Strategie zur Reduzierung des Risikos und der Auswirkungen von XSS-Angriffen in modernen Browsern beschrieben.

Komponenten der CSP

So implementieren Sie eine effektive CSP:

• Über Zulassungslisten teilen Sie dem Kunden mit, was erlaubt ist und was nicht.
• Hier finden Sie Informationen zu den verfügbaren Richtlinien.
• Erkundigen Sie sich nach den Keywords, die sie akzeptieren.
• Schränken Sie die Verwendung von Inline-Code und eval() ein.
• Melden Sie Richtlinienverstöße an Ihren Server, bevor Sie sie erzwingen.

Zulassungslisten für Quellen

Bei XSS-Angriffen wird ausgenutzt, dass der Browser nicht zwischen Script unterscheiden kann, das zu Ihrer Anwendung gehört, und Script, das von einem Dritten böswillig eingeschleust wurde. Beispielsweise wird über die Google +1-Schaltfläche unten auf dieser Seite Code von https://apis.google.com/js/plusone.js im Kontext der Herkunft dieser Seite geladen und ausgeführt. Wir vertrauen diesem Code, aber wir können nicht davon ausgehen, dass der Browser selbst herausfindet, dass Code von apis.google.com sicher ausgeführt werden kann, während Code von apis.evil.example.com wahrscheinlich nicht sicher ist. Der Browser lädt und führt jeden Code herunter, den eine Seite anfordert, unabhängig von der Quelle.

Mit dem Content-Security-Policy-HTTP-Header von CSP können Sie eine Zulassungsliste mit Quellen für vertrauenswürdige Inhalte erstellen und dem Browser mitteilen, nur Ressourcen aus diesen Quellen auszuführen oder zu rendern. Selbst wenn ein Angreifer eine Lücke findet, über die er ein Script einschleusen kann, entspricht das Script nicht der Zulassungsliste und wird daher nicht ausgeführt.

Wir vertrauen darauf, dass apis.google.com gültigen Code liefert, und wir vertrauen darauf, dass wir das auch tun. Hier ist eine Beispielrichtlinie, mit der Scripts nur ausgeführt werden dürfen, wenn sie aus einer dieser beiden Quellen stammen:

Content-Security-Policy: script-src 'self' https://apis.google.com

script-src ist eine Anweisung, die eine Reihe von scriptbezogenen Berechtigungen für eine Seite steuert. Dieser Header 'self' ist eine gültige Scriptquelle und https://apis.google.com eine andere. Der Browser kann jetzt JavaScript von apis.google.com über HTTPS sowie vom Ursprung der aktuellen Seite herunterladen und ausführen, aber nicht von anderen Ursprüngen. Wenn ein Angreifer Code in Ihre Website einschleust, gibt der Browser einen Fehler aus und führt das eingeschleuste Script nicht aus.

Die Richtlinie gilt für eine Vielzahl von Ressourcen

CSP bietet eine Reihe von Richtlinien, mit denen die Ressourcen, die auf einer Seite geladen werden dürfen, detailliert gesteuert werden können, einschließlich script-src aus dem vorherigen Beispiel.

In der folgenden Liste sind die übrigen Ressourcenanweisungen für Ebene 2 aufgeführt. Es wurde eine Spezifikation der Ebene 3 entworfen, die jedoch in den Hauptbrowsern weitgehend nicht implementiert ist.

base-uri

Schränkt die URLs ein, die im <base>-Element einer Seite erscheinen können.

child-src

Die URLs für Worker und eingebettete Frame-Inhalte. Zum Beispiel ermöglicht child-src https://youtube.com das Einbetten von Videos von YouTube, aber nicht von anderen Quellen.

connect-src

Schränkt die Ursprünge ein, zu denen Sie über XHR, WebSockets und EventSource eine Verbindung herstellen können.

font-src

Gibt die Quellen an, aus denen Webschriftarten bereitgestellt werden können. Sie können beispielsweise die Webschriften von Google mit font-src https://themes.googleusercontent.com zulassen.

form-action

Listet gültige Endpunkte für die Einreichung von <form>-Tags auf.

frame-ancestors

Gibt die Quellen an, in die die aktuelle Seite eingebettet werden kann. Diese Anweisung gilt für <frame>-, <iframe>-, <embed>- und <applet>-Tags. Sie kann nicht in <meta>-Tags oder für HTML-Ressourcen verwendet werden.

frame-src

Diese Direktive wurde auf Ebene 2 eingestellt, aber auf Ebene 3 wiederhergestellt. Ist das nicht der Fall, greift der Browser auf child-src zurück.

img-src

Definiert die Ursprünge, von denen Bilder geladen werden können.

media-src

Schränkt die Ursprünge ein, die zur Bereitstellung von Video und Audio zulässig sind.

object-src

Ermöglicht die Steuerung von Flash und anderen Plug-ins.

plugin-types

Schränkt die Arten von Plug-ins ein, die eine Seite aufrufen kann.

report-uri

Gibt eine URL an, an die der Browser Berichte sendet, wenn ein Verstoß gegen eine Content Security Policy vorliegt. Diese Direktive kann nicht in <meta>-Tags verwendet werden.

style-src

Schränkt die Ursprünge ein, von denen eine Seite Stylesheets verwenden kann.

upgrade-insecure-requests

Er weist User-Agents an, URL-Schemas umzuschreiben, indem HTTP in HTTPS geändert wird. Diese Richtlinie gilt für Websites mit einer großen Anzahl von alten URLs, die umgeschrieben werden müssen.

worker-src

Eine CSP-Richtlinie der Ebene 3, die die URLs einschränkt, die als Worker, freigegebener Worker oder Dienst-Worker geladen werden können. Seit Juli 2017 ist diese Richtlinie eingeschränkt implementiert.

Standardmäßig lädt der Browser die verknüpfte Ressource ohne Einschränkungen von jeder Quelle, es sei denn, Sie legen eine Richtlinie mit einer bestimmten Anweisung fest. Wenn Sie die Standardeinstellung überschreiben möchten, geben Sie eine default-src-Anweisung an. Mit dieser Anweisung werden die Standardwerte für alle nicht angegebenen Anweisungen definiert, die auf -src enden. Wenn Sie beispielsweise default-src auf https://example.com festlegen und keine font-src-Anweisung angeben, können Sie nur Schriftarten aus https://example.com laden.

default-src wird in den folgenden Anweisungen nicht als Fallback verwendet. Wenn Sie sie nicht festlegen, entspricht das dem Zulassen aller Zugriffe:

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

Grundlegende CSP-Syntax

Wenn Sie CSP-Richtlinien verwenden möchten, listen Sie sie im HTTP-Header auf. Die Richtlinien müssen durch Doppelpunkte getrennt sein. Geben Sie alle erforderlichen Ressourcen eines bestimmten Typs in einer einzigen Direktive an:

script-src https://host1.com https://host2.com

Im Folgenden finden Sie ein Beispiel für mehrere Anweisungen, in diesem Fall für eine Webanwendung, die alle Ressourcen aus einem Content Delivery Network unter https://cdn.example.net lädt und keine geframeten Inhalte oder Plug-ins verwendet:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Implementierungsdetails

Moderne Browser unterstützen den Content-Security-Policy-Header ohne Präfix. Dies ist die empfohlene Überschrift. Die Header X-WebKit-CSP und X-Content-Security-Policy, die Sie möglicherweise in Onlineanleitungen sehen, werden nicht mehr unterstützt.

CSP wird auf Seitenebene definiert. Sie müssen den HTTP-Header mit jeder Antwort senden, die Sie schützen möchten. So können Sie die Richtlinie für bestimmte Seiten anhand ihrer spezifischen Anforderungen optimieren. Wenn beispielsweise einige Seiten Ihrer Website eine Schaltfläche „Mag ich“ haben, andere aber nicht, können Sie festlegen, dass der Code für die Schaltfläche nur bei Bedarf geladen wird.

Die Quellenliste für jede Richtlinie ist flexibel. Sie können Quellen nach Schema (data:, https:) oder mit einer Spezifität von nur Hostname (example.com, was jedem Ursprung auf diesem Host entspricht: beliebiges Schema, beliebiger Port) bis zu einem voll qualifizierten URI (https://example.com:443, der nur HTTPS, nur example.com und nur Port 443 entspricht) angeben. Platzhalter sind zulässig, aber nur als Schema, Port oder an der äußersten linken Position des Hostnamens: *://*.example.com:* würde mit allen Subdomains von example.com (aber nicht mit example.com selbst) über jedes Schema und jeden Port übereinstimmen.

Die Quellenliste akzeptiert auch vier Keywords:

• 'none' stimmt mit nichts überein.
• 'self' stimmt mit dem aktuellen Ursprung überein, aber nicht mit seinen Subdomains.
• In 'unsafe-inline' ist Inline-JavaScript und -CSS zulässig. Weitere Informationen finden Sie unter Inline-Code vermeiden.
• 'unsafe-eval' ermöglicht Text-in-JavaScript-Mechanismen wie eval. Weitere Informationen finden Sie unter eval() vermeiden.

Diese Keywords müssen in einfache Anführungszeichen gesetzt werden. Mit script-src 'self' (in Anführungszeichen) wird beispielsweise die Ausführung von JavaScript vom aktuellen Host autorisiert. script-src self (ohne Anführungszeichen) erlaubt JavaScript von einem Server namens „self“ (und nicht vom aktuellen Host), was wahrscheinlich nicht Ihre Absicht war.

Seiten in einer Sandbox ausführen

Es gibt noch eine weitere Direktive, die es wert ist, erwähnt zu werden: sandbox. Es unterscheidet sich ein wenig von den anderen, die wir uns angesehen haben, da hier die Aktionen, die eine Seite ausführen kann, und nicht die Ressourcen, die sie laden kann, eingeschränkt werden. Wenn die sandbox-Anweisung vorhanden ist, wird die Seite so behandelt, als wäre sie in einem <iframe> mit einem sandbox-Attribut geladen worden. Das kann eine Vielzahl von Auswirkungen auf die Seite haben, z. B. die Erzwingung eines eindeutigen Ursprungs der Seite und die Verhinderung der Formulareinreichung. Dies geht etwas über den Rahmen dieser Seite hinaus, aber vollständige Details zu gültigen Sandbox-Attributen finden Sie im Abschnitt „Sandboxing“ der HTML5-Spezifikation.

Das Meta-Tag

Der bevorzugte Übermittlungsmechanismus von CSPs ist ein HTTP-Header. Es kann jedoch hilfreich sein, eine Richtlinie für eine Seite direkt im Markup festzulegen. Dazu verwenden Sie ein <meta>-Tag mit einem http-equiv-Attribut:

<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

Diese Funktion kann nicht für frame-ancestors, report-uri oder sandbox verwendet werden.

Inline-Code vermeiden

So leistungsstark die richtlinienbasierten Zulassungslisten in CSP-Richtlinien auch sind, können sie die größte Bedrohung durch XSS-Angriffe nicht beheben: die Inline-Script-Injection. Wenn ein Angreifer ein Script-Tag einschleusen kann, das direkt einen schädlichen Nutzlastcode (z. B. <script>sendMyDataToEvilDotCom()</script>) enthält, kann der Browser es nicht von einem legitimen Inline-Script-Tag unterscheiden. Mit CSP wird dieses Problem gelöst, indem Inline-Script vollständig verboten wird.

Dieses Verbot gilt nicht nur für Scripts, die direkt in script-Tags eingebettet sind, sondern auch für Inline-Ereignishandler und javascript:-URLs. Sie müssen den Inhalt der script-Tags in eine externe Datei verschieben und javascript:-URLs und <a ... onclick="[JAVASCRIPT]"> durch entsprechende addEventListener()-Aufrufe ersetzen. Sie könnten beispielsweise Folgendes umschreiben:

<script>
    function doAmazingThings() {
    alert('YOU ARE AMAZING!');
    }
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>

in etwa so aussehen:

<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>

// amazing.js
function doAmazingThings() {
    alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
    document.getElementById('amazing')
    .addEventListener('click', doAmazingThings);
});

Der umgeschriebene Code ist nicht nur mit der CSP kompatibel, sondern auch mit den Best Practices für Webdesign ausgerichtet. Bei Inline-JavaScript werden Struktur und Verhalten auf eine Weise kombiniert, die den Code verwirrend macht. Außerdem ist das Caching und Kompilieren komplizierter. Wenn Sie Ihren Code in externe Ressourcen verschieben, steigern Sie die Leistung Ihrer Seiten.

Es wird außerdem dringend empfohlen, Inline-style-Tags und ‑Attribute in externe Stylesheets zu verschieben, um Ihre Website vor CSS-basierten Datenextraktionsangriffen zu schützen.

Inline-Scripts und ‑Styles vorübergehend zulassen

Sie können Inline-Scripts und ‑Styles aktivieren, indem Sie 'unsafe-inline' als zulässige Quelle in einer script-src- oder style-src-Anweisung hinzufügen. Mit CSP-Level 2 können Sie Ihrer Zulassungsliste auch bestimmte Inline-Scripts hinzufügen, entweder mit einer kryptografischen Nonce (einmal verwendete Zahl) oder einem Hash, wie unten beschrieben.

Wenn Sie ein Einmalpasswort verwenden möchten, geben Sie Ihrem Script-Tag das Attribut „nonce“ hinzu. Der Wert muss mit einem Wert in der Liste der vertrauenswürdigen Quellen übereinstimmen. Beispiel:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
    // Some inline code I can't remove yet, but need to as soon as possible.
</script>

Fügen Sie der script-src-Anweisung nach dem Keyword nonce- den Nonce hinzu:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Nonces müssen für jede Seitenanfrage neu generiert werden und dürfen nicht erraten werden können.

Hash-Werte funktionieren ähnlich. Anstatt dem Skript-Tag Code hinzuzufügen, erstellen Sie einen SHA-Hash des Skripts selbst und fügen Sie ihn der script-src-Anweisung hinzu. Angenommen, Ihre Seite enthält Folgendes:

<script>alert('Hello, world.');</script>

Ihre Richtlinie muss Folgendes enthalten:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Das Präfix sha*- gibt den Algorithmus an, mit dem der Hash generiert wird. Im vorherigen Beispiel wird sha256- verwendet, aber CSP unterstützt auch sha384- und sha512-. Lassen Sie beim Generieren des Hashwerts die <script>-Tags weg. Großschreibung und Leerzeichen, einschließlich voran- und nachgestellter Leerzeichen.

Lösungen zum Generieren von SHA-Hashes gibt es in beliebig vielen Sprachen. In Chrome 40 und höher können Sie die Entwicklertools öffnen und dann die Seite neu laden. Auf dem Tab „Konsole“ werden Fehlermeldungen mit dem korrekten SHA-256-Hash für jedes Ihrer Inline-Scripts angezeigt.

Auf eval() verzichten

Selbst wenn ein Angreifer kein Script direkt einschleusen kann, kann er Ihre Anwendung dazu bringen, Eingabetext in ausführbares JavaScript umzuwandeln und im eigenen Namen auszuführen. eval(), new Function(), setTimeout([string], …) und setInterval([string], ...) sind Angriffsvektoren, mit denen Angreifer Schadcode über eingeschleusten Text ausführen können. Die Standardreaktion der CSP auf dieses Risiko besteht darin, alle diese Vektoren vollständig zu blockieren.

Dies hat folgende Auswirkungen auf die Entwicklung von Anwendungen:

• Sie müssen JSON mit der integrierten Funktion JSON.parse parsen, anstatt sich auf eval zu verlassen. Sichere JSON-Vorgänge sind in allen Browsern seit IE8 verfügbar.

• Sie müssen alle setTimeout- oder setInterval-Aufrufe mit Inline-Funktionen anstelle von Strings neu schreiben. Angenommen, Ihre Seite enthält Folgendes:

  setTimeout("document.querySelector('a').style.display = 'none';", 10);
  

  Formuliere den Text so um:

  setTimeout(function () {
      document.querySelector('a').style.display = 'none';
  }, 10);
    ```
  

• Vermeiden Sie Inline-Vorlagen bei der Laufzeit. Viele Vorlagenbibliotheken verwenden new Function() häufig, um die Vorlagenerstellung zur Laufzeit zu beschleunigen, was die Auswertung schädlichen Texts ermöglicht. Einige Frameworks unterstützen CSP standardmäßig und greifen bei fehlender eval auf einen robusten Parser zurück. Die Anweisung ng-csp von AngularJS ist ein gutes Beispiel dafür. Wir empfehlen jedoch, stattdessen eine Vorlagensprache zu verwenden, die eine Vorkompilierung bietet, z. B. Handlebars. Wenn Sie Ihre Vorlagen vorkompilieren, kann die Nutzerfreundlichkeit sogar noch höher sein als bei der schnellsten Laufzeitimplementierung. Außerdem wird Ihre Website sicherer.

Wenn eval() oder andere Text-zu-JavaScript-Funktionen für Ihre Anwendung erforderlich sind, können Sie sie aktivieren, indem Sie 'unsafe-eval' in einer script-src-Anweisung als zulässige Quelle hinzufügen. Wir raten aufgrund des damit verbundenen Risikos von Codeinjektion dringend davon ab.

Richtlinienverstöße melden

Wenn Sie den Server über Fehler informieren möchten, die eine schädliche Injection ermöglichen, können Sie den Browser anweisen, POSTJSON-formatierte Verstoßberichte an einen in einer report-uri-Richtlinie angegebenen Speicherort zu senden:

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Diese Berichte sehen so aus:

{
    "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
    }
}

Der Bericht enthält hilfreiche Informationen zur Ursache eines Richtlinienverstoßes, einschließlich der Seite, auf der er aufgetreten ist (document-uri), des referrer der Seite, der Ressource, die gegen die Richtlinie der Seite verstößt (blocked-uri), der spezifischen Richtlinie, gegen die verstoßen wurde (violated-directive) und der vollständigen Richtlinie für die Seite (original-policy).

Nur Berichterstellung

Wenn Sie gerade erst mit der CSP beginnen, empfehlen wir, den Berichtsmodus zu verwenden, um den Status Ihrer App zu bewerten, bevor Sie die Richtlinie ändern. Senden Sie dazu statt eines Content-Security-Policy-Headers einen Content-Security-Policy-Report-Only-Header:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Die im Modus „Nur melden“ angegebene Richtlinie blockiert eingeschränkte Ressourcen nicht, sendet aber Verstoßberichte an den von Ihnen angegebenen Speicherort. Sie können sogar beide Header senden, um eine Richtlinie durchzusetzen und gleichzeitig eine andere zu überwachen. So können Sie Änderungen an Ihrer CSP testen und gleichzeitig Ihre aktuelle Richtlinie erzwingen: Aktivieren Sie die Meldungen für eine neue Richtlinie, beobachten Sie die Meldungen zu Verstößen und beheben Sie alle Fehler. Wenn Sie mit der neuen Richtlinie zufrieden sind, können Sie sie erzwingen.

Praxisbeispiele

Der erste Schritt beim Erstellen einer Richtlinie für Ihre App besteht darin, die geladenen Ressourcen zu bewerten. Wenn Sie die Struktur Ihrer App kennen, erstellen Sie eine Richtlinie, die auf den Anforderungen basiert. In den folgenden Abschnitten werden einige gängige Anwendungsfälle und der Entscheidungsprozess für die Unterstützung dieser Fälle gemäß den CSP-Richtlinien erläutert.

Widgets für soziale Medien

• Die Facebook-Magie-Schaltfläche bietet mehrere Implementierungsoptionen. Wir empfehlen, die <iframe>-Version zu verwenden, damit sie vom Rest Ihrer Website getrennt bleibt. Es benötigt eine child-src https://facebook.com-Direktive, um ordnungsgemäß zu funktionieren.
• Die Tweet-Schaltfläche von X benötigt Zugriff auf ein Script. Verschieben Sie das bereitgestellte Skript in eine externe JavaScript-Datei und verwenden Sie die Anweisung script-src https://platform.twitter.com; child-src https://platform.twitter.com.
• Andere Plattformen haben ähnliche Anforderungen und können auf ähnliche Weise angegangen werden. Wenn Sie diese Ressourcen testen möchten, empfehlen wir Ihnen, einen default-src von 'none' festzulegen und in der Konsole zu prüfen, welche Ressourcen Sie aktivieren müssen.

Um mehrere Widgets zu verwenden, kombinieren Sie die Anweisungen wie folgt:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Gesperrt

Bei einigen Websites sollten Sie dafür sorgen, dass nur lokale Ressourcen geladen werden können. Im folgenden Beispiel wird eine CSP für eine Banking-Website entwickelt. Dabei wird mit einer Standardrichtlinie begonnen, die alles blockiert (default-src 'none').

Die Website lädt alle Bilder, Stile und Scripts von einem CDN unter https://cdn.mybank.net und stellt über XHR eine Verbindung zu https://api.mybank.com/ her, um Daten abzurufen. Es werden Frames verwendet, aber nur für Seiten, die lokal auf der Website sind (keine Drittanbieterquellen). Es gibt kein Flash auf der Website, keine Schriftarten und keine Extras. Der restriktivste CSP-Header, den er senden kann, ist:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Nur SSL

Im Folgenden finden Sie ein Beispiel für einen CSP für einen Forumsadministrator, der dafür sorgen möchte, dass alle Ressourcen in seinem Forum nur über sichere Kanäle geladen werden. Er hat jedoch keine Erfahrung mit Programmieren und verfügt nicht über die Ressourcen, um die Forumssoftware von Drittanbietern mit vielen Inline-Scripts und ‑Styles neu zu schreiben:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Obwohl https: in default-src angegeben ist, übernehmen die Skript- und Stilanweisungen diese Quelle nicht automatisch. Jede Anweisung überschreibt den Standardwert für diesen spezifischen Ressourcentyp.

Entwicklung des CSP-Standards

Content Security Policy Level 2 ist ein vom W3C empfohlener Standard. Die Arbeitsgruppe für Web Application Security von W3C entwickelt die nächste Spezifikationsversion: Content Security Policy Level 3.

Sie können die Diskussionen zu diesen neuen Funktionen in den Mailinglistenarchiven "public-webappsec@" verfolgen.