Content Security Policy

Die Content Security Policy kann das Risiko und die Auswirkungen von Cross-Site-Scripting-Angriffen in modernen Browsern erheblich reduzieren.

Joe Medley

Mike West

Unterstützte Browser

• 25
• 14
• 23
• 7

Quelle

Das Sicherheitsmodell des Webs basiert auf einer Same-Origin-Policy. Beispielsweise darf Code aus https://mybank.com nur auf die Daten von https://mybank.com zugreifen können und https://evil.example.com darf niemals Zugriff erhalten. Jeder Ursprung wird theoretisch vom Rest des Webs isoliert und bietet Entwicklern eine sichere Sandbox, in die sie sich einbauen können. In der Praxis haben Angreifer jedoch mehrere Möglichkeiten gefunden, das System zu stürzen.

Bei Cross-Site-Scripting-Angriffen (XSS) wird beispielsweise die Same-Origin-Policy umgangen, indem eine Website dazu verleitet wird, neben dem gewünschten Inhalt schädlichen Code zu senden. Das ist ein großes Problem, da Browser dem gesamten Code einer Seite vertrauen, der als legitimer Teil des Sicherheitsherkunftsorts dieser Seite gilt. Der XSS-Spickzettel ist ein alter, aber repräsentativer Querschnitt der Methoden, mit denen Angreifer Schadcode einschleusen, um dieses Vertrauen zu verletzen. Wenn ein Angreifer überhaupt einen Code einschleust, hat er die Nutzersitzung manipuliert und sich Zugriff auf private Informationen verschafft.

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

Komponenten der CSP

So implementieren Sie eine effektive CSP:

• Über Zulassungslisten können Sie dem Kunden mitteilen, was erlaubt ist und was nicht.
• Informationen zu den verfügbaren Anweisungen.
• Erfahre, welche Keywords sie verwenden.
• Schränken Sie die Verwendung von Inline-Code und eval() ein.
• Melden Sie Richtlinienverstöße an Ihren Server, bevor Sie sie erzwingen.

Quell-Zulassungslisten

Bei XSS-Angriffen wird die Unfähigkeit des Browsers ausgenutzt, zwischen einem Skript, das Teil Ihrer Anwendung ist, und einem Skript, das böswillig von einem Dritten eingeschleust wurde, zu unterscheiden. Über die Google +1-Schaltfläche unten auf dieser Seite wird beispielsweise Code von https://apis.google.com/js/plusone.js im Kontext des Ursprungs dieser Seite geladen und ausgeführt. Wir vertrauen diesem Code, aber wir können nicht erwarten, dass der Browser selbst erkennt, dass der 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 jeglichen Code, der von einer Seite angefordert wird, unabhängig von der Quelle herunter und führt ihn aus.

Mit dem HTTP-Header Content-Security-Policy der CSP können Sie eine Zulassungsliste mit Quellen mit vertrauenswürdigen Inhalten erstellen und den Browser anweisen, nur Ressourcen aus diesen Quellen auszuführen oder zu rendern. Selbst wenn ein Angreifer ein Loch zum Einschleusen eines Skripts finden kann, entspricht das Skript nicht der Zulassungsliste und wird daher nicht ausgeführt.

Wir vertrauen darauf, dass apis.google.com gültigen Code bereitstellt, und das tun wir auch selbst. Hier sehen Sie eine Beispielrichtlinie, die zulässt, dass Skripts nur ausgeführt werden, 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 skriptbezogenen Berechtigungen für eine Seite steuert. Dieser Header ist 'self' als eine gültige Skriptquelle und https://apis.google.com als weitere. Der Browser kann jetzt JavaScript-Code von apis.google.com über HTTPS sowie vom Ursprung der aktuellen Seite herunterladen und ausführen, jedoch nicht von einem anderen Ursprung. Wenn ein Angreifer Code in Ihre Website einschleust, gibt der Browser eine Fehlermeldung aus und führt das eingefügte Skript nicht aus.

In der Console wird ein Fehler angezeigt, wenn ein Script versucht, von einem Ursprung auszuführen, der nicht auf der Zulassungsliste steht.

Richtlinie gilt für eine Vielzahl von Ressourcen

Die CSP bietet eine Reihe von Richtlinienanweisungen, die eine detaillierte Kontrolle über die Ressourcen ermöglichen, die eine Seite laden darf, einschließlich der script-src aus dem vorherigen Beispiel.

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

base-uri

Damit werden die URLs eingeschränkt, die im <base>-Element einer Seite erscheinen können.

child-src

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

connect-src

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

font-src

Gibt die Ursprünge an, von denen Webschriftarten bereitgestellt werden können. Du kannst Web Fonts von Google beispielsweise mithilfe von font-src https://themes.googleusercontent.com zulassen.

form-action

Listet gültige Endpunkte für die Übermittlung aus <form> Tags auf.

frame-ancestors

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

frame-src

Diese Anweisung wurde in Stufe 2 eingestellt, wird aber in Stufe 3 wiederhergestellt. Ist er nicht vorhanden, verwendet der Browser child-src.

img-src

Definiert, aus welchem Ursprung Bilder geladen werden können.

media-src

Schränkt die Quellen ein, die für die Übermittlung von Video- und Audioinhalten zulässig sind.

object-src

Ermöglicht die Kontrolle über Flash und andere Plug-ins.

plugin-types

Die Arten von Plug-ins, die auf einer Seite aufgerufen werden können, werden eingeschränkt.

report-uri

Gibt eine URL an, an die der Browser Berichte sendet, wenn eine Content Security Policy verletzt wird. Diese Anweisung kann nicht in <meta>-Tags verwendet werden.

style-src

Mit dieser Option legen Sie fest, aus welchen Ursprüngen eine Seite Stylesheets verwenden darf.

upgrade-insecure-requests

Weist User-Agents an, URL-Schemas umzuschreiben, indem HTTP zu HTTPS geändert wird. Diese Anweisung ist für Websites mit einer großen Anzahl alter URLs vorgesehen, die neu geschrieben werden müssen.

worker-src

Eine CSP-Level-3-Anweisung, mit der die URLs eingeschränkt werden, die als Worker, freigegebene Worker oder Service Worker geladen werden können. Seit Juli 2017 gibt es eingeschränkte Implementierungen für diese Richtlinie.

Standardmäßig lädt der Browser die zugehörige Ressource von einem beliebigen Ursprung ohne Einschränkungen, sofern Sie keine Richtlinie mit einer bestimmten Anweisung festlegen. Wenn Sie die Standardeinstellung überschreiben möchten, geben Sie eine default-src-Anweisung an. Diese Anweisung definiert die Standardwerte für jede nicht angegebene Anweisung, die auf -src endet. 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.

In den folgenden Anweisungen wird default-src nicht als Fallback verwendet. Wenn Sie sie nicht festlegen, ist das gleichbedeutend mit der Zulassung:

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

Grundlegende CSP-Syntax

Wenn Sie CSP-Anweisungen verwenden möchten, listen Sie sie im HTTP-Header auf und trennen Sie die Anweisungen durch Doppelpunkte. Achten Sie darauf, alle erforderlichen Ressourcen eines bestimmten Typs in einer einzigen Anweisung aufzulisten:

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 Inhalte in Frames 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 Header Content-Security-Policy ohne Präfix. Dies ist der empfohlene Header. Die Header X-WebKit-CSP und X-Content-Security-Policy, die möglicherweise in Onlineanleitungen angezeigt werden, wurden eingestellt.

Die CSP wird seitenweise definiert. Sie müssen den HTTP-Header mit jeder Antwort senden, die Sie schützen möchten. Auf diese Weise können Sie die Richtlinie für bestimmte Seiten an deren spezifischen Anforderungen anpassen. Wenn beispielsweise eine Gruppe von Seiten Ihrer Website eine +1-Schaltfläche hat und andere nicht, können Sie zulassen, dass der Schaltflächencode nur bei Bedarf geladen wird.

