Im Sinne einer Content-Security-Policy und um Cross-Site-Scripting zu verhindern, sollten Webmaster sämtliche Skripte in gesonderte Dateien auslagern, statt sie direkt im Quellcode der Homepage einzubetten. Die CSP funktioniert dann nach dem Prinzip einer Whitelist: Im Header werden die Quellen genannt, aus denen Skripte und Daten geladen werden dürfen. Sollte ein fremdes Skript unerkannt in den HTML-Code der Seite eingeschleust worden sein und nun versuchen, externe Daten zu laden, muss der Browser des Nutzers dieses verbieten. Standardmäßig blockiert eine CSP alle Skripte, die sich direkt im Code befinden (Inline-Skripte). So werden sowohl die Website als auch der Internetnutzer – und vor allem dessen sensible Daten – geschützt.
Manipulationen durch Cross-Site-Scripting sind für Cyberkriminelle relativ leicht durchzuführen. Fast jede Seite im World Wide Web besitzt ein Eingabefeld: z. B. Kommentarfunktion, Suchleiste oder Log-in-Feld. Statt einfachem Text können dort auch Skripte eingefügt werden. Wenn der Server nicht entsprechend abgesichert ist, implementieren Kriminelle auf diesem Weg Phishing-Interfaces, bringen die gesamte Website zum Erliegen oder erlangen durch Schadsoftware die Kontrolle über den Webbrowser des Nutzers. CSP (oder richtiger: das entsprechende Headerfeld) teilt dem Webbrowser mit, aus welchen Quellen er Daten laden darf. Ist die Policy im Code der Website implementiert, wird der Versuch, über XSS eingeschleusten Code abzurufen, mit einer Fehlermeldung beantwortet.
Über die Content-Security-Policy können Webmaster aber auch viele weitere Einstellungen vornehmen, beispielweise durch diese Direktiven:
- base-uri: Beschränkt die URLs, die im <base>-Element der Webpage auftauchen dürfen.
- child-src: Legt fest, aus welchen Quellen Daten in Frames auftauchen dürfen, z. B. bei eingebetteten Videos von Drittanbietern.
- connect-src: Beschränkt die Quellen, mit denen sich die Seite verbinden kann, z. B. über Links.
- font-src: Bestimmt die Quellen, aus denen Schriftarten geladen werden dürfen.
- form-action: Stellt eine Liste von gültigen Endpunkten in Formularen bereit.
- frame-ancestors: Legt fest, welche Domains die Seite in Frames und iFrames einbauen dürfen.
- img-src: Beschränkt die Quellen, aus denen Bilder geladen werden dürfen.
- media-src: Legt fest, aus welchen Quellen Audio- und Video-Formate geladen werden dürfen.
- object-src: Definiert die Kontrolle über Flash und andere Plug-ins.
- plugin-types: Limitiert die Arten von Plug-ins.
- report-uri: Spezifiziert eine URL, an die Berichte geschickt werden, wenn gegen die Sicherheitsmaßnahmen verstoßen wurde.
- script-src: Bestimmt, welche Quellen für JavaScript erlaubt sind.
- style-src: Funktioniert wie script-src, wird allerdings bei Stylesheets angewendet.
- upgrade-insecure-requests: Legt fest, dass unsichere Seiten mit HTTP wie HTTPS-Seiten behandelt werden.
- sandbox: Verschiebt die betreffende Seite in eine Sandbox, in der u. a. Formulare, Pop-ups und Skripte verboten sind.
Diese Direktiven gelten nur, wenn sie ausdrücklich gesetzt sind. Ansonsten stehen sie standardmäßig offen und stellen somit eine Sicherheitslücke dar. Mit der default-src lässt sich dies allerdings ändern: Hier können Sie den standardmäßigen Zustand aller Direktiven festlegen, die mit -src enden. Statt diese offen zu lassen, stellen Sie z. B. ein, dass nur Daten aus Ihrer eigenen Website geladen werden dürfen, es sei denn, Sie haben es im HTTP-Header einer einzelnen Webpage anders festgelegt. In gesonderten Direktiven fügen Sie dann noch weitere Quellen hinzu.
In das Header-Feld können Sie beliebig viele Direktiven eintragen. Möchten Sie mehrere Direktiven aufnehmen, trennen Sie diese durch Semikolons. Außerdem müssen Sie als Webmaster alle Quellen innerhalb einer Direktive angeben. Mehrmalige Nennungen von gleichen Direktiven mit zusätzlichen Quellen wie im folgenden Beispiel sind nicht zulässig: