Content Security Policy

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

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. Das XSS-Cheatsheet ist ein alter, aber repräsentativer Querschnitt der Methoden, mit denen Angreifer dieses Vertrauen durch Einschleusen von schädlichem Code missbrauchen können. 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:

• Mithilfe von Zulassungslisten können Sie dem Kunden mitteilen, was zulässig ist und was nicht.
• Informationen zu 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 dies wahrscheinlich nicht 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, um ein Script einzuschleusen, 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 restlichen Ressourcenrichtlinien auf Ebene 2 aufgeführt. Eine Spezifikation für Level 3 wurde bereits erstellt, ist aber in den gängigen Browsern weitgehend nicht implementiert.

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. Mit child-src https://youtube.com können beispielsweise Videos von YouTube, aber nicht von anderen Quellen eingebettet werden.

connect-src

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

font-src

Gibt die Ursprünge an, von denen Webschriften 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 auf einer Seite aufgerufen werden können.

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. Stand Juli 2017 gibt es nur wenige Implementierungen dieser Richtlinie.

Standardmäßig lädt der Browser die verknüpfte Ressource von jedem Ursprung ohne Einschränkungen, es sei denn, Sie legen eine Richtlinie mit einer bestimmten Anweisung fest. Wenn Sie den Standardwert ü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 setzen und keine font-src-Richtlinie angeben, können Sie Schriftarten nur von https://example.com laden.

Bei den folgenden Anweisungen wird default-src 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 und trennen Sie die Richtlinien durch Doppelpunkte. 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 an ihre spezifischen Anforderungen anpassen. Wenn beispielsweise einige Seiten Ihrer Website eine „+1“-Schaltfläche 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 nach Spezifität angeben, z. B. nur nach Hostnamen (example.com, entspricht jedem Ursprung auf diesem Host: beliebiges Schema, beliebiger Port) oder nach einem vollständig qualifizierten URI (https://example.com:443, entspricht nur HTTPS, nur example.com und nur Port 443). 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.
• 'unsafe-inline' unterstützt Inline-JavaScript und Inline-CSS. Weitere Informationen finden Sie unter Inline-Code vermeiden.
• 'unsafe-eval' erlaubt Text-zu-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 testen

Es gibt noch eine weitere Direktive, die es wert ist, erwähnt zu werden: sandbox. Sie unterscheidet sich ein wenig von den anderen, die wir uns angesehen haben, da sie Einschränkungen für Aktionen auf der Seite und nicht für Ressourcen auf der Seite vornimmt. 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 Bereitstellungsmechanismus der CSP ist ein HTTP-Header. Es kann jedoch hilfreich sein, eine Richtlinie für eine Seite direkt im Markup festzulegen. Verwenden Sie dazu 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 in CSP-Richtlinien verwendeten anbieterbasierten Zulassungslisten auch sind, können sie die größte Bedrohung durch XSS-Angriffe nicht beseitigen: 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:

<!-- 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 neu geschriebene Code ist nicht nur mit CSP kompatibel, sondern entspricht auch den Best Practices für Webdesign. 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, können Sie die Leistung Ihrer Seiten verbessern.

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' in einer script-src- oder style-src-Anweisung als zulässige Quelle hinzufügen. Mit CSP-Level 2 können Sie Ihrer Zulassungsliste auch bestimmte Inline-Scripts hinzufügen, entweder mit einer kryptografischen Nonce (einmalig verwendete Zahl) oder einem Hash.

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.

Hashes funktionieren ähnlich. Anstatt dem Script-Tag Code hinzuzufügen, erstellen Sie einen SHA-Hash des Scripts 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ß- und Kleinschreibung sowie Leerzeichen, einschließlich vorangestellter und nachgestellter Leerzeichen, sind wichtig.

Lösungen zum Generieren von SHA-Hashes sind in beliebig vielen Sprachen verfügbar. 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 des 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 mithilfe von Inline-Funktionen anstelle von Strings neu schreiben. Angenommen, Ihre Seite enthält Folgendes:

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

  Formulieren Sie ihn 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 ng-csp-Richtlinie 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 dringend davon ab, da das Risiko von Code-Injection besteht.

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 CSP beginnen, empfehlen wir Ihnen, den Modus „Nur Berichte“ zu verwenden, um den Status Ihrer App zu bewerten, bevor Sie Ihre Richtlinie ändern. Senden Sie dazu anstelle 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 Berichte“ 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 ist. 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 Script in eine externe JavaScript-Datei und verwenden Sie das Direktiv 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.

Wenn du mehrere Widgets verwenden möchtest, kombiniere die Anweisungen so:

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). Auf der Website gibt es kein Flash, keine Schriftarten und keine Extras. Der strengste CSP-Header, der gesendet werden 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 Inline-Scripts und ‑stilen neu zu schreiben:

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

Auch wenn https: in default-src angegeben ist, wird diese Quelle nicht automatisch von den Script- und Stilrichtlinien übernommen. Jede Anweisung überschreibt die Standardeinstellung für diesen bestimmten Ressourcentyp.

Entwicklung des CSP-Standards

Content Security Policy Level 2 ist ein vom W3C empfohlener Standard. Die Arbeitsgruppe für Webanwendungssicherheit des W3C entwickelt die nächste Iteration der Spezifikation, Content Security Policy Level 3.

Die Diskussion zu diesen anstehenden Funktionen finden Sie in den Archiven der Mailingliste „public-webappsec@“.