Content-Security-Policy (CSP)
So können Sie eine Inhaltsicherheitsrichtlinie einsetzen:
Anleitung: Die Content Security Policy erstellen
Die Content Security Policy (CSP) ist ein von Mozilla entwickelter Sicherheitsmechanismus, der im letzten Jahr erheblich an Popularität gewonnen hat. Diese Inhaltsicherheitsrichtlinie ist eine zusätzliche Sicherheitsebene, die Sie relativ einfach einsetzen können.
Wenn Sie die Sicherheitsmechanismen für Ihre Webseite verbessern möchten, ist die Einrichtung einer Content Security Policy (CSP) eine ausgezeichnete Maßnahme.
Dieser Mechanismus fungiert als Whitelist und hat zum Zweck, festzulegen, wie der Browser Ressourcen wie Skripte, Schriftarten, Bilder, CSS, Medien, Applets usw. lädt.
CSP wird derzeit als sehr effektiver Schutz vor Cross-Site-Scripting-Angriffen (XSS) gehandelt. Sie hilft dabei, einige Arten von Webangriffen, wie Datendiebstahl, Unkenntlichmachung von Websites oder die Verbreitung von Malware, zu erkennen und abzuwehren.
Hier zeigen wir Ihnen mit Code-Beispielen, wie Sie CSP in verschiedenen Serverumgebungen hinzufügen können.
Die Wahl zwischen Whitelist CSP und Strict CSP
Unsere Anleitungen und kostenlos bereitgestellten Code-Beispiele konzentrieren sich auf das Whitelist-CSP-Prinzip, das die erlaubten Quellen für Skripte und Daten definiert. Web-Entwickler sollten dringend alle Skripte in separate Dateien auslagern und nicht mehr ungesichert im Quellcode der Webseite einbetten. Jegliche fremde Skripte, die in den Code eingeschleust wurden, werden dadurch zuverlässig vom Browser des Nutzers blockiert.
Das ultimative Ziel: Strict CSP
Ein Strict CSP sollte das ultimative Ziel bei der Implementierung einer CSP sein. Dieses erweiterte Sicherheitskonzept verwendet Nonces oder Hashes, um Cross-Site-Scripting (XSS) zu verhindern, im Gegensatz zu den häufig verwendeten hostbasierten Whitelist-CSPs. Diese können oft umgangen werden und die Webseite bleibt somit anfällig für XSS-Attacken.
Wenn eine Anwendung ein Strict CSP verwendet, haben Angreifer, die HTML-Injection-Schwachstellen finden, in der Regel nicht die Möglichkeit, den Browser dazu zu zwingen, schädliche Skripte im Kontext des verwundbaren Dokuments auszuführen.
Dies liegt daran, dass ein Strict CSP nur gehashte Skripte oder Skripte mit dem korrekten, serverseitig generierten Nonce-Wert zulässt. Um eine Webseite mit Strict CSP abzusichern, muss der HTML-Code überarbeitet werden, um Muster zu entfernen, die nicht mit der CSP kompatibel sind.
Gleichgewicht zwischen Sicherheit und Funktionalität
Eine Content Security Policy (CSP) kann etwas knifflig sein, um sie korrekt zu implementieren, insbesondere auf einer komplexen Website, die Ressourcen aus verschiedenen Quellen verwendet. Der Schlüssel liegt darin, ein Gleichgewicht zwischen Sicherheit und Funktionalität zu finden.
Für die bestmögliche Sicherheit jeder Online-Anwendung empfehlen wir dringend, eine Webseite von Grund auf neu zu gestalten und effizient ein Strict CSP zu planen und umzusetzen.
Ein einfaches, nicht-Strictes CSP sollte nur für Webseiten verwendet werden, bei denen die Erstellung einer strengen Richtlinie nicht möglich ist. Es bietet jedoch zuverlässigen Schutz vor Cross-Site-Framing und Cross-Site-Formularübermittlungen und reduziert Ihre Angriffsfläche erheblich.
Unsere Empfehlung:
Für die meisten Webseitenbetreiber ist es sinnvoller, zunächst eine Whitelist-CSP zu implementieren. Diese bietet bereits einen soliden Grundschutz und lässt sich bei Bedarf in der Zukunft zu einem Strict CSP weiterentwickeln. Das Warten auf die perfekte Lösung könnte riskant sein, wenn dies bedeutet, dass Sie keine Sicherheitsmaßnahmen ergreifen.
Unsere Anleitungen und kostenlos bereitgestellten Code-Beispiele konzentrieren sich auf Whitelist-CSP. Für individuelle Sicherheitsberatung und Implementierung stehen wir Ihnen gerne zur Verfügung. Nehmen Sie einfach Kontakt mit uns auf
CSP Header Beispiel mit einem meta Tag
Webseitenbetreiber, deren Serverebene keine Möglichkeit zur Implementierung von CSP zulässt, können den Content-Security-Policy-Header mit der Verwendung eines HTML <meta>-Elements in den HTML-Code leicht einfügen.
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
CSP Beispiel mit Server .htaccess
.htaccess-Datei Ihres Servers kopieren. Der Vorteil der Verwendung der .htaccess-Datei des Web-Servers besteht darin, dass sie für alle Anfragen gilt, nicht nur für Ihre PHP-Dateien.
Das folgende Header-Code-Beispiel ist das, was wir auf unserer Website verwenden. Wenn Sie einige dieser Quellen nicht nutzen, sollten Sie sie entfernen oder durch Ihre eigenen erforderlichen Werte ersetzen. Wir bieten dies als Leitfaden an, damit Sie sich schnell in diesem manchmal eigenwilligen Thema zurechtfinden, ohne viel Zeit mit Trial and Error zu verlieren.
Bearbeiten Sie dazu Ihre .htaccess-Datei, die sich im Stammverzeichnis Ihrer Website befindet:
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src *; \
img-src 'self' data: https://s.w.org https://images.dmca.com https://www.webwiki.de https://t.paypal.com https://secure.gravatar.com; \
font-src 'self' data: https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com; \
connect-src 'self' https://t.clarity.ms https://wid.cert-bund.de https://www.paypal.com; \
style-src 'self'; \
style-src-elem 'self' 'unsafe-inline' https://cdn.jsdelivr.net https://fonts.googleapis.com; \
script-src 'self' 'unsafe-inline' 'unsafe-eval' https://cdn.jsdelivr.net https://ajax.googleapis.com https://images.dmca.com https://www.googletagmanager.com https://www.paypal.com; \
script-src-elem 'self' 'unsafe-inline' https://www.paypal.com https://cdn.jsdelivr.net https://www.google-analytics.com https://www.clarity.ms https://www.googletagmanager.com https://www.gstatic.com https://images.dmca.com; \
object-src 'none'; \
worker-src 'self' blob:; \
frame-src 'self' https://www.paypal.com; \
frame-ancestors 'self'; \
form-action 'self' https://www.paypal.com; \
base-uri 'self';"
Header set Cross-Origin-Resource-Policy: same-origin;
Header set Cross-Origin-Open-Policy: same-origin-allow-popups;
</IfModule>
CSP Header Beispiel mit Google Fonts
Sie müssen mindestens zwei CSP-Direktiven angeben, die style-src und die font-src Direktive.
Die style-src Direktive:
Google Fonts wird in der Regel über ein Link-Tag bereitgestellt, Sie könnten ein Stylesheet wie folgt laden:
<link href="https://fonts.googleapis.com/css?family=Roboto&display=swap" rel="stylesheet">
Damit die Content-Security-Policy diese CSS-Datei überhaupt laden kann, müssen Sie fonts.googleapis.com zu Ihrer style-src-Direktive hinzufügen.
Diese Richtlinie könnte so aussehen: style-src fonts.googleapis.com
Die font-src Direktive:
Als Nächstes müssen wir eine font-src-Direktive verwenden, um die tatsächliche Font-Face-Quelldatei zuzulassen. Im Fall von Google Fonts werden diese Schriftdateien von fonts.gstatic.com bereitgestellt. Das bedeutet, wir benötigen folgendes in unserer Content-Security-Policy: font-src fonts.gstatic.com
Zusammensetzung des Google Fonts CSP:
Ein vollständiger Content-Security-Policy-Header für Google Fonts könnte so aussehen:
Content-Security-Policy: default-src 'self'; font-src fonts.gstatic.com; style-src 'self' fonts.googleapis.com
CSP Header Beispiel mit Google Maps
script-src und die img-src Direktive.Die script-src Direktive:
Damit das Google Maps JavaScript geladen wird, müssen wir die Domain maps.googleapis.com in unserer Richtlinie zulassen: script-src maps.googleapis.com
Die img-src Direktive:
Sie werden feststellen, dass die geladenen Bilder je nach Art der verwendeten Google-Karte variieren können:
maps.gstatic.com– lädt verschiedene Bildressourcen für die Karte wie Fadenkreuz-Cursor, einen einfachen Marker, das Google-Logo usw.maps.googleapis.com– lädt Kacheln der Karte.data:image/svg+xml– verschiedene Ressourcen werden als SVG über Daten-URIs geladen.khms0.googleapis.com– lädt Satellitenbilder für die Karte. Wir werden*.googleapis.comin unserer Richtlinie verwenden, um alle ähnlichen Domains zuzulassen.geo0.ggpht.com– lädt Street-View-Bilder, dies könnte von einigen verschiedenen ähnlichen Subdomains kommen, daher verwenden wir*.ggpht.comin unserer Content-Security-Policy
Um die Bilder von Google Maps zu laden, müssen wir diese Domains in unserer Richtlinie zulassen: img-src data: maps.gstatic.com *.googleapis.com *.ggpht.com
Zusammensetzung des Google Maps CSP:
Ein minimaler Content-Security-Policy-Header, der mit Google Maps funktioniert, könnte so aussehen:
Content-Security-Policy: script-src maps.googleapis.com; img-src data: maps.gstatic.com *.googleapis.com *.ggpht.com
CSP Beispiel mit WordPress functions.php
Für Webseitenbetreiber mit der weitverbreiteten CMS WordPress ist das Einsetzen des Content-Security-Policy-Headers in der Regel eine einfache Möglichkeit zur Implementierung von CSP. Die functions.php-Datei können Sie mühelos direkt im WordPress-Administrations-Bereich konfigurieren und den Header-Code hinzufügen.
1. Öffnen Sie die functions.php-Datei Ihres aktiven Themes.
2. Fügen Sie den folgenden PHP-Code hinzu:
Here’s an example of a Content-Security-Policy header:
In this example CSP policy you find two CSP directives: default-src and img-src.
header("Content-Security-Policy:
default-src * 'self';
img-src 'self' data: maps.gstatic.com *.googleapis.com *.ggpht.com https://secure.gravatar.com;
font-src 'self' data: fonts.gstatic.com https://maxcdn.bootstrapcdn.com;
style-src 'self' 'unsafe-inline' fonts.googleapis.com;
connect-src 'self';
script-src 'self' 'unsafe-inline' https://www.googletagmanager.com www.google-analytics.com ajax.googleapis.com;
object-src 'none';
worker-src 'self' blob:;
frame-src 'self' https://www.google.com;
frame-ancestors 'self';
form-action 'self';
");Die default-src Direktive:
The default-src directive restricts what URLs resources can be fetched from the document that set the Content-Security-Policy header. This includes images (img-src), css files (script-src), js files (script-src), etc.
We have set the default-src directive to `self` which means the same origin, or same domain and scheme.
Die img-src Direktive:
By adding the img-src directive to our policy we can override the default-src directive and provide a policy specific to loading images. In this case we are allowing images to be loaded from 'self' and the domain cdn.example.com.
Die script-src Direktive:
By adding the script-src directive to our policy we can override the default-src directive. Damit z.B. Google Analytics geladen wird, müssen wir die Domain www.google-analytics.com ajax.googleapis.com in unserer Richtlinie zulassen:
Allow Google Analytics, Google AJAX CDN:
Allow YouTube:
Die frame-src Direktive:
By adding the frame-src directive to our policy we can override the default-src directive. Damit wir YouTube Videos laden können, müssen wir die Domain https://www.youtube-nocookie.com in unserer Richtlinie zulassen:
Content-Security-Policy: script-src 'self' www.google-analytics.com ajax.googleapis.com;
- 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 fallen sie auf default-src zurück.
Quellen lassen sich als Adressen, in ihrer Art oder auch als Wildcards eingeben. Folgende Eingaben sind zulässig:
- script-src https://example.com:443 – Skripte sind nur von dieser Domain per HTTPS zulässig.
- script-src ’none‘ – Skripte dürfen nicht geladen werden.
- script-src ’self‘ – Skripte dürfen aus demselben Ursprung wie die aktuelle Seite geladen werden, nicht aber von Subdomains.
- script-src https: – Skripte dürfen von jeglicher Domain geladen werden, solange sie mit HTTPS beginnt.
- script-src example.com – Skripte dürfen von dieser Domain geladen werden.
- script-src *.example.com – Skripte von dieser Domain und von allen Subdomains sind zulässig.
- img-src data: – Bilder dürfen über Data-URLs geladen werden.
1. Lockerere Richtlinie:
Sie können mit einer lockeren Richtlinie beginnen und sie nach und nach verschärfen, während Sie deren Auswirkungen auf Ihre Website verstehen. Zum Beispiel:
header("Content-Security-Policy: default-src * 'unsafe-inline' 'unsafe-eval';");
Diese Richtlinie erlaubt Inhalte aus jeder Quelle, einschließlich Inline-Skripten und Inline-Styles, ist jedoch nicht besonders sicher. Die Idee ist, nach und nach Berechtigungen zu entfernen und jedes Mal zu testen, ob die Website immer noch funktioniert.
2. Nur-Melden-Modus (Report-Only):
Um herauszufinden, welche Ressourcen das Problem verursachen, ohne Ihre Website zu beeinträchtigen, können Sie CSP im „Nur-Melden“-Modus verwenden. Dies protokolliert Verstöße, ohne tatsächlich etwas zu blockieren:
header("Content-Security-Policy-Report-Only: default-src 'self'; script-src https://domain.com");
3. Feinsteuerung:
Wenn Sie feststellen, dass nur bestimmte Arten von Inhalten problematisch sind, können Sie verschiedene Richtlinien für verschiedene Arten von Ressourcen (Skript, Bild, Schriftart usw.) festlegen.
header("Content-Security-Policy: default-src 'self'; script-src 'self' https://domain.com https://another-script-source.com; img-src 'self' https://img-source.com");
4. Inline-Nonce:
Wenn Sie inline <script> oder <style>
-Tags haben, die blockiert werden, können Sie einen einmaligen Wert nonce (number only used once) ’nonce-rAnd0m‘ generieren und sowohl in den CSP-Header als auch in das Inline-Skript/-Style-Element einfügen, um diese zu erlauben.
header("Content-Security-Policy: default-src 'self'; script-src 'self' https:$nonce = base64_encode(random_bytes(16));
function add_csp_header() {
global $nonce;
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-$nonce'");
}
add_action('send_headers', 'add_csp_header');
Wenn keine der Einstellungen es Ihnen ermöglicht, die gewünschte CSP hinzuzufügen, können Sie sich gerne an uns wenden. Wir stehen Ihnen mit Rat und Tat zur Seite.
Rundum-Absicherung
Inhaltsicherheitsrichtlinie (CSP)
XSS-Absicherung
100% Geld-zurück-Garantie
Keine monatlichen Kosten
Wir schützen, was Ihnen wichtig ist.
Schlüsselfertige Absicherung:
Unsere Experten erledigen diese Aufgabe komplett für Sie.
Statt 245,- € jetzt zum Vorzugspreis von nur 195,- €