Content Security Policy in nginx: CSP richtig setzen – mit PairDrop und SkySend

Was CSP leistet – und was nicht

Eine Content Security Policy ist eine Erlaubnisliste, die der Server mit jeder Antwort verschickt. Sie legt fest, von welchen Quellen der Browser Skripte, Stile, Bilder, Schriften und Verbindungen akzeptiert. Der Nutzen entsteht nicht dadurch, dass deine Seite unsicher wäre – sondern dadurch, dass eine Einschleusung dann nicht mehr ausgenutzt werden kann.

Header ja, Meta nur eingeschränkt

Man kann eine Policy auch per <meta http-equiv="Content-Security-Policy"> in die Seite schreiben. Das ist bei statischen Seiten populär, weil man keine Serverkonfiguration braucht – aber es fehlen die wichtigen Teile:

Deshalb gehört CSP in nginx. Zwei Regeln vorab, die man sonst schmerzhaft lernt:

• Die Policy gilt pro Antwort, nicht pro Domain. Verschiedene Apps auf derselben Domain brauchen unterschiedliche Policies – das ist eine Architekturfrage, kein Konfigurationsdetail.
• Genau ein CSP-Header pro Antwort. Bei zwei Headern setzt der Browser beide durch, also die strengere – und du suchst eine Weile, warum die „neue“ Policy die Seite zerschießt.

Die Direktiven in der Praxis

Eine Policy ist eine Folge von direktive quelle quelle, getrennt durch Semikolon. default-src ist der Auffangwert für alles, was nicht einzeln genannt wird. In der Praxis sind es diese hier:

Die drei, die nie etwas kaputtmachen

Wenn du Zeit für nichts anderes hast, setze diese drei – sie kosten keine Funktion und schließen drei Angriffsklassen:

add_header Content-Security-Policy "object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;

'unsafe-inline', Hashes, Nonces, strict-dynamic

Der häufigste Grund, warum eine Policy „nicht geht“, sind Inline-Skripte und Inline-Stile. Ohne Erlaubnis blockiert der Browser jeden <script>-Block und jedes style="…"-Attribut. Drei Wege führen daraus – mit sehr unterschiedlichem Aufwand:

Für selbst gehostete Fremd-Apps (also der Normalfall bei PairDrop und SkySend) läuft es praktisch auf 'unsafe-inline' für Stile hinaus, während Skripte meist strikt bleiben können. Das ist ein bewusster Kompromiss: Stil-Injection ist deutlich harmloser als Skript-Injection.

Der sichere Weg: erst Report-Only

Der einzige Weg, eine CSP einzuführen, ohne Besucher auszusperren: erst beobachten, dann durchsetzen. Dafür gibt es denselben Header mit angehängtem -Report-Only – er blockiert nichts, sondern meldet nur.

# Schritt 1: beobachten (blockiert nichts)
add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data: blob:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;

# Schritt 2: nach der Auswertung scharf schalten
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: blob:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;

Der wichtigste Trick kostet nichts: die Konsole des Browsers ist dein Report-Endpunkt. Bei jedem Verstoß erscheint dort eine Meldung mit der verletzten Direktive und der blockierten Adresse. Öffne die Seite, klicke dich durch die Funktionen – hochladen, teilen, Vorschau, PWA installieren – und lies die Ausgabe. Nach zehn Minuten weißt du mehr über die App als jede Dokumentation verrät.

Reports sammeln ohne Drittanbieter

Wenn du Reports zentral auswerten willst, kannst du das selbst bauen. Zwei Wege:

# Variante A: Browser senden an den eigenen Endpunkt
add_header Content-Security-Policy-Report-Only "…; report-uri /csp-report" always;

# Variante B (moderner, ersetzt report-uri): Reporting-API
add_header Report-To '{"group":"csp","max_age":86400,"endpoints":[{"url":"https://pd.huuu.biz/csp-report"}]}' always;
# und in der Policy: report-to csp

Für den Endpunkt habe ich eine naheliegende Idee getestet, die nicht funktioniert: Eine reine nginx-Lösung mit return 204; und $request_body im Log. Das Ergebnis: HTTP 204 kommt an, das Log enthält aber nur einen Bindestrich – nginx liest den Body bei einem return nicht, also ist $request_body leer. Wenn du die Reports wirklich speichern willst, brauchst du ein Backend davor:

location = /csp-report {
    proxy_pass http://127.0.0.1:8787;    # kleiner Sammler, siehe Skript unten
    client_max_body_size 32k;            # Reports sind klein – Bremse gegen Missbrauch
    access_log off;
}

Der Sammler ist ein Dutzend Zeilen: Body lesen, als JSON-Zeile anhängen, mit 204 antworten. Genau in dieser Form läuft er im Test – der Browser bekommt sein 204, in der Logdatei steht der vollständige Report:

#!/usr/bin/env node
// csp-collector.mjs  -  sammelt CSP-Reports in eine JSONL-Datei
import http from "node:http";
import fs from "node:fs";

const PORT = Number(process.env.PORT || 8787);
const LOG  = process.env.LOG || "/var/log/csp-reports.jsonl";

http.createServer((req, res) => {
  if (req.method !== "POST" || !req.url.startsWith("/csp-report")) {
    res.writeHead(404); return res.end();
  }
  let body = "";
  req.on("data", (c) => { body += c; if (body.length > 64 * 1024) req.destroy(); });
  req.on("end", () => {
    fs.appendFileSync(LOG, JSON.stringify({ zeit: new Date().toISOString(), ip: req.socket.remoteAddress, rohdaten: body.slice(0, 8000) }) + "\n");
    res.writeHead(204); res.end();          // 204 genuegt dem Browser
  });
}).listen(PORT, "127.0.0.1", () => console.log("Collector auf 127.0.0.1:" + PORT));

Mit socat, einem systemd-Unit und einer Logrotation läuft das dauerhaft. Wer es „richtig“ will, nimmt einen selbst gehosteten Fehlersammler (etwa GlitchTip oder Sentry) und zeigt dorthin – dann hast du Gruppierung und Auswertung, aber wieder einen Dienst mehr zu warten.

Praxis 1: PairDrop absichern

PairDrop ist eine WebRTC-Anwendung: Zwei Geräte finden sich über einen Vermittlungsserver und übertragen Daten anschließend direkt miteinander. Für die Policy heißt das:

Daraus entsteht die Policy für pd.huuu.biz beziehungsweise deine eigene Instanz:

# Einmalig im http-Kontext definieren (z. B. conf.d/websocket-upgrade.conf):
map $http_upgrade $connection_upgrade { default upgrade; '' close; }

server {
    listen 443 ssl;
    http2 on;
    server_name pd.meine.domain;

    ssl_certificate     /etc/ssl/private/pd.meine.domain_ecc/fullchain.cer;
    ssl_certificate_key /etc/ssl/private/pd.meine.domain_ecc/pd.meine.domain.key;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; media-src 'self' blob:; font-src 'self'; connect-src 'self'; worker-src 'self' blob:; manifest-src 'self'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests" always;

    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;      # WebSocket-Signalisierung
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://127.0.0.1:50513;
    }
}

Praxis 2: SkySend absichern

SkySend ist der zweite gute Testfall, weil es anders funktioniert: Die Dateien werden im Browser verschlüsselt, der Schlüssel steckt im URL-Fragment, und die Uploads laufen laut Konfiguration über FILE_UPLOAD_WS per WebSocket. Genau diese Punkte muss die Policy abbilden.

Die fertige Policy für sky.huuu.biz beziehungsweise deine Instanz:

    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; media-src 'self' blob:; font-src 'self'; connect-src 'self'; worker-src 'self' blob:; manifest-src 'self'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests" always;

nginx-Fallen beim Setzen der Header

# /etc/nginx/snippets/security-headers.conf  -  gemeinsame Basis
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# /etc/nginx/snippets/csp-pairdrop.conf      -  app-spezifisch
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; …" always;

# im Serverblock
include snippets/security-headers.conf;
include snippets/csp-pairdrop.conf;

Mehrere Dienste, eine Domain

Sobald zwei Apps dieselbe Domain teilen, brauchst du die CSP pro location – und läufst in die Vererbungsregel. Sauber geht es so:

Testen, ohne Besucher zu verlieren

# 1) Ist der Header ueberhaupt gesetzt?
curl -sI https://pd.huuu.biz/ | grep -i 'content-security'

# 2) Scharf oder nur im Testmodus?
curl -sI https://pd.huuu.biz/ | grep -io 'content-security-policy\(-report-only\)\?'

# 3) Konfiguration vor dem Reload pruefen
sudo nginx -t && sudo systemctl reload nginx

Wenn es schiefgeht

Häufige Fragen (FAQ)

Fazit

CSP ist der Header mit der größten Wirkung und dem größten Selbsterschütterungspotenzial – je nachdem, in welcher Reihenfolge man ihn einführt. Mit Report-Only, der Konsole als Report-Endpunkt und einer Policy, die pro Anwendung gebaut wird, ist es dagegen ein ruhiger Vorgang: beobachten, ergänzen, scharf schalten.

PairDrop und SkySend zeigen dabei die zwei Muster, die dir bei jedem selbst gehosteten Dienst begegnen: eine App mit WebRTC, bei der die Peer-Verbindungen außerhalb der CSP liegen, und eine App mit WebSocket-Uploads, bei der ein fehlender connect-src-Eintrag erst beim echten Transfer auffällt.