{"id":205,"date":"2026-06-18T16:21:17","date_gmt":"2026-06-18T16:21:17","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/18\/content-security-policy-nodejs\/"},"modified":"2026-06-18T16:21:17","modified_gmt":"2026-06-18T16:21:17","slug":"content-security-policy-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/18\/content-security-policy-nodejs\/","title":{"rendered":"Content Security Policy in Node.js: 12 Schritte [2026]"},"content":{"rendered":"\n

Cross-Site-Scripting (XSS) steht seit Jahren auf der OWASP-Top-10-Liste der gef\u00e4hrlichsten Webanwendungsangriffe. Bei einem XSS-Angriff injiziert ein Angreifer schadhaften JavaScript-Code in deine Webseite, der im Browser des Opfers ausgef\u00fchrt wird, um Sitzungs-Tokens zu stehlen oder Aktionen im Namen des Nutzers durchzuf\u00fchren. Der Content Security Policy<\/strong>-Header (CSP) ist die wirksamste Browser-seitige Gegenwehr: Er teilt dem Browser exakt mit, welche Ressourcen geladen werden d\u00fcrfen, und blockiert alles andere. Dieses Tutorial zeigt, wie du CSP in 12 Schritten in einer Node.js\/Express-Anwendung implementierst, von der ersten Direktive bis zur produktionsreifen Konfiguration mit Nonces, Hashes, strict-dynamic und Violation Reporting.<\/p>\n\n\n\n

Was ist Content Security Policy und warum brauchst du sie?<\/h2>\n\n\n\n

Der Content-Security-Policy<\/code>-Header ist eine HTTP-Response-Header-Richtlinie, die dem Browser mitteilt, welche Quellen er f\u00fcr Skripte, Stylesheets, Bilder, Fonts und andere Ressourcen als vertrauensw\u00fcrdig akzeptieren soll. Alles, was nicht explizit erlaubt ist, wird blockiert und ein Violation-Report kann an einen konfigurierten Endpunkt gesendet werden.<\/p>\n\n\n\n

Ohne CSP kann ein Angreifer, der es schafft, schadhaften HTML-Code in deine Seite einzuschleusen (z. B. durch eine unzureichend escapte Nutzereingabe), beliebigen JavaScript-Code ausf\u00fchren. Mit einer sorgf\u00e4ltig konfigurierten CSP ist dieser Angriff in der Regel nicht mehr m\u00f6glich, weil der Browser den injizierten Code verweigert.<\/p>\n\n\n\n

CSP Level 2<\/strong> ist der produktive Baseline, den alle modernen Browser vollst\u00e4ndig unterst\u00fctzen. CSP Level 3<\/strong> (aktuelle W3C-Spezifikation) bringt Erweiterungen wie 'strict-dynamic'<\/code> und require-trusted-types-for<\/code>, die in Chromium-Browsern bereits implementiert sind. F\u00fcr eine DACH-Nutzerbasis, bei der mehr als 65 % Chrome oder Edge nutzen, sind Level-3-Features 2026 produktionsreif.<\/p>\n\n\n\n

Wichtig: CSP ist kein Ersatz f\u00fcr korrektes Input-Escaping oder Parameterized Queries. Es ist eine zus\u00e4tzliche Verteidigungsschicht, die Angriffe blockiert, die trotz anderer Ma\u00dfnahmen durchkommen.<\/p>\n\n\n\n

Voraussetzungen<\/h2>\n\n\n\n

F\u00fcr dieses Tutorial ben\u00f6tigst du folgende Softwareversionen:<\/p>\n\n\n\n

Software<\/th>Mindestversion<\/th>Empfohlene Version<\/th>Zweck<\/th><\/tr><\/thead>
Node.js<\/td>18.x LTS<\/td>20.20.2 LTS<\/td>JavaScript-Laufzeitumgebung<\/td><\/tr>
npm<\/td>9.x<\/td>10.x<\/td>Paketverwaltung<\/td><\/tr>
Express<\/td>4.x<\/td>5.2.1<\/td>Web-Framework<\/td><\/tr>
helmet<\/td>7.x<\/td>8.2.0<\/td>HTTP-Security-Header-Middleware<\/td><\/tr>
curl oder Browser DevTools<\/td>beliebig<\/td>aktuelle Version<\/td>CSP-Header testen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Au\u00dferdem brauchst du Grundkenntnisse in Node.js und Express sowie ein Terminal (Linux\/macOS) oder die PowerShell\/Git Bash unter Windows. Das fertige Projekt findest du am Ende dieses Tutorials als vollst\u00e4ndig lauff\u00e4higen Code.<\/p>\n\n\n\n

Schritt 1: Projektstruktur anlegen<\/h2>\n\n\n\n

Lege ein frisches Verzeichnis an und initialisiere ein npm-Projekt:<\/p>\n\n\n\n

mkdir csp-demo && cd csp-demo\nnpm init -y\nnpm install express@5 helmet@8<\/code><\/pre>\n\n\n\n
Die Verzeichnisstruktur nach diesem Schritt:<\/p>\n\n\n\n
csp-demo\/\n\u251c\u2500\u2500 node_modules\/\n\u251c\u2500\u2500 package.json\n\u2514\u2500\u2500 server.js        (noch zu erstellen)<\/code><\/pre>\n\n\n\n
Lege die Hauptdatei server.js<\/code> an:<\/p>\n\n\n\n
const express = require('express');\nconst app = express();\nconst PORT = 3000;\n\napp.get('\/', (req, res) => {\n  res.send(`\n    <!DOCTYPE html>\n    <html lang=\"de\">\n      <head><title>CSP Demo<\/title><\/head>\n      <body>\n        <h1>CSP Demo<\/h1>\n        <script>console.log('inline script');<\/script>\n      <\/body>\n    <\/html>\n  `);\n});\n\napp.listen(PORT, () => console.log(`Server l\u00e4uft auf Port ${PORT}`));<\/code><\/pre>\n\n\n\n
Starte den Server mit node server.js<\/code> und rufe http:\/\/localhost:3000<\/code> auf. Im Browser-Netzwerktab siehst du noch keinen CSP-Header. Das \u00e4ndern wir in den n\u00e4chsten Schritten.<\/p>\n\n\n\n
Schritt 2: Ersten CSP-Header manuell setzen<\/h2>\n\n\n\n
Bevor wir Helmet.js einsetzen, ist es wichtig zu verstehen, wie ein CSP-Header manuell gesetzt wird. Das gibt dir die volle Kontrolle und hilft beim Debuggen sp\u00e4terer Probleme.<\/p>\n\n\n\n
const express = require('express');\nconst app = express();\nconst PORT = 3000;\n\n\/\/ Manuelle CSP-Middleware\napp.use((req, res, next) => {\n  res.setHeader(\n    'Content-Security-Policy',\n    [\n      \"default-src 'self'\",\n      \"script-src 'self'\",\n      \"style-src 'self'\",\n      \"img-src 'self' data:\",\n      \"connect-src 'self'\",\n      \"font-src 'self'\",\n      \"object-src 'none'\",\n      \"base-uri 'self'\",\n      \"frame-ancestors 'none'\",\n      \"form-action 'self'\"\n    ].join('; ')\n  );\n  next();\n});\n\napp.get('\/', (req, res) => {\n  res.send(`\n    <!DOCTYPE html>\n    <html lang=\"de\">\n      <head><title>CSP Demo<\/title><\/head>\n      <body>\n        <h1>CSP aktiv<\/h1>\n        <!-- Dieser inline-Script wird von CSP blockiert -->\n        <script>console.log('dieser Code wird blockiert');<\/script>\n      <\/body>\n    <\/html>\n  `);\n});\n\napp.listen(PORT, () => console.log(`Server l\u00e4uft auf Port ${PORT}`));<\/code><\/pre>\n\n\n\n
Nach dem Neustart des Servers \u00f6ffne die Browser-Konsole. Du siehst jetzt eine CSP-Fehlermeldung:<\/p>\n\n\n\n
Refused to execute inline script because it violates the following Content Security Policy directive:\n\"script-src 'self'\". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.<\/code><\/pre>\n\n\n\n
Das ist genau das gew\u00fcnschte Verhalten. Der Browser verweigert den inline-Script, weil unsere Policy nur Skripte von 'self'<\/code> (der gleichen Origin) erlaubt. Eine L\u00f6sung ist, externe Skript-Dateien statt inline-Code zu verwenden oder Nonces\/Hashes einzusetzen, was wir in Schritten 7 und 8 zeigen.<\/p>\n\n\n\n
Schritt 3: Helmet.js CSP-Middleware konfigurieren<\/h2>\n\n\n\n
Helmet.js ist eine Express-Middleware-Sammlung, die zahlreiche HTTP-Security-Header auf einmal setzt. Die aktuelle Version 8.2.0 verwendet f\u00fcr CSP die Methode helmet.contentSecurityPolicy()<\/code>. Die offizielle Helmet-Dokumentation<\/a> empfiehlt, Helmet fr\u00fch in der Middleware-Kette zu platzieren:<\/p>\n\n\n\n
const express = require('express');\nconst helmet = require('helmet');\nconst app = express();\nconst PORT = 3000;\n\napp.use(\n  helmet.contentSecurityPolicy({\n    directives: {\n      defaultSrc: [\"'self'\"],\n      scriptSrc: [\"'self'\"],\n      styleSrc: [\"'self'\", \"'unsafe-inline'\"],\n      imgSrc: [\"'self'\", \"data:\"],\n      connectSrc: [\"'self'\"],\n      fontSrc: [\"'self'\"],\n      objectSrc: [\"'none'\"],\n      mediaSrc: [\"'self'\"],\n      frameSrc: [\"'none'\"],\n      baseUri: [\"'self'\"],\n      frameAncestors: [\"'none'\"],\n      formAction: [\"'self'\"]\n    }\n  })\n);\n\napp.get('\/', (req, res) => {\n  res.send('<h1>Gesichert mit Helmet CSP<\/h1>');\n});\n\napp.listen(PORT, () => console.log(`Port ${PORT}`));<\/code><\/pre>\n\n\n\n
Hinweis: In diesem Beispiel ist 'unsafe-inline'<\/code> f\u00fcr styleSrc<\/code> gesetzt. Das ist f\u00fcr viele Projekte ein pragmatischer Einstieg, da inline-Styles sehr h\u00e4ufig in Bibliotheken vorkommen. F\u00fcr maximale Sicherheit solltest du auch hier auf Nonces oder Hashes umstellen. F\u00fcr scriptSrc<\/code> ist 'unsafe-inline'<\/code> hingegen ein kritisches Sicherheitsrisiko und sollte nie in der Produktion stehen.<\/p>\n\n\n\n
\u00dcberpr\u00fcfe den gesetzten Header mit curl:<\/p>\n\n\n\n
curl -I http:\/\/localhost:3000<\/code><\/pre>\n\n\n\n
Die Ausgabe sollte einen vollst\u00e4ndigen CSP-Header enthalten:<\/p>\n\n\n\n
content-security-policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'none'; media-src 'self'; frame-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self'<\/code><\/pre>\n\n\n\n
Schritt 4: CSP-Direktiven im \u00dcberblick<\/h2>\n\n\n\n
CSP kennt \u00fcber 20 Direktiven. Die folgende Tabelle zeigt die wichtigsten, ihren Zweck und den empfohlenen Wert f\u00fcr eine restriktive Produktionskonfiguration. Die vollst\u00e4ndige Referenz findest du auf MDN Web Docs<\/a> und auf content-security-policy.com<\/a>:<\/p>\n\n\n\n
Direktive<\/th>Kontrolliert<\/th>Empfohlener Produktionswert<\/th>Risiko bei Fehler<\/th><\/tr><\/thead>
default-src<\/code><\/td>Fallback f\u00fcr alle Ressourcentypen<\/td>'self'<\/code><\/td>Alle nicht explizit definierten Typen unkontrolliert<\/td><\/tr>
script-src<\/code><\/td>JavaScript-Quellen, inline-Scripts, eval()<\/td>'self' 'nonce-XYZ'<\/code><\/td>XSS \u00fcber injizierte Scripts m\u00f6glich<\/td><\/tr>
style-src<\/code><\/td>CSS-Quellen und inline-Styles<\/td>'self' 'nonce-XYZ'<\/code><\/td>CSS-Injection, Datenleck \u00fcber Attribute<\/td><\/tr>
img-src<\/code><\/td>Bildquellen inkl. data: URIs<\/td>'self' data: https:<\/code><\/td>Tracking-Pixel von Drittanbietern<\/td><\/tr>
connect-src<\/code><\/td>fetch(), XHR, WebSocket, EventSource<\/td>'self'<\/code><\/td>Datenleck an externe Server<\/td><\/tr>
font-src<\/code><\/td>Web-Fonts<\/td>'self'<\/code><\/td>Font-Fingerprinting<\/td><\/tr>
object-src<\/code><\/td>Flash, Plugins, <object><\/td>'none'<\/code><\/td>Plugin-basierte Exploits<\/td><\/tr>
frame-ancestors<\/code><\/td>Wer darf die Seite einbetten?<\/td>'none'<\/code> oder 'self'<\/code><\/td>Clickjacking-Angriffe<\/td><\/tr>
base-uri<\/code><\/td>Erlaubte <base>-Tag-Ziele<\/td>'self'<\/code><\/td>Base-Tag-Injection rewrite relative URLs<\/td><\/tr>
form-action<\/code><\/td>Wohin Formulare submitten d\u00fcrfen<\/td>'self'<\/code><\/td>Formular-Hijacking an externe URL<\/td><\/tr>
upgrade-insecure-requests<\/code><\/td>HTTP zu HTTPS upgraden<\/td>Immer setzen<\/td>Mixed-Content-Warnungen<\/td><\/tr>
report-uri<\/code> \/ report-to<\/code><\/td>Violation-Reporting-Endpunkt<\/td>Eigener Endpunkt<\/td>Keine Sichtbarkeit bei Verst\u00f6\u00dfen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Eine wichtige Regel: object-src 'none'<\/code> immer setzen. Flash und veraltete Browser-Plugins sind bekannte Angriffsfl\u00e4chen, die du vollst\u00e4ndig ausschlie\u00dfen solltest. Ebenso wichtig ist base-uri 'self'<\/code>: Ohne diese Direktive kann ein Angreifer ein <base href=\"https:\/\/evil.com\"><\/code>-Tag injizieren und damit alle relativen URLs auf seine Domain umleiten.<\/p>\n\n\n\n
Schritt 5 bis 6: Nonce-basierte CSP implementieren<\/h2>\n\n\n\n
Inline-Scripts und Inline-Styles sind im Webentwicklungsalltag unvermeidlich. Templates-Engines rendern oft dynamische Inhalte als <script><\/code>-Bl\u00f6cke direkt in der HTML-Antwort. Das naheliegendste L\u00f6sungskonzept, 'unsafe-inline'<\/code> zu erlauben, deaktiviert den XSS-Schutz komplett und ist f\u00fcr script-src<\/code> inakzeptabel.<\/p>\n\n\n\n
Die saubere L\u00f6sung ist ein Nonce<\/strong>: ein kryptografisch zuf\u00e4lliger Wert, der pro HTTP-Anfrage neu generiert wird und sowohl im CSP-Header als auch im nonce<\/code>-Attribut des <script><\/code>-Tags erscheint. Der Browser erlaubt nur Scripts, deren Nonce mit dem Header \u00fcbereinstimmt. Ein Angreifer kann den Nonce nicht kennen, da er bei jeder Anfrage neu erstellt wird.<\/p>\n\n\n\n
Die Implementierung in Express nutzt das crypto<\/code>-Modul aus der Node.js-Standardbibliothek:<\/p>\n\n\n\n
const express = require('express');\nconst helmet = require('helmet');\nconst crypto = require('crypto');\nconst app = express();\nconst PORT = 3000;\n\n\/\/ Nonce-Middleware: pro Request neu erzeugen\napp.use((req, res, next) => {\n  \/\/ 16 Bytes = 128 Bit Entropie, ausreichend f\u00fcr einen Nonce\n  res.locals.nonce = crypto.randomBytes(16).toString('base64');\n  next();\n});\n\n\/\/ Helmet mit dynamischem Nonce\napp.use((req, res, next) => {\n  helmet.contentSecurityPolicy({\n    directives: {\n      defaultSrc: [\"'self'\"],\n      scriptSrc: [\"'self'\", `'nonce-${res.locals.nonce}'`],\n      styleSrc: [\"'self'\", `'nonce-${res.locals.nonce}'`],\n      imgSrc: [\"'self'\", \"data:\"],\n      connectSrc: [\"'self'\"],\n      objectSrc: [\"'none'\"],\n      baseUri: [\"'self'\"],\n      frameAncestors: [\"'none'\"],\n      formAction: [\"'self'\"],\n      upgradeInsecureRequests: []\n    }\n  })(req, res, next);\n});\n\napp.get('\/', (req, res) => {\n  const nonce = res.locals.nonce;\n  res.send(`\n    <!DOCTYPE html>\n    <html lang=\"de\">\n    <head>\n      <title>CSP Nonce Demo<\/title>\n      <!-- Nonce im style-Tag erlaubt inline-CSS -->\n      <style nonce=\"${nonce}\">\n        body { font-family: sans-serif; padding: 2rem; }\n        h1 { color: #2563eb; }\n      <\/style>\n    <\/head>\n    <body>\n      <h1>Nonce-gesicherter Inline-Code<\/h1>\n      <!-- Nonce im script-Tag erlaubt inline-JavaScript -->\n      <script nonce=\"${nonce}\">\n        console.log('Dieser inline-Script ist durch den Nonce erlaubt.');\n        document.querySelector('h1').textContent = 'Nonce funktioniert!';\n      <\/script>\n    <\/body>\n    <\/html>\n  `);\n});\n\napp.listen(PORT, () => console.log(`Nonce-Demo l\u00e4uft auf Port ${PORT}`));<\/code><\/pre>\n\n\n\n
Lade die Seite zweimal neu und inspiziere den CSP-Header: Der Nonce-Wert \u00e4ndert sich bei jeder Anfrage. \u00d6ffne die Browser-Konsole und versuche, einen Script ohne Nonce auszuf\u00fchren. Der Browser verweigert ihn. Das ist der Nonce-basierte Schutz in Aktion.<\/p>\n\n\n\n
Kritischer Hinweis:<\/strong> Der Nonce muss wirklich zuf\u00e4llig und per Request frisch sein. Verwende niemals einen statischen Nonce. Ein Angreifer, der den Nonce einmalig aussp\u00e4ht (z. B. aus einem gecachten Response), kann ihn wiederverwenden. crypto.randomBytes(16)<\/code> erzeugt ausreichende Entropie (128 Bit), da die Wahrscheinlichkeit einer Kollision in der Praxis null ist.<\/p>\n\n\n\n
Schritt 7: Hash-basierte CSP f\u00fcr statische Inline-Scripts<\/h2>\n\n\n\n
Wenn der Inhalt eines <script><\/code>-Blocks sich nie \u00e4ndert, ist ein Hash eine Alternative zum Nonce. Der Browser berechnet den SHA-256-Hash des Script-Inhalts und vergleicht ihn mit dem im CSP-Header angegebenen Wert. Stimmen sie \u00fcberein, wird das Script ausgef\u00fchrt.<\/p>\n\n\n\n
So erzeugst du den SHA-256-Hash eines inline-Scripts in Node.js:<\/p>\n\n\n\n
const crypto = require('crypto');\n\n\/\/ Exakter Script-Inhalt (Whitespace inklusive)\nconst scriptContent = `console.log('Hallo Welt');`;\n\nconst hash = crypto\n  .createHash('sha256')\n  .update(scriptContent)\n  .digest('base64');\n\nconsole.log(`'sha256-${hash}'`);\n\/\/ Ausgabe: 'sha256-abc123...'<\/code><\/pre>\n\n\n\n
Den erzeugten Hash tr\u00e4gst du in den scriptSrc<\/code>-Direktive ein:<\/p>\n\n\n\n
const SCRIPT_HASH = `'sha256-${hash}'`;\n\napp.use(\n  helmet.contentSecurityPolicy({\n    directives: {\n      defaultSrc: [\"'self'\"],\n      scriptSrc: [\"'self'\", SCRIPT_HASH],\n      objectSrc: [\"'none'\"],\n      baseUri: [\"'self'\"]\n    }\n  })\n);\n\napp.get('\/', (req, res) => {\n  res.send(`\n    <html>\n      <body>\n        <!-- Nur dieser exakte Script-Inhalt ist erlaubt -->\n        <script>console.log('Hallo Welt');<\/script>\n      <\/body>\n    <\/html>\n  `);\n});<\/code><\/pre>\n\n\n\n
Der Vorteil von Hashes: Kein dynamisch generierter Wert n\u00f6tig, der Header kann gecacht werden. Der Nachteil: Sobald du auch nur ein Leerzeichen im Script-Inhalt \u00e4nderst, \u00e4ndert sich der Hash und du musst den Header aktualisieren. Hashes eignen sich daher f\u00fcr wirklich statische Scripts (z. B. ein Analytics-Snippet, das sich selten \u00e4ndert). CSP unterst\u00fctzt auch SHA-384 und SHA-512 f\u00fcr noch st\u00e4rkere Hashes.<\/p>\n\n\n\n
Schritt 8: Report-Only Modus und Violation Reporting einrichten<\/h2>\n\n\n\n
Bevor du eine strenge CSP in der Produktion aktivierst, empfiehlt das OWASP CSP Cheat Sheet ausdr\u00fccklich, zun\u00e4chst den Report-Only Modus<\/strong> zu nutzen. Der Header Content-Security-Policy-Report-Only<\/code> verh\u00e4lt sich wie ein normaler CSP-Header, blockiert aber keine Ressourcen, sondern sendet nur Verletzungsberichte. So siehst du, was eine k\u00fcnftige Policy brechen w\u00fcrde, ohne die Produktionsanwendung zu st\u00f6ren.<\/p>\n\n\n\n
const express = require('express');\nconst app = express();\nconst PORT = 3000;\nconst violations = [];\n\n\/\/ Report-Only Middleware\napp.use((req, res, next) => {\n  res.setHeader(\n    'Content-Security-Policy-Report-Only',\n    [\n      \"default-src 'self'\",\n      \"script-src 'self'\",\n      \"style-src 'self'\",\n      \"object-src 'none'\",\n      \"base-uri 'self'\",\n      \"report-uri \/csp-report\"\n    ].join('; ')\n  );\n  next();\n});\n\n\/\/ CSP Violation Report Endpunkt\napp.use(express.json({ type: 'application\/csp-report' }));\napp.post('\/csp-report', (req, res) => {\n  const report = req.body['csp-report'] || req.body;\n  console.log('CSP-Versto\u00df:', JSON.stringify(report, null, 2));\n  violations.push({\n    time: new Date().toISOString(),\n    ...report\n  });\n  res.status(204).end();\n});\n\n\/\/ Versto\u00df-Log einsehen\napp.get('\/violations', (req, res) => {\n  res.json(violations);\n});\n\napp.get('\/', (req, res) => {\n  res.send(`\n    <html>\n      <body>\n        <!-- Dieser Script w\u00fcrde im enforce-Modus blockiert (kein Nonce\/Hash) -->\n        <script>console.log('Versto\u00df wird geloggt aber nicht blockiert');<\/script>\n        <!-- Bild von externer Domain, w\u00fcrde in production blockiert -->\n        <img src=\"https:\/\/via.placeholder.com\/100\" alt=\"test\">\n      <\/body>\n    <\/html>\n  `);\n});\n\napp.listen(PORT, () => console.log(`Report-Only auf Port ${PORT}`));<\/code><\/pre>\n\n\n\n
Ein typischer Violation-Report vom Browser sieht so aus:<\/p>\n\n\n\n
{\n  \"csp-report\": {\n    \"document-uri\": \"http:\/\/localhost:3000\/\",\n    \"referrer\": \"\",\n    \"violated-directive\": \"script-src 'self'\",\n    \"effective-directive\": \"script-src\",\n    \"original-policy\": \"default-src 'self'; script-src 'self'; ...\",\n    \"blocked-uri\": \"inline\",\n    \"status-code\": 200,\n    \"script-sample\": \"console.log('Versto\u00df wird geloggt...\"\n  }\n}<\/code><\/pre>\n\n\n\n
Die Empfehlung: Setze Report-Only f\u00fcr mindestens 2 Wochen in der Produktion. Analysiere die eingehenden Reports und passe die Policy an, bis keine legitimen Ressourcen mehr blockiert werden. Erst dann wechselst du auf den Enforce-Header. Die modernere Alternative zu report-uri<\/code> ist report-to<\/code> in Kombination mit der Reporting-API, die einen strukturierteren Reporting-Mechanismus bietet und in aktuellen Chromium-Browsern unterst\u00fctzt wird.<\/p>\n\n\n\n
Schritt 9 und 10: strict-dynamic und Trusted Types API<\/h2>\n\n\n\n
strict-dynamic<\/strong> ist ein Schl\u00fcsselwort aus CSP Level 3, das die Verwaltung von Nonce-basierten Policies erheblich vereinfacht. Wenn ein Script durch einen Nonce oder Hash als vertrauensw\u00fcrdig markiert ist und dieses Script seinerseits weitere Scripts dynamisch l\u00e4dt (document.createElement('script')<\/code>), gelten diese Kind-Scripts ebenfalls als vertrauensw\u00fcrdig, ohne dass ihre Quell-URLs explizit in der Policy stehen m\u00fcssen.<\/p>\n\n\n\n
Das OWASP CSP Cheat Sheet<\/a> empfiehlt als moderne Produktions-Policy:<\/p>\n\n\n\n
app.use((req, res, next) => {\n  const nonce = crypto.randomBytes(16).toString('base64');\n  res.locals.nonce = nonce;\n\n  res.setHeader(\n    'Content-Security-Policy',\n    [\n      \"default-src 'self'\",\n      \/\/ strict-dynamic: nonce-approved Scripts d\u00fcrfen weitere Scripts laden\n      `script-src 'nonce-${nonce}' 'strict-dynamic'`,\n      \"style-src 'self'\",\n      \"object-src 'none'\",\n      \/\/ base-uri 'none' ist restriktiver als 'self'\n      \"base-uri 'none'\",\n      \"frame-ancestors 'none'\",\n      \"form-action 'self'\",\n      \"upgrade-insecure-requests\",\n      \"report-uri \/csp-report\"\n    ].join('; ')\n  );\n  next();\n});<\/code><\/pre>\n\n\n\n
Mit strict-dynamic<\/code> musst du nicht mehr alle CDN-URLs deiner JavaScript-Bibliotheken in der Policy auflisten, was die Policy wartbarer macht und weniger anf\u00e4llig f\u00fcr JSONP-Byp\u00e4sse ist.<\/p>\n\n\n\n
Trusted Types<\/strong> ist eine erg\u00e4nzende Browser-API, die DOM-XSS-Angriffe \u00fcber gef\u00e4hrliche Sinks wie innerHTML<\/code>, outerHTML<\/code> oder document.write()<\/code> verhindert. Anstatt rohe Strings an diese APIs zu \u00fcbergeben, erfordert Trusted Types das Erstellen einer Policy, die Strings in sichere Objekte transformiert:<\/p>\n\n\n\n
\/\/ CSP-Header mit Trusted Types\nContent-Security-Policy:\n  require-trusted-types-for 'script';\n  trusted-types appPolicy;\n\n\/\/ Client-seitiger JavaScript-Code\nconst policy = trustedTypes.createPolicy('appPolicy', {\n  createHTML(input) {\n    \/\/ DOMPurify als Sanitizer einsetzen\n    return DOMPurify.sanitize(input);\n  }\n});\n\n\/\/ Sicherer Einsatz von innerHTML\ndocument.querySelector('#output').innerHTML =\n  policy.createHTML(userInput);<\/code><\/pre>\n\n\n\n
Trusted Types ist in Chromium-Browsern (Chrome, Edge) verf\u00fcgbar und wird schrittweise in anderen Browsern eingef\u00fchrt. F\u00fcr Produktionsanwendungen empfiehlt sich Report-Only (Content-Security-Policy-Report-Only: require-trusted-types-for 'script'<\/code>) zum Testen, bevor auf Enforce umgestellt wird.<\/p>\n\n\n\n
Schritt 11: CSP f\u00fcr Single Page Applications (React, Vue, Angular)<\/h2>\n\n\n\n
SPAs stellen besondere Herausforderungen f\u00fcr CSP dar. React und Vue rendern DOM-Elemente dynamisch, und viele Build-Tools injizieren inline-Scripts in die index.html<\/code>. Folgende Strategie funktioniert f\u00fcr die meisten SPA-Setups mit einem Node.js\/Express-Backend:<\/p>\n\n\n\n
const express = require('express');\nconst helmet = require('helmet');\nconst crypto = require('crypto');\nconst path = require('path');\nconst app = express();\n\n\/\/ Nonce f\u00fcr jede Anfrage generieren\napp.use((req, res, next) => {\n  res.locals.nonce = crypto.randomBytes(16).toString('base64');\n  next();\n});\n\n\/\/ CSP f\u00fcr SPA: strict-dynamic erlaubt Bundle-Loader\napp.use((req, res, next) => {\n  helmet.contentSecurityPolicy({\n    directives: {\n      defaultSrc: [\"'self'\"],\n      scriptSrc: [\n        \"'self'\",\n        (req, res) => `'nonce-${res.locals.nonce}'`,\n        \"'strict-dynamic'\"\n      ],\n      styleSrc: [\"'self'\", \"'unsafe-inline'\"],\n      imgSrc: [\"'self'\", \"data:\", \"blob:\"],\n      connectSrc: [\n        \"'self'\",\n        \"https:\/\/api.deineapp.de\",\n        \"wss:\/\/ws.deineapp.de\"\n      ],\n      fontSrc: [\"'self'\"],\n      objectSrc: [\"'none'\"],\n      frameAncestors: [\"'none'\"],\n      baseUri: [\"'self'\"],\n      formAction: [\"'self'\"],\n      upgradeInsecureRequests: []\n    },\n    reportOnly: false\n  })(req, res, next);\n});\n\n\/\/ SPA: Index-HTML dynamisch rendern um Nonce einzusetzen\napp.get('\/', (req, res) => {\n  const nonce = res.locals.nonce;\n  \/\/ In Produktion: Template-Engine oder fs.readFile verwenden\n  res.send(`\n    <!DOCTYPE html>\n    <html lang=\"de\">\n    <head>\n      <meta charset=\"UTF-8\">\n      <title>React App<\/title>\n      <link rel=\"stylesheet\" href=\"\/static\/css\/main.css\">\n    <\/head>\n    <body>\n      <div id=\"root\"><\/div>\n      <!-- Nonce erm\u00f6glicht den Bundle-Loader und React hydration -->\n      <script nonce=\"${nonce}\" src=\"\/static\/js\/main.js\"><\/script>\n    <\/body>\n    <\/html>\n  `);\n});\n\n\/\/ Statische Assets servieren\napp.use('\/static', express.static(path.join(__dirname, 'build\/static')));\n\napp.listen(3000);<\/code><\/pre>\n\n\n\n
Wichtige Punkte f\u00fcr SPAs: 'unsafe-inline'<\/code> f\u00fcr styleSrc<\/code> ist bei vielen UI-Bibliotheken (Material UI, Ant Design) vorerst n\u00f6tig, da sie Styles direkt in den DOM schreiben. F\u00fcr connectSrc<\/code> musst du explizit alle API-Endpunkte und WebSocket-URLs eintragen. blob:<\/code> in imgSrc<\/code> ist oft n\u00f6tig, wenn Nutzer Bilder hochladen und diese \u00fcber URL.createObjectURL()<\/code> angezeigt werden.<\/p>\n\n\n\n
Schritt 12: CSP testen, debuggen und finalisieren<\/h2>\n\n\n\n
Bevor du die CSP in der Produktion schaltest, solltest du sie gr\u00fcndlich testen. Drei Werkzeuge sind hier unverzichtbar:<\/p>\n\n\n\n
1. Browser DevTools:<\/strong> In Chrome und Firefox gibt die Konsole detaillierte CSP-Fehlermeldungen aus, welche Direktive verletzt wurde und welche Ressource blockiert wird. \u00d6ffne DevTools mit F12, wechsle zum Reiter “Konsole” und lade die Seite neu. Alle CSP-Verst\u00f6\u00dfe erscheinen als rote Fehlermeldungen.<\/p>\n\n\n\n
2. CSP Evaluator:<\/strong> Das Tool CSP Evaluator von Google<\/a> analysiert deine Policy auf bekannte Schwachstellen, Bypass-M\u00f6glichkeiten und Konfigurationsfehler. F\u00fcge deinen CSP-Header-Wert ein und erhalte eine detaillierte Bewertung.<\/p>\n\n\n\n
3. Automatisierter Test in Node.js:<\/strong><\/p>\n\n\n\n
const http = require('http');\n\nfunction testCSP(port = 3000) {\n  return new Promise((resolve, reject) => {\n    http.get(`http:\/\/localhost:${port}\/`, (res) => {\n      const csp = res.headers['content-security-policy'];\n      if (!csp) {\n        reject(new Error('Kein CSP-Header gefunden!'));\n        return;\n      }\n\n      const checks = {\n        defaultSrc: csp.includes(\"default-src 'self'\"),\n        noUnsafeInlineScript: !csp.match(\/script-src[^;]*'unsafe-inline'\/),\n        noUnsafeEval: !csp.includes(\"'unsafe-eval'\"),\n        objectSrcNone: csp.includes(\"object-src 'none'\"),\n        baseUriRestricted: csp.includes(\"base-uri\"),\n        frameAncestors: csp.includes(\"frame-ancestors\"),\n        hasNonce: csp.includes(\"nonce-\") || csp.includes(\"sha256-\")\n      };\n\n      console.log('CSP-Pr\u00fcfergebnis:');\n      Object.entries(checks).forEach(([key, value]) => {\n        console.log(`  ${value ? '\u2713' : '\u2717'} ${key}`);\n      });\n\n      const passed = Object.values(checks).filter(Boolean).length;\n      console.log(`\\n${passed}\/${Object.keys(checks).length} Checks bestanden`);\n      resolve(checks);\n    }).on('error', reject);\n  });\n}\n\ntestCSP().catch(console.error);<\/code><\/pre>\n\n\n\n
Das Skript pr\u00fcft die wichtigsten Sicherheitskriterien und gibt eine \u00fcbersichtliche Zusammenfassung aus. F\u00fchre es als Teil deiner CI\/CD-Pipeline aus, um sicherzustellen, dass die CSP-Konfiguration nach jedem Deployment korrekt ist.<\/p>\n\n\n\n
F\u00fcr die finale Produktionskonfiguration empfiehlt die W3C CSP Level 3 Spezifikation<\/a> folgende Reihenfolge beim Rollout: (1) Report-Only mit einer strikten Policy f\u00fcr 2 Wochen, (2) Analyse der Violation Reports, (3) Policy anpassen bis alle legitimen Ressourcen erlaubt sind, (4) Umschalten auf Enforce-Modus, (5) Weiteres Monitoring \u00fcber den Reporting-Endpunkt.<\/p>\n\n\n\n
H\u00e4ufige Fehler bei der CSP-Implementierung<\/h2>\n\n\n\n
Diese f\u00fcnf Fehler f\u00fchren bei CSP-Implementierungen am h\u00e4ufigsten zu Sicherheitsl\u00fccken oder broken Deployments:<\/p>\n\n\n\n
Fehler 1: 'unsafe-inline'<\/code> in script-src erlauben.<\/strong> Sobald 'unsafe-inline'<\/code> in script-src<\/code> steht, ist der XSS-Schutz von CSP praktisch aufgehoben. Der Angreifer kann trotzdem beliebige inline-Scripts injizieren. Die korrekte Alternative sind Nonces oder Hashes. 'unsafe-inline'<\/code> wird zudem ignoriert, wenn ein Nonce oder Hash in der Policy vorhanden ist, weshalb es bei nonce-basierten Policies keinen Effekt hat, aber trotzdem nicht stehen sollte.<\/p>\n\n\n\n
Fehler 2: 'unsafe-eval'<\/code> erlauben.<\/strong> eval()<\/code>, Function()<\/code> und verwandte Konstrukte sind h\u00e4ufige XSS-Vektoren. Wer 'unsafe-eval'<\/code> in die Policy aufnimmt, \u00f6ffnet eine Hintert\u00fcr f\u00fcr Angreifer. Viele JavaScript-Bibliotheken sind ohne eval()<\/code> einsetzbar. Pr\u00fcfe die Anforderungen deiner Dependencies und versuche, auf eval<\/code>-freie Alternativen umzusteigen.<\/p>\n\n\n\n
Fehler 3: Statische Nonces wiederverwenden.<\/strong> Ein Nonce verliert seine Schutzwirkung, wenn er nicht bei jeder HTTP-Anfrage neu generiert wird. Ein Angreifer, der eine Seite mit einem gecachten Nonce in einem CDN oder Reverse Proxy sieht, kann ihn in seinen Angriffscode einf\u00fcgen. Stelle sicher, dass kein CDN oder Reverse Proxy deine HTML-Antworten mit CSP-Nonces cachet. Setze Cache-Control: no-store<\/code> f\u00fcr nonce-haltige Antworten.<\/p>\n\n\n\n
Fehler 4: base-uri nicht einschr\u00e4nken.<\/strong> Ohne base-uri 'self'<\/code> oder base-uri 'none'<\/code> kann ein Angreifer ein <base href=\"https:\/\/evil.com\"><\/code>-Tag injizieren. Alle relativen URLs auf der Seite werden dann auf die Domain des Angreifers umgeleitet, was Skripte, Styles und Formulare betrifft. Dieser Angriff ist subtil und wird oft \u00fcbersehen.<\/p>\n\n\n\n
Fehler 5: JSONP-f\u00e4hige Domains in script-src allowlisten.<\/strong> Wenn du eine Domain in script-src<\/code> eintr\u00e4gst, die JSONP-Endpunkte anbietet (z. B. \u00e4ltere Google-APIs, Social-Media-Widgets), kann ein Angreifer diese Endpunkte nutzen, um beliebigen JavaScript-Code einzuschleusen. Pr\u00fcfe bei jeder erlaubten Domain, ob sie JSONP-Callbacks unterst\u00fctzt. Die L\u00f6sung ist, stattdessen auf 'strict-dynamic'<\/code> mit Nonces umzusteigen, das JSONP-Byp\u00e4sse eliminiert.<\/p>\n\n\n\n
Fehler 6: object-src und plugin-types vergessen.<\/strong> Flash-Plugins und Java-Applets sind l\u00e4ngst obsolet, werden aber in \u00e4lteren Browsern noch unterst\u00fctzt und sind bekannte Exploit-Vektoren. object-src 'none'<\/code> schlie\u00dft diese Angriffsfl\u00e4che vollst\u00e4ndig.<\/p>\n\n\n\n
Fehler 7: Policy zu permissiv starten und nie versch\u00e4rfen.<\/strong> Viele Teams setzen eine breite Policy ein (“erst mal alles erlauben, damit nichts bricht”) und kommen nie dazu, sie zu versch\u00e4rfen. Der richtige Ansatz ist umgekehrt: Mit einem maximalen Restrict starten, Report-Only nutzen und nur das freischalten, was wirklich gebraucht wird.<\/p>\n\n\n\n
Troubleshooting: 8 h\u00e4ufige CSP-Probleme und ihre L\u00f6sungen<\/h2>\n\n\n\n
Problem<\/th>Ursache<\/th>L\u00f6sung<\/th><\/tr><\/thead>
Inline-Script wird blockiert trotz Nonce<\/td>Nonce im Header stimmt nicht mit Nonce im HTML \u00fcberein (z. B. durch Caching)<\/td>Cache-Control: no-store f\u00fcr HTML-Antworten setzen, Nonce-Generierung debuggen<\/td><\/tr>
Externe Schriftart (Google Fonts) blockiert<\/td>font-src fehlt oder erlaubt fonts.gstatic.com nicht<\/td>font-src ‘self’ https:\/\/fonts.gstatic.com hinzuf\u00fcgen<\/td><\/tr>
WebSocket-Verbindung blockiert<\/td>wss:\/\/ in connect-src fehlt<\/td>connect-src ‘self’ wss:\/\/dein-server.de hinzuf\u00fcgen<\/td><\/tr>
React\/Vue Build-Scripts blockiert<\/td>Gebaute Bundle-Files haben keine Nonce<\/td>strict-dynamic einsetzen oder Nonce via Template-Engine in index.html injizieren<\/td><\/tr>
Blob-URLs f\u00fcr Datei-Uploads blockiert<\/td>blob: in img-src fehlt<\/td>img-src ‘self’ data: blob: erg\u00e4nzen<\/td><\/tr>
eval() in Third-Party-Library wirft CSP-Fehler<\/td>Bibliothek verwendet eval() oder Function()-Konstruktor<\/td>Bibliothek auf eval-freie Version upgraden oder ersetzen; als letztes Mittel unsafe-eval nur f\u00fcr src-Muster dieser Bibliothek<\/td><\/tr>
CSP-Header erscheint nicht in curl-Ausgabe<\/td>Middleware falsch platziert (nach dem ersten res.send() Aufruf)<\/td>Helmet\/CSP-Middleware vor allen Routen platzieren, app.use() vor app.get()<\/td><\/tr>
Bilder von S3 oder CDN werden blockiert<\/td>img-src erlaubt nur ‘self’<\/td>img-src ‘self’ https:\/\/dein-bucket.s3.eu-central-1.amazonaws.com hinzuf\u00fcgen<\/td><\/tr>
report-uri erh\u00e4lt keine Berichte<\/td>Content-Type des Reports nicht erkannt<\/td>express.json({ type: ‘application\/csp-report’ }) als Middleware hinzuf\u00fcgen<\/td><\/tr>
Policy bricht Stripe\/PayPal-Checkout<\/td>Payment-IFrames werden von frame-src blockiert<\/td>frame-src ‘self’ https:\/\/js.stripe.com oder entsprechende Payment-CDN-URL erg\u00e4nzen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Ein h\u00e4ufiges Debugging-Problem ist, dass der CSP-Header korrekt gesetzt ist, aber der Browser ihn ignoriert, weil eine meta http-equiv=\"Content-Security-Policy\"<\/code>-Direktive im HTML-Dokument einen anderen Wert setzt. Der Header hat Priorit\u00e4t vor dem Meta-Tag, aber wenn beide vorhanden sind, k\u00f6nnen unerwartete Konflikte entstehen. Entferne alle CSP-Meta-Tags und setze die Policy ausschlie\u00dflich \u00fcber den HTTP-Header.<\/p>\n\n\n\n
Fortgeschrittene Tipps: Production-Ready CSP<\/h2>\n\n\n\n
F\u00fcr eine produktionsreife CSP-Implementierung gibt es einige fortgeschrittene Muster, die \u00fcber die Grundkonfiguration hinausgehen:<\/p>\n\n\n\n
Differenzierte Policies f\u00fcr verschiedene Routen:<\/strong> Nicht alle Seiten einer Anwendung haben die gleichen Anforderungen. Eine Admin-Konsole braucht keine Payment-iFrames. Eine \u00f6ffentliche Produktseite braucht keine WebSocket-Verbindungen. Setze route-spezifische CSP-Header \u00fcber separate Middleware-Instanzen statt einer globalen Policy.<\/p>\n\n\n\n
Reporting-API statt report-uri:<\/strong> Die modernere report-to<\/code>-Direktive verwendet die Reporting API und unterst\u00fctzt Gruppenreporting, Sampling-Rate und strukturiertere Reports. F\u00fcr eine zukunftssichere Implementierung kombiniere beide:<\/p>\n\n\n\n
\/\/ Reporting-Gruppe definieren\nres.setHeader('Reporting-Endpoints', 'csp-endpoint=\"https:\/\/deine-app.de\/csp-report\"');\n\n\/\/ CSP mit report-to und report-uri (Backward-Compat.)\nres.setHeader(\n  'Content-Security-Policy',\n  [\n    \"default-src 'self'\",\n    `script-src 'nonce-${nonce}' 'strict-dynamic'`,\n    \"object-src 'none'\",\n    \"base-uri 'none'\",\n    \"report-to csp-endpoint\",\n    \"report-uri \/csp-report\"  \/\/ Fallback f\u00fcr \u00e4ltere Browser\n  ].join('; ')\n);<\/code><\/pre>\n\n\n\n
CSP-Nonce mit Template-Engines (EJS, Pug, Handlebars):<\/strong> Template-Engines machen es einfach, den Nonce in alle Templates zu injizieren. Bei EJS \u00fcbergibst du den Nonce als Template-Variable und verwendest ihn als <%- nonce %><\/code>. Das Wichtigste ist, dass alle Script- und Style-Tags den Nonce erhalten, auch die vom Framework generierten.<\/p>\n\n\n\n
Sicherheitsaudit mit dem OWASP Secure Headers Project:<\/strong> Das OWASP Secure Headers Project<\/a> pflegt eine Referenzliste empfohlener Header-Konfigurationen. Dort findest du aktuelle Empfehlungen f\u00fcr CSP, HSTS, X-Frame-Options und weitere Header, die du neben CSP setzen solltest.<\/p>\n\n\n\n
Performance-Aspekte:<\/strong> CSP-Header haben keinen messbaren Performance-Einfluss auf die Serverseite, da es sich um einfache String-Operationen handelt. Der Browser muss jedoch die Policy parsen und bei jeder Ressourcenanforderung pr\u00fcfen. Bei sehr langen Policies (z. B. viele allowlistete Domains) kann dies marginal l\u00e4nger dauern. Eine gut strukturierte Policy mit Nonces statt langen Domain-Listen ist daher auch aus Performance-Sicht vorzuziehen.<\/p>\n\n\n\n
Vollst\u00e4ndiges Beispielprojekt: Produktionsbereite CSP<\/h2>\n\n\n\n
Hier ist die vollst\u00e4ndige, produktionsbereite server.js<\/code> mit allen besprochenen Features:<\/p>\n\n\n\n
const express = require('express');\nconst helmet = require('helmet');\nconst crypto = require('crypto');\nconst app = express();\nconst PORT = process.env.PORT || 3000;\nconst violations = [];\n\n\/\/ 1. Nonce pro Request erzeugen\napp.use((req, res, next) => {\n  res.locals.nonce = crypto.randomBytes(16).toString('base64');\n  next();\n});\n\n\/\/ 2. Helmet mit vollst\u00e4ndiger CSP-Konfiguration\napp.use((req, res, next) => {\n  const nonce = res.locals.nonce;\n  helmet.contentSecurityPolicy({\n    directives: {\n      defaultSrc: [\"'self'\"],\n      scriptSrc: [\n        \"'self'\",\n        `'nonce-${nonce}'`,\n        \"'strict-dynamic'\"\n      ],\n      styleSrc: [\"'self'\", `'nonce-${nonce}'`],\n      imgSrc: [\"'self'\", \"data:\", \"blob:\"],\n      connectSrc: [\"'self'\"],\n      fontSrc: [\"'self'\"],\n      objectSrc: [\"'none'\"],\n      mediaSrc: [\"'self'\"],\n      frameSrc: [\"'none'\"],\n      frameAncestors: [\"'none'\"],\n      baseUri: [\"'none'\"],\n      formAction: [\"'self'\"],\n      upgradeInsecureRequests: [],\n      reportUri: ['\/csp-report']\n    }\n  })(req, res, next);\n});\n\n\/\/ 3. CSP Violation Reports empfangen\napp.use(express.json({ type: ['application\/json', 'application\/csp-report'] }));\n\napp.post('\/csp-report', (req, res) => {\n  const report = req.body?.['csp-report'] || req.body;\n  if (report) {\n    const entry = {\n      time: new Date().toISOString(),\n      ip: req.ip,\n      violatedDirective: report['violated-directive'],\n      blockedUri: report['blocked-uri'],\n      documentUri: report['document-uri']\n    };\n    violations.push(entry);\n    \/\/ In Produktion: Logging-Service verwenden (z.B. Winston, Sentry)\n    console.warn('CSP-Versto\u00df:', entry);\n  }\n  res.status(204).end();\n});\n\n\/\/ 4. Hauptroute mit Nonce-Injection\napp.get('\/', (req, res) => {\n  const nonce = res.locals.nonce;\n  res.send(`\n    <!DOCTYPE html>\n    <html lang=\"de\">\n    <head>\n      <meta charset=\"UTF-8\">\n      <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">\n      <title>CSP Demo<\/title>\n      <style nonce=\"${nonce}\">\n        body { font-family: system-ui, sans-serif; max-width: 800px; margin: 2rem auto; padding: 1rem; }\n        .badge { background: #22c55e; color: white; padding: .25rem .75rem; border-radius: 9999px; font-size: .875rem; }\n        pre { background: #f1f5f9; padding: 1rem; border-radius: .5rem; overflow-x: auto; }\n      <\/style>\n    <\/head>\n    <body>\n      <h1>Content Security Policy <span class=\"badge\">aktiv<\/span><\/h1>\n      <p>Diese Seite ist durch einen Nonce-basierten CSP-Header gesichert.<\/p>\n      <pre id=\"csp-output\">CSP wird geladen...<\/pre>\n      <script nonce=\"${nonce}\">\n        \/\/ Dieser inline-Script ist durch den Nonce erlaubt\n        fetch('\/api\/csp-info')\n          .then(r => r.json())\n          .then(data => {\n            document.getElementById('csp-output').textContent =\n              'Nonce: ' + data.nonce.substring(0, 10) + '... (erste 10 Zeichen)\\\\n' +\n              'Violations gesamt: ' + data.violations;\n          });\n      <\/script>\n    <\/body>\n    <\/html>\n  `);\n});\n\n\/\/ 5. API-Endpunkt f\u00fcr CSP-Status\napp.get('\/api\/csp-info', (req, res) => {\n  res.json({\n    nonce: res.locals.nonce,\n    violations: violations.length\n  });\n});\n\napp.listen(PORT, () => {\n  console.log(`Server l\u00e4uft auf Port ${PORT}`);\n  console.log(`CSP aktiv: Nonce-basiert mit strict-dynamic`);\n});<\/code><\/pre>\n\n\n\n
Teste die Anwendung mit node server.js<\/code>, \u00f6ffne http:\/\/localhost:3000<\/code> und \u00fcberpr\u00fcfe den CSP-Header in den Browser-DevTools unter Netzwerk > Headers. Du siehst den vollst\u00e4ndigen Header inklusive des frisch generierten Nonce-Werts, der bei jedem Reload wechselt.<\/p>\n\n\n\n
Weiterf\u00fchrende Inhalte<\/h2>\n\n\n\n
Content Security Policy ist eine von mehreren Sicherheitsebenen f\u00fcr Node.js-Anwendungen. Diese Artikel bauen auf dem hier gezeigten Wissen auf oder erg\u00e4nzen es:<\/p>\n\n\n\n