Lässt sich Content Security Policy im WebSphere Application Server oder IBM HTTP Server generell unabhängig von der Anwendung konfigurieren?

**Ja – technisch kann man CSP serverseitig unabhängig von der Anwendung setzen, aber „generell für alles“ ist das nur beim IBM HTTP Server sinnvoll. Beim WebSphere Application Server ist eine globale, anwendungsunabhängige CSP in der Praxis nicht der richtige Ort, weil CSP vom tatsächlich ausgelieferten HTML, JavaScript und den eingebundenen Quellen abhängt.** ## Der entscheidende Unterschied **IBM HTTP Server (IHS):** Ja, dort lässt sich CSP grundsätzlich zentral als HTTP-Response-Header konfigurieren, typischerweise über Apache-Mechanismen wie `mod_headers`. Das ist der saubere Weg, wenn du einen Header vor alle oder ausgewählte Responses setzen willst. IBM HTTP Server basiert auf Apache HTTP Server; Header-Manipulation auf Webserver-Ebene ist dafür der naheliegende Mechanismus. IBM-Dokumentation und IBM-nahe Beispiele zeigen genau dieses Prinzip: Sicherheits-Header werden als Response-Header am Webserver bzw. vorgelagert gesetzt. ([cloud.ibm.com](https://cloud.ibm.com/docs/cis?topic=cis-setting-security-headers)) **WebSphere Application Server (WAS):** Nicht sinnvoll als pauschale, serverweite Standardkonfiguration für beliebige Anwendungen. WAS kennt zwar HTTP-Transport- und Header-bezogene Einstellungen, aber daraus folgt **keine** allgemeine, robuste CSP-Konfiguration für alle Anwendungen. CSP ist keine rein infrastrukturelle Serveroption wie etwa `Server`-Header ausblenden, sondern eine inhaltliche Policy pro Anwendung bzw. pro ausgelieferter Seite. Die IBM-Doku zu HTTP-Transport-Custom-Properties zeigt eher Container-/Transport-Themen, nicht eine generische globale CSP-Verwaltung für alle Apps. ([ibm.com](https://www.ibm.com/docs/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/rrun_chain_httpcustom.html)) ## Warum „global“ oft die falsche Idee ist CSP wirkt nur dann korrekt, wenn sie zu den tatsächlichen Ressourcen der Anwendung passt: Skripte, Styles, Fonts, Frames, APIs, CDNs, Inline-Skripte, Nonces, Hashes. Genau deshalb ist eine einzige globale Policy für mehrere Anwendungen oft entweder: - **zu streng** und bricht Funktionen, oder - **zu locker** und bringt kaum Sicherheitsgewinn. Der wichtige Praxispunkt ist: **CSP ist keine reine Serverhärtung, sondern Teil des Anwendungsdesigns.** MDN beschreibt CSP ausdrücklich als Response-Header, der festlegt, welche Quellen der Browser laden und ausführen darf. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy?source=post_page---------------------------)) ## Was daraus praktisch folgt Wenn du **eine zentrale, anwendungsunabhängige Stelle** suchst, nimm **IBM HTTP Server** oder einen vorgeschalteten Reverse Proxy / Load Balancer. Wenn du **eine wirklich wirksame CSP** willst, muss die Policy **pro Anwendung** abgestimmt werden. Besonders bei älteren WebSphere-Anwendungen ist das wichtig, weil dort oft Inline-JavaScript, `unsafe-inline`, `unsafe-eval` oder externe Altlasten im Spiel sind. ## Klare Empfehlung **Ja, im IBM HTTP Server kannst du CSP zentral konfigurieren. Für WebSphere selbst solltest du CSP nicht als generelle, anwendungsblinde Servereinstellung betrachten, sondern als Policy, die pro Anwendung definiert und getestet werden muss.** Der beste Kompromiss in der Praxis ist: - **IHS** setzt den Header zentral, - **aber** nur mit einer **pro Anwendung passenden Policy** oder zumindest mit URL-/VirtualHost-spezifischen Regeln, - nicht mit einer einzigen pauschalen CSP für alles. Ein typischer Ansatz auf IHS-Ebene wäre z. B. ein zentral gesetzter Header wie: ```apache Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; frame-ancestors 'self'" ``` Das ist aber nur ein technisches Beispiel, **keine** allgemein sichere Standard-Policy für jede Anwendung.