Eine Content Security Policy (CSP) begrenzt, aus welchen Quellen ein Browser Skripte, Styles, Bilder oder andere Ressourcen laden darf. Damit reduziert sie die Angriffsfläche für bestimmte Cross-Site-Scripting-Szenarien. Oracle APEX 24.2 arbeitet dabei strenger mit Inline-JavaScript und Inline-CSS und verwendet, wo nötig, Nonces oder Hashes statt pauschaler Freigaben.
1. Report-Only zum Beobachten verwenden
APEX unterstützt die Header Content-Security-Policy-Report-Only und Content-Security-Policy. Report-Only blockiert noch keine Inhalte, meldet aber Verstöße. Das ist der sichere erste Schritt für eine bestehende Anwendung mit Plug-ins, Dynamic Actions und eigenem JavaScript.
Beobachten Sie zunächst typische Seiten: Login, Dashboard, Formulare, Dialoge und Seiten mit Datei- oder REST-Integration. Sortieren Sie die Meldungen nach Ursache. Ein einzelner fehlender Host kann viele Meldungen erzeugen; umgekehrt kann ein Inline-Handler auf nur einer alten Seite den Rollout blockieren.
2. Nonce und Hash statt unsafe-inline
APEX kann Inline-Skripte und Styles mit einem eindeutigen Nonce pro Request versehen. In der CSP wird dafür der APEX-Platzhalter #APEX_CSP_NONCE# verwendet. Für bestimmte sichere Inline-Ausnahmen stehen außerdem Hashes und die von APEX bereitgestellten Substitution Strings zur Verfügung.
Übernehmen Sie nicht einfach 'unsafe-inline', nur damit die Warnungen verschwinden. Dadurch wird die Policy deutlich schwächer. Verschieben Sie eigenen JavaScript-Code in statische Dateien oder verwenden Sie deklarative Dynamic Actions. Eigene Style-Tags sollten ebenfalls in eine zentrale CSS-Datei wandern, wenn sie nicht zwingend dynamisch sein müssen.
3. Header zentral in APEX konfigurieren
Die Header werden in den Security Attributes der Anwendung unter Browser Security und HTTP Response Headers hinterlegt. Verwenden Sie Report-Only für die Erprobung und wechseln Sie erst nach der Bereinigung auf die erzwingende Variante. Eine einfache Ausgangsbasis kann so aussehen:
default-src 'self' #APEX_CSP_NONCE# 'unsafe-hashes' #APEX_CSP_HASHES#;
object-src 'none'; img-src 'self' data:;Diese Direktiven sind kein universelles fertiges Regelwerk. Fonts, externe APIs, Bilder, WebSockets, Karten oder Analyse-Dienste benötigen je nach Architektur zusätzliche, ausdrücklich erlaubte Quellen. Ergänzen Sie nur Quellen, die die Anwendung tatsächlich benötigt, und prüfen Sie jede Ausnahme fachlich.
4. Eigene Komponenten und Plug-ins prüfen
Nach dem Aktivieren der Policy testen Sie alle Seitenpfade mit Browser-Konsole und Netzwerkprotokoll. Besonders häufig betroffen sind individuelle Plug-ins, Inline-Event-Handler, externe JavaScript-Bibliotheken und Widgets, die HTML mit Inline-Styles erzeugen. Aktualisieren Sie das Plug-in oder verlagern Sie die betroffene Logik, statt die gesamte Policy zu lockern.
Auch ein erfolgreicher Seitenaufruf reicht nicht als Test. Prüfen Sie Speichern, Validierungen, AJAX-Aktionen, modale Dialoge, Datei-Downloads und Fehlerseiten. Testen Sie zusätzlich mit einem Benutzer ohne Entwicklerrechte, weil administrative Pfade andere Ressourcen laden können.
Praktische Checkliste
- Report-Only-Header in den Security Attributes konfigurieren.
- Wichtige Seiten und Nutzerpfade mit Browser-Konsole testen.
- Inline-Code in statische Dateien oder deklarative Aktionen verschieben.
- APEX-Nonce- und Hash-Platzhalter korrekt einsetzen.
- Externe Quellen auf das notwendige Minimum begrenzen und erst danach CSP erzwingen.
Fazit
APEX 24.2 verbessert die Grundlage für eine strengere Content Security Policy, indem Inline-Ressourcen kontrollierter behandelt werden. Der sichere Weg führt über Beobachtung, kleine Anpassungen und wiederholte Regressionstests. So wird CSP zu einem belastbaren Sicherheitsstandard der Anwendung und nicht zu einer Sammlung zufälliger Ausnahmen.
Weiterführend: CSP-Verbesserungen in APEX 24.2, die APEX-Administrationsdokumentation zu CSP und CSP-Substitution Strings.