Die Quellliste für jede Anweisung ist flexibel. Sie können Quellen nach Schema (data:, https:) oder in einer Spezifität von nur Hostnamen (example.com, der mit jedem Ursprung auf diesem Host: jedem Schema, jedem Port) übereinstimmt, bis zu einem voll qualifizierten URI (https://example.com:443, der nur mit HTTPS, nur example.com und nur Port 443 übereinstimmt) angeben. Platzhalter werden akzeptiert, jedoch nur als Schema, Port oder an der obersten Position des Hostnamens: *://*.example.com:* entspricht allen Subdomains von example.com (aber nicht example.com selbst), wobei ein beliebiges Portschema verwendet wird.

Die Quellenliste akzeptiert auch vier Keywords:

• Für 'none' gibt es keine Übereinstimmungen.
• 'self' stimmt mit dem aktuellen Ursprung, aber nicht mit seinen Subdomains überein.
• 'unsafe-inline' lässt Inline-JavaScript und -CSS zu. 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.

Für diese Keywords sind einfache Anführungszeichen erforderlich. Beispielsweise autorisiert script-src 'self' (mit Anführungszeichen) die Ausführung von JavaScript aus dem aktuellen Host und script-src self (ohne Anführungszeichen) lässt JavaScript von einem Server namens „self“ (und nicht vom aktuellen Host) zu, was Sie wahrscheinlich nicht genau meinen.

Seiten in einer Sandbox ausführen

Es gibt noch eine weitere Richtlinie, über die wir sprechen können: sandbox. Sie unterscheidet sich ein wenig von den anderen, die wir uns bereits angesehen haben, da hier Einschränkungen für Aktionen gelten, die die Seite ausführen kann, anstatt auf Ressourcen, die die Seite laden kann. Wenn die Anweisung sandbox vorhanden ist, wird die Seite so behandelt, als wäre sie in einem <iframe> mit einem sandbox-Attribut geladen. Dies kann verschiedene Auswirkungen auf die Seite haben: z. B. wird die Seite zu einem eindeutigen Ursprung gezwungen oder das Senden von Formularen verhindert. Dies würde den Rahmen dieser Seite etwas sprengen, aber Sie finden alle Details zu gültigen Sandbox-Attributen im Abschnitt "Sandboxing" der HTML5-Spezifikation.

Das Meta-Tag

Der bevorzugte Übermittlungsmechanismus der CSPs ist ein HTTP-Header. Es kann jedoch nützlich sein, direkt im Markup eine Richtlinie auf einer Seite festzulegen. Dazu verwendest du 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'">

Kann nicht für frame-ancestors, report-uri oder sandbox verwendet werden.

Inline-Code vermeiden

So leistungsstark wie die ursprungsbasierten Zulassungslisten, die in CSP-Anweisungen verwendet werden, können sie die größte Bedrohung durch XSS-Angriffe nicht lösen: die Inline-Skript-Einschleusung. Wenn ein Angreifer ein Skript-Tag einschleusen kann, das direkt schädliche Nutzlast enthält (z. B. <script>sendMyDataToEvilDotCom()</script>), hat der Browser keine Möglichkeit, dieses von einem legitimen Inline-Skript-Tag zu unterscheiden. Die CSP löst dieses Problem, indem sie Inline-Scripts vollständig verbietet.

Dieses Sperren umfasst nicht nur Skripts, die direkt in script-Tags eingebettet sind, sondern auch Inline-Event-Handler und javascript:-URLs. Sie müssen den Inhalt von script-Tags in eine externe Datei verschieben und javascript:-URLs sowie <a ... onclick="[JAVASCRIPT]"> durch entsprechende addEventListener()-Aufrufe ersetzen. Beispielsweise können Sie 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 entspricht auch den Best Practices für Webdesign. Inline-JavaScript vermischt Struktur und Verhalten auf eine Weise, die den Code verwirrend macht. Außerdem ist es komplizierter, diese im Cache zu speichern und zu kompilieren. Wenn Sie Ihren Code in externe Ressourcen verlagern, können Sie die Leistung Ihrer Seiten verbessern.

Das Verschieben von Inline-style-Tags und -Attributen in externe Stylesheets wird ebenfalls dringend empfohlen, um Ihre Website vor CSS-basierten Daten-Exfiltrationsangriffen zu schützen.

Inline-Scripts und Stile vorübergehend zulassen

Warnung: Das Sperren von Inline-Skripts und Stilen ist die wichtigste Sicherheitsfunktion der CSP. Verwenden Sie diese Methoden nur, wenn ein Script oder Stylesheet unbedingt inline sein muss.

Sie können Inline-Skripts und Stile 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-Skripts hinzufügen. Verwenden Sie dazu entweder eine kryptografische Nonce (einmal verwendete Nummer) oder einen Hash wie folgt.

Um eine Nonce zu verwenden, weisen Sie Ihrem Skript-Tag ein Nonce-Attribut zu. Der Wert muss mit einer 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 die Nonce Ihrer script-src-Anweisung nach dem nonce--Keyword hinzu:

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

Nonces müssen für jede Seitenanfrage neu generiert werden und lassen sich nicht erraten.

Hashes funktionieren ähnlich. Statt Code in das Skript-Tag einzufügen, erstellen Sie einen SHA-Hash-Wert des Skripts selbst und fügen ihn der Anweisung script-src hinzu. Angenommen, Ihre Seite enthält Folgendes:

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

Ihre Bedingungen müssen Folgendes enthalten:

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

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

Lösungen zum Generieren von SHA-Hashes sind in beliebig vielen Sprachen verfügbar. Wenn Sie Chrome 40 oder höher verwenden, können Sie die Entwicklertools öffnen und Ihre Seite dann aktualisieren. Auf dem Tab „Console“ werden Fehlermeldungen mit dem richtigen SHA-256-Hash für jedes Inline-Script angezeigt.

Auf eval() verzichten

Selbst wenn ein Angreifer das Skript nicht direkt einschleusen kann, ist er möglicherweise in der Lage, Ihre Anwendung dazu zu bringen, Eingabetext in ausführbaren JavaScript zu konvertieren und in seinem Namen auszuführen. eval(), new Function(), setTimeout([string], …) und setInterval([string], ...) sind Vektoren, mit denen Angreifer schädlichen Code über injizierten 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 Art und Weise, wie Sie Anwendungen erstellen:

• Sie müssen JSON mit dem integrierten JSON.parse parsen, anstatt eval zu verwenden. Sichere JSON-Vorgänge sind seit IE8 in jedem Browser verfügbar.

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

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

  Umformulieren wie:

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

• Vermeiden Sie Inline-Vorlagen zur Laufzeit. Viele Vorlagenbibliotheken verwenden häufig new Function(), um die Vorlagengenerierung während der Laufzeit zu beschleunigen und so die Auswertung von schädlichem Text zu ermöglichen. Einige Frameworks unterstützen die CSP standardmäßig und greifen auf einen robusten Parser zurück, falls eval fehlt. Die Anweisung „ng-csp“ von AngularJS ist ein gutes Beispiel dafür. Wir empfehlen stattdessen jedoch eine Vorlagensprache mit Vorkompilierung, z. B. Handles. Durch das Vorkompilieren Ihrer Vorlagen wird die Nutzererfahrung noch schneller als die schnellste Laufzeitimplementierung und Ihre Website wird sicherer.

Wenn eval() oder andere Text-in-JavaScript-Funktionen für Ihre Anwendung erforderlich sind, können Sie sie aktivieren, indem Sie 'unsafe-eval' als zulässige Quelle in eine script-src-Anweisung einfügen. Wir raten dringend davon ab, da das Risiko einer Code-Einschleusung besteht.

Richtlinienverstöße melden

Um den Server über Fehler zu informieren, die eine schädliche Einschleusung verhindern können, können Sie den Browser auffordern, Berichte zu Verstößen im JSON-Format an einen in einer report-uri-Anweisung angegebenen Ort zu POST:

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 dazu, wie Sie die Ursache eines Richtlinienverstoßes finden können. Dazu gehören die Seite, auf der der Verstoß aufgetreten ist (document-uri), die referrer dieser Seite, die Ressource, die gegen die Richtlinie der Seite verstoßen hat (blocked-uri), die spezifische Richtlinie, gegen die der Verstoß verstoßen hat (violated-directive) und die vollständige Richtlinie der Seite (original-policy).

Nur Bericht

Wenn Sie gerade erst mit der CSP angefangen haben, sollten Sie den Modus „Nur Bericht“ verwenden, um den Status Ihrer App zu bewerten, bevor Sie Ihre 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 Richtlinie, die im Modus „Nur Bericht“ festgelegt ist, blockiert keine eingeschränkten Ressourcen, sendet aber Berichte zu Verstößen an den von Ihnen angegebenen Standort. Sie können sogar beide Header senden, um eine Richtlinie zu erzwingen und gleichzeitig eine andere zu überwachen. Dies ist eine gute Möglichkeit, Änderungen an Ihrer CSP zu testen und gleichzeitig die aktuelle Richtlinie durchzusetzen: Aktivieren Sie die Berichterstellung für eine neue Richtlinie, behalten Sie die Berichte zu Verstößen im Blick und beheben Sie etwaige Fehler. Wenn Sie mit der neuen Richtlinie zufrieden sind, können Sie mit der Durchsetzung beginnen.

Verwendung in der Praxis

Der erste Schritt beim Erstellen einer Richtlinie für Ihre Anwendung besteht darin, die von ihr geladenen Ressourcen zu bewerten. Wenn Sie die Struktur Ihrer App verstanden haben, können Sie basierend auf den Anforderungen eine Richtlinie erstellen. In den folgenden Abschnitten werden einige häufige Anwendungsfälle und der Entscheidungsprozess für die Einhaltung der CSP-Richtlinien beschrieben.

Widgets für soziale Medien

• Die Gefällt mir-Schaltfläche von Facebook bietet mehrere Implementierungsoptionen. Wir empfehlen, die <iframe>-Version zu verwenden, damit sie im Sandbox-Modus auf der restlichen Website bleibt. Es benötigt eine child-src https://facebook.com-Anweisung, 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 die Anweisung script-src https://platform.twitter.com; child-src https://platform.twitter.com.
• Andere Plattformen haben ähnliche Anforderungen und können ähnlich behandelt werden. Zum Testen dieser Ressourcen empfehlen wir, für default-src den Wert 'none' festzulegen und in der Konsole zu beobachten, welche Ressourcen Sie aktivieren müssen.

Kombinieren Sie die Anweisungen wie folgt, um mehrere Widgets zu verwenden:

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

Sperren

Bei einigen Websites kann es sinnvoll sein, nur lokale Ressourcen zu laden. Im folgenden Beispiel wird eine CSP für eine Bankwebsite entwickelt, beginnend mit einer Standardrichtlinie, die alles blockiert (default-src 'none').

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

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 eine Beispiel-CSP für einen Forumsadministrator, der sicherstellen möchte, dass alle Ressourcen in seinem Forum nur über sichere Kanäle geladen werden, aber keine Programmiererfahrung hat und nicht über die Ressourcen verfügt, um die Forensoftware von Drittanbietern mit Inline-Skripts und Stilen umzuschreiben:

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

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

CSP-Standardentwicklung

Die Content Security Policy Stufe 2 ist ein von W3C empfohlener Standard. Die Arbeitsgruppe zur Sicherheit von Webanwendungen von W3C entwickelt derzeit die nächste Iteration der Spezifikation: Content Security Policy Level 3.

Informationen zu diesen neuen Funktionen finden Sie in den Archiven von Mailinglisten öffentliche-Webanwendungsec@.