Content Security Policy in Next.js – praktische Schritt-für-Schritt-Anleitung

Content Security Policy (CSP) ist ein Browser‑Mechanismus, der es Anwendungsentwicklern ermöglicht, zu definieren, welche Ressourcen im Kontext einer Seite geladen und ausgeführt werden dürfen. Durch CSP kann das Risiko von Cross‑Site‑Scripting‑Angriffen (XSS) und anderen unerwünschten Verhaltensweisen, wie dem Einschleusen nicht autorisierten JavaScript‑Codes, erheblich reduziert werden. In Umgebungen, die auf Next.js und React basieren, wo Komponenten dynamisch gerendert werden, erfordert die Implementierung von CSP eine durchdachte Konfiguration, um die Funktionalität der Anwendung nicht zu beeinträchtigen.

Bedrohungsmodell – warum CSP in React/Next.js‑Anwendungen nötig ist

Moderne Front‑End‑Anwendungen laden häufig Skripte aus vielen Quellen: CDN, eigenem Server und zudem dynamisch generierte Inline‑Skripte (z. B. in HTML‑Templates eingebettet). Angreifer können Schwachstellen in der Eingabesanitisierung ausnutzen, um eigenen JavaScript‑Code einzuschleusen, was zum Diebstahl von Tokens, Sitzungen oder zur Ausführung nicht autorisierter Aktionen führt. CSP wirkt als Abwehrschicht, indem es nicht autorisierte Quellen blockiert und die Verwendung sicherer Lade‑Methoden erzwingt.

Wie CSP funktioniert – grundlegende Direktiven und ihre Bedeutung

Die CSP‑Richtlinie wird im HTTP‑Header Content‑Security‑Policy oder im <meta>-Tag definiert. Die wichtigsten Direktiven sind:

• default-src – Standardquelle für alle Ressourcentypen, wenn keine andere Direktive angegeben ist.
• script-src – steuert, von wo JavaScript‑Skripte geladen werden dürfen.
• style-src – definiert erlaubte Quellen für CSS‑Stylesheets.
• img-src – regelt die Herkunft von Bildern.
• connect-src – legt fest, zu welchen Adressen die Anwendung Verbindungen herstellen darf (z. B. API, WebSocket).

In der Praxis ist script-src am wichtigsten, da sie direkt vor XSS schützt. Es wird empfohlen, Hashes ('sha256-…') oder Nonces ('nonce‑…') für Inline‑Skripte zu verwenden, anstatt sich auf 'unsafe-inline' zu verlassen, das den Schutz deaktiviert.

Beispiel‑CSP‑Richtlinie für Next.js

Unten steht eine minimale, aber wirksame CSP‑Richtlinie, die in der Datei next.config.js mittels Middleware oder in der Funktion getServerSideProps hinzugefügt werden kann:

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: "default-src 'self'; script-src 'self' 'sha256-abc123' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.example.com; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'"
          }
        ]
      }
    ];
  }
};

Diese Richtlinie erlaubt nur Skripte vom eigenen Host und einem vertrauenswürdigen CDN, und Inline‑Skripte müssen mit einem Hash gesichert werden. Für Styles wurde 'unsafe-inline' nur in Ausnahmefällen zugelassen, was ein Kompromiss bei der Nutzung von CSS‑in‑JS‑Bibliotheken ist.

Code‑Beispiele: unsicher vs. sicher

Betrachten wir eine einfache React‑Komponente, die Inhalte von einer API ohne Sanitisierung einfügt:

function UnsafeComponent({html}) {
  return ;
}

Dieses Vorgehen ist anfällig für XSS, da beliebiger HTML‑Code ausgeführt werden kann. Die sichere Version nutzt eine Sanitizer‑Bibliothek und beschränkt CSP gleichzeitig auf vertrauenswürdige Quellen:

import DOMPurify from 'dompurify';

function SafeComponent({html}) {
  const cleanHtml = DOMPurify.sanitize(html);
  return ;
}

Die Kombination aus Anwendungssanitisierung und einer restriktiven CSP‑Richtlinie erhöht die Sicherheit erheblich.

„CSP ist kein magischer Schild – es ist ein Baustein der Verteidigungsschicht, der mit sicherem Code zusammenarbeiten muss.“

Checkliste zur CSP‑Implementierung in Next.js und React

• Identifizieren Sie alle Quellen für Skripte, Styles, Bilder und Verbindungen, die im Projekt verwendet werden.
• Bestimmen Sie, welche Inline‑Skripte unverzichtbar sind; ersetzen Sie sie durch Hashes oder Nonces.
• Konfigurieren Sie den CSP‑Header in next.config.js oder im vorgelagerten Server (NGINX, Vercel).
• Aktivieren Sie das CSP‑Reporting (Direktive report-uri oder report-to) und überwachen Sie die Logs.
• Testen Sie die Richtlinie im Reporting‑Modus (Content-Security-Policy-Report-Only), bevor Sie sie im Blockierungsmodus aktivieren.
• Verwenden Sie die Entwickler‑Tools des Browsers, um CSP‑Verstöße zu analysieren und die Richtlinie anzupassen.

Typische Fehler und Kompromisse bei der CSP‑Implementierung

Die häufigsten Stolperfallen sind:

• Verwendung von 'unsafe-inline' oder 'unsafe-eval' – schaltet den XSS‑Schutz vollständig aus.
• Veraltete Hashes – nach einer Code‑Änderung muss der Hash aktualisiert werden, sonst blockiert die Richtlinie legitimen Code.
• Zu restriktives default-src ohne passende Anpassung der Unter‑Direktiven – kann dazu führen, dass die Anwendung notwendige Ressourcen wie Schriftarten oder Bilder nicht mehr lädt.
• Fehlendes Reporting – ohne aktiviertes Reporting ist es schwierig zu erkennen, welche Ressourcen blockiert werden und warum.

Die Lösung ist ein iterativer Ansatz: Zuerst die Richtlinie im Report‑Only-Modus aktivieren, Daten sammeln und anschließend in den Blockier‑Modus wechseln, nachdem alle Fehlalarme eliminiert wurden.

Debugging von CSP‑Verstößen im Browser und Reporting

In der Entwicklerkonsole von Chrome und Firefox erscheinen Meldungen wie Refused to load the script … because it violates the following Content Security Policy directive: "script-src …". Ein Klick auf die Meldung öffnet eine Vorschau, welche Quelle blockiert wurde. Zusätzlich erhält der Server, wenn report-uri konfiguriert ist, ein JSON mit den Verstoß‑Informationen, was eine automatische Analyse und Aktualisierung der Richtlinie ermöglicht.

Wartung und Aktualisierung der CSP‑Richtlinie

Eine CSP‑Richtlinie ist keine einmalige Einstellung – sie erfordert regelmäßige Überprüfungen. Jede neue Bibliothek, jedes CDN oder jede Funktion (z. B. WebSocket) kann das Hinzufügen entsprechender Quellen zu den Direktiven nötig machen. Eine bewährte Praxis ist die Integration von e2e‑Tests, die prüfen, ob die Anwendung mit aktivierter CSP funktioniert, sowie das Monitoring von Reports in einem SIEM‑System oder an einem dedizierten Endpunkt.

Zusammenfassend ist die Implementierung von Content Security Policy in Next.js‑ und React‑Projekten ein Prozess, der eine genaue Inventarisierung der Ressourcen, die korrekte Konfiguration der Header und kontinuierliches Monitoring kombiniert. Dadurch kann das Engineering‑Team das XSS‑Risiko erheblich reduzieren und gleichzeitig die volle Funktionalität der Anwendung erhalten. Wenn Sie Unterstützung bei einer Sicherheits‑Audit, CSP‑Konfiguration oder Reporting‑Integration benötigen, kontaktieren Sie uns bei Coderia.it – gemeinsam bauen wir ein robustes Schutzschild für Ihren Code.