PrimeFaces und Content-Security-Header?

**Ja: PrimeFaces unterstützt Content Security Policy, aber nur sauber, wenn du PrimeFaces-eigene Inline-Skripte über das eingebaute CSP-Handling laufen lässt und deinen Header darauf abstimmst.** PrimeFaces hat dafür eine eigene CSP-Unterstützung und ein Showcase/Testbeispiel; CSP selbst wird per `Content-Security-Policy`-Header des Servers erzwungen. ([primefaces.github.io](https://primefaces.github.io/primefaces/)) ## Was das praktisch bedeutet PrimeFaces erzeugt an vielen Stellen JavaScript für Widgets, AJAX und Initialisierung. Genau das kollidiert mit einer strengen CSP, wenn du einfach nur `script-src 'self'` setzt. Dann blockiert der Browser diese Skripte sofort. PrimeFaces stellt deshalb eine eigene CSP-Funktionalität bereit, die auf `script-src` abgestimmt ist. ([primefaces.github.io](https://primefaces.github.io/primefaces/jsdocs/modules/src_PrimeFaces.PrimeFaces.csp.html)) Der entscheidende Punkt ist: **Nicht PrimeFaces ist das Problem, sondern ungeplantes Inline-JavaScript in JSF-Seiten, Templates oder Fremdkomponenten.** PrimeFaces kann seinen Teil abfedern, aber eigene `onclick`, rohe `<script>`-Blöcke oder andere JSF-/UI-Bibliotheken brechen dir die Policy oft trotzdem. Das ist in der Praxis der häufigste Fehler und wird in vielen oberflächlichen Antworten nicht klar genug gesagt. ([primefaces.org](https://www.primefaces.org/showcase/ui/misc/csp.xhtml)) ## Sinnvolle CSP-Strategie mit PrimeFaces Für PrimeFaces ist eine **nonce-basierte CSP** in der Regel der saubere Weg. Also nicht pauschal `'unsafe-inline'`, sondern pro Request ein Nonce im Header und dieselbe Nonce für erlaubte Skripte. CSP erlaubt genau dieses Modell ausdrücklich. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy)) Ein typischer Startpunkt ist: ```http Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<RANDOM>'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; ``` Wichtig dabei: **`style-src` ist oft der nächste Stolperstein.** Selbst wenn `script-src` sauber läuft, scheitern viele PrimeFaces-Seiten danach an Inline-Styles, Themes, Icon-Fonts oder Drittressourcen. Genau deshalb ist „CSP aktiviert“ noch lange nicht „CSP produktionsreif“. ## Was du vermeiden solltest `'unsafe-inline'` in `script-src` macht den wichtigsten Sicherheitsgewinn von CSP praktisch kaputt. Wenn du das setzt, läuft PrimeFaces zwar oft schneller „irgendwie“, aber du verlierst genau den Schutz gegen viele XSS-Szenarien, für den CSP gedacht ist. MDN beschreibt CSP genau als Mechanismus, um solche Code-Injections zu begrenzen. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)) Ebenfalls problematisch: mehrere UI-Bibliotheken mischen, wenn nur eine davon CSP-konform arbeitet. Dann wirkt es so, als sei PrimeFaces inkompatibel, obwohl tatsächlich eine andere Bibliothek oder eigener Legacy-Code die Verstöße erzeugt. ([stackoverflow.com](https://stackoverflow.com/questions/63824293/content-security-policy-default-setup-of-primefaces-restricts-bootsfaces-scripts)) ## Klare Empfehlung Wenn du PrimeFaces mit CSP betreiben willst, ist der richtige Weg: 1. **PrimeFaces-CSP-Funktionen nutzen** 2. **CSP per Nonce im Response-Header ausliefern** 3. **eigene Inline-Skripte und HTML-Event-Handler entfernen** 4. **Fremdkomponenten separat prüfen** 5. **zuerst mit Report-Only testen, dann scharf schalten** ([primefaces.github.io](https://primefaces.github.io/primefaces/)) Die offizielle [PrimeFaces-Doku zu Content Security Policy](https://primefaces.github.io/primefaces/15_0_0/#/core/contentsecuritypolicy) ist dafür der wichtigste Einstieg. Für die Regeln des Headers selbst ist die [CSP-Referenz von MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) die beste Ergänzung.