Moderne Webseiten bestehen nicht ausschließlich aus dem eigenen JavaScript einer Organisation. Zahlungsseiten, Analyse-Tools, Chat-Widgets, A/B-Test-Systeme, Anzeigen-Tags und Zahlungs-SDKs können jeweils mehrere Drittanbieter-Skripte laden. Wird eines dieser Skripte kompromittiert, kann bösartiger Code im Browser des Benutzers die klassischen Anfrage-Kontrollen eines WAAP vollständig umgehen.
Bei Zahlungsabläufen insbesondere ist client-seitiges Risiko nicht mehr nur eine Best-Practice-Frage. PCI DSS 4.0 v4.0.1 hat die Kontrolle, das Inventar und die Integrität von Skripten auf Zahlungsseiten stärker in den Fokus gerückt. Organisationen müssen nachweisen können, welche Quellen auf welchen Seiten ausgeführt werden dürfen.
Von Anwendungsteams zu verlangen, dass sie CSP, HSTS, Frame-Schutz und Referrer-Policy-Header manuell auf jeder Seite hinzufügen, ist nicht nachhaltig. Codeänderungen sind in Legacy-Anwendungen schwierig; in modernen Anwendungen wenden verschiedene Service-Teams möglicherweise nicht konsistent denselben Sicherheitsstandard an. Das Ergebnis sind Sicherheits-Header, die auf manchen Seiten vorhanden und auf anderen fehlen.
Der richtige Ansatz ist es, Browser-Sicherheits-Header zentral, unabhängig vom Anwendungscode und aus einer richtliniengesteuerten Position heraus durchzusetzen. Der ADC sollte Antwort-Header umschreiben, um CSP, HSTS, Clickjacking-Schutz, MIME-Sniffing-Prävention, Referrer-Kontrolle und Fingerprint-Bereinigung zu standardisieren.
TR7 Client-Side Script Protection liefert dieses Modell: Es wendet grundlegende Sicherheits-Header für client-seitige Risiken auf vService-Ebene an und verknüpft die Browser-Sicherheit mit der zentralen WAAP-Richtlinie.
TR7 implementiert Client-Side Script Protection durch Umschreiben von Antwort-Headern, ein CSP-Profil, Fingerprint-Bereinigung und Compliance-Sichtbarkeit.
TR7 wendet Sicherheits-Header in der HTTP-Antwortphase mit set-header- oder add-header-Verhalten an. Browser-Sicherheitskontrollen lassen sich aktivieren, ohne Anwendungscode oder Zertifikatstruktur zu ändern.
Der Content-Security-Policy-Header teilt dem Browser das erlaubte Quellmodell mit. TR7 bietet derzeit grundlegenden CSP-Schutz über einen festen `default-src 'self';`-Ansatz.
Header wie Server, X-Powered-By, X-AspNet-Version und X-AspNetMvc-Version können aus Antworten entfernt werden. Dadurch wird es für Angreifer schwieriger, ein Technologie-Inventar zu erstellen und CVEs zuzuordnen.
vServices mit einer aktiven securityHeaders-Regel können als Nachweis in Compliance-Berichten ausgewiesen werden. Dies stärkt den Prüfpfad für Zahlungsseiten-Sicherheit und client-seitige Kontrollprozesse.
Client-Side Script Protection wendet 8 vorgefertigte Sicherheits-Header unter einer einzigen securityHeaders-Regel an.
TR7 kann den Content-Security-Policy-Header über die securityHeaders-Regel hinzufügen. Das aktuelle Verhalten erzeugt eine Basis-Sicherheitsrichtlinie mit `default-src 'self';`. Diese Richtlinie zielt auf einen Browser-Standard ab, der nur Ressourcen vom gleichen Ursprung akzeptiert. Komplexere CSP-Anforderungen sollten über benutzerdefinierte Header-Konfiguration oder anwendungsseitige Änderungen adressiert werden.
Der Strict-Transport-Security-Header kann auf TLS-Verbindungen angewendet werden. Er weist den Browser an, HTTPS für die betreffende Domain zu erfordern. Optionen wie includeSubDomains und preload bieten ein strengeres Sicherheitsverhalten. HSTS wird nur im TLS-Kontext angewendet, um die Ausgabe einer fehlerhaften Richtlinie an reine HTTP-Hosts zu verhindern.
Der X-Frame-Options-Header kann mit dem SAMEORIGIN-Wert angewendet werden. Dadurch wird verhindert, dass die Seite in einem iframe auf einem anderen Ursprung geladen wird. Dies trägt dazu bei, das Clickjacking-Risiko insbesondere auf Login-, Zahlungs-, Admin-Panel- und sensiblen Transaktionsseiten zu reduzieren. Es bietet kostengünstigen Basisschutz gegen User-Interface-Redress-Angriffe.
Der X-Content-Type-Options-Header kann mit dem nosniff-Wert hinzugefügt werden. Dies verhindert, dass der Browser einen Content-Type errät und Inhalte in einem unerwarteten Format ausführt. Die Kontrolle ist besonders wertvoll für Datei-Upload-Abläufe, statische Inhalte und Legacy-Anwendungen, die falsche Content-Types zurückgeben. Client-seitige Risiken durch MIME-Confusion werden reduziert.
Der Referrer-Policy-Header kann mit einem no-referrer-when-downgrade-Standard angewendet werden. Dies begrenzt das Auslaufen von Referrer-Informationen in Szenarien wie dem Übergang von HTTPS zu HTTP. Referrer-Verhalten ist bei URLs wichtig, die Bürger-, Kunden- oder Session-Parameter enthalten. Organisationen können zentral begrenzen, wie viele Quell-URL-Informationen der Browser an externe Seiten weitergibt.
Der Permission-Policy-Header kann verwendet werden, um den Zugriff auf Browser-Funktionen wie Mikrofon, Kamera, Geolokalisierung und ähnliche APIs einzuschränken. TR7 wendet diesen Header unter der securityHeaders-Regel an, um unnötige Browser-Berechtigungsflächen zu reduzieren. Besonders auf Portal-, Zahlungs- und Admin-Bildschirmen wird verhindert, dass Seiten auf unerwartete APIs zugreifen. Client-seitige Sicherheit ist nicht allein auf den Skript-Ursprung beschränkt.
Obwohl der X-XSS-Protection-Header in modernen Browsern nur begrenzte Wirkung hat, kann er für die Kompatibilität mit älteren Clients verwendet werden. Das `1; mode=block`-Verhalten aktiviert in einigen Legacy-Browsern einen grundlegenden XSS-Filter. Dieser Header ist für sich allein keine Sicherheitsgarantie und sollte neben CSP- und WAAP-Kontrollen betrachtet werden. Er bietet eine kostengünstige zusätzliche Schicht für Organisationen mit einer älteren Nutzerbasis.
TR7 kann Header wie Server, X-Powered-By, X-AspNet-Version und X-AspNetMvc-Version entfernen. Diese Header können auf den verwendeten Anwendungsserver, das Framework oder die Laufzeitversion hinweisen. Angreifer können diese Informationen für CVE-Zuordnung und gezielte Exploit-Versuche nutzen. Fingerprint-Bereinigung ist ein praktischer Härtungsschritt, der die sichtbare Angriffsfläche reduziert.
securityHeaders kann als Regeltyp an bestimmte vService-, Domain- oder Pfad-Bedingungen gebunden werden. Eine Zahlungsseite kann mit einem strengeren Satz betrieben werden, ein internes Portal mit einem anderen und eine Legacy-Anwendung mit einer permissiveren Kombination. Dies verhindert, dass eine einzige globale Header-Richtlinie Anwendungen beschädigt. Operatoren wenden Sicherheits-Header entsprechend dem Service-Kontext an.
TR7 implementiert den aktuellen Umfang der Client-Side Script Protection auf der Antwort-Header-Ebene. Es ist kein zusätzlicher JavaScript-Agent, Client-SDK oder separater Reverse-Proxy erforderlich. Dieser Ansatz bietet geringe Latenz und breite Kompatibilität. Die tatsächliche aktuelle Fähigkeit ist die Standardisierung von Sicherheits-Headern; es wird kein Anspruch auf Runtime-Skimmer-Erkennung oder automatische SRI-Injektion erhoben.
vServices mit einer aktiven securityHeaders-Regel können in Compliance-Berichten ausgewiesen werden. Dies erleichtert es, Prüfern gegenüber genau darzulegen, wo Zahlungsseiten-Sicherheits-Header angewendet werden. Es unterstützt die Erstellung technischer Nachweise für client-seitige Sicherheitserwartungen gemäß PCI DSS 4.0 v4.0.1 Abschnitt 6.4.3. Die Berichterstellung macht nicht nur sichtbar, dass eine Header-Richtlinie konfiguriert ist, sondern auf welchen Services sie aktiv ist.
Wenn benutzerdefinierte HTML-Seiten zurückgegeben werden — etwa für Bot-Schutz oder Zugangssperrung — können Sicherheits-Header auf demselben Antwortpfad aufrechterhalten werden. Dies verhindert, dass Fehler- oder Challenge-Seiten mit schwächeren Sicherheits-Headern zurückgegeben werden als die Hauptanwendung. Jede dem Benutzer präsentierte Antwort nähert sich demselben grundlegenden Browser-Sicherheitsstandard an. Konsistenz ist besonders bei Login- und Bot-Verifikationsabläufen wichtig.
Client-Side Script Protection arbeitet zusammen mit Antwort-Header-Reihenfolge, HSTS-Bedingung, festem CSP-Verhalten, dem securityHeaders-Regeltyp und Fingerprint-Bereinigung.
TR7 kann einige Header mit set-header überschreiben und andere mit add-header hinzufügen. Diese Unterscheidung bestimmt, wie vorhandene Anwendungs-Header sich verhalten. Vor dem Wechsel in die Produktion empfiehlt es sich zu testen, ob die eigenen Header der Anwendung mit den von TR7 hinzugefügten in Konflikt stehen.
HSTS sollte nur auf TLS-Verbindungen angewendet werden. TR7 verknüpft diesen Header mit der ssl_fc-Bedingung, um zu verhindern, dass reine HTTP-Hosts einen falschen HSTS-Header erhalten. Eine fehlerhafte HSTS-Richtlinie kann bei einigen Domains zu Zugriffsproblemen führen und sollte daher mit Bedacht eingesetzt werden.
Wenn CSP im aktuellen securityHeaders-Verhalten aktiviert ist, wird der `default-src 'self';`-Header als fester Wert ausgegeben. Es gibt keinen zusätzlichen benutzerdefinierten Direktiven-Editor innerhalb der aktiven Fähigkeiten dieser Seite. Für detailliertere CSP-Anforderungen sollte eine benutzerdefinierte Header-Regel oder eine anwendungsseitige Konfiguration geplant werden.
securityHeaders funktioniert nicht wie eine WAAP-Signatur-Scoring-Regel. Es wird als Antwort-Header-Härtungsregel behandelt, die immer angewendet wird. Daher ist es nicht an ein Angriffs-Score oder ein Schwellenwert-Ergebnis gebunden.
Die Header Server, X-Powered-By, X-AspNet-Version und X-AspNetMvc-Version können entfernt werden. Das Entfernen dieser Header ändert das Anwendungsverhalten nicht; es reduziert lediglich die externe Sichtbarkeit von Technologieinformationen. In Legacy-Anwendungen kann dieser einfache Schritt Informationslecks spürbar reduzieren.
CSP- und Frame-Richtlinien können einige Anwendungskomponenten beeinflussen. Seiten, die Inline-Skripte verwenden oder Inhalte von externen Quellen laden, sollten insbesondere zuerst in einer Testumgebung validiert werden. Der regelbasierte Ansatz von TR7 macht es unkompliziert, eine strenge Richtlinie zunächst auf einem begrenzten Pfad oder einer Domain zu erproben, bevor sie breit ausgerollt wird.
E-Commerce-Teams können CSP, HSTS und Server-Fingerprint-Bereinigung auf vService-Ebene auf Checkout-Seiten aktivieren. Dieses Setup erzeugt nachweisbare technische Belege für PCI DSS 4.0 v4.0.1 Client-seitige Sicherheitskontrollen.
Banking-Portale können X-Frame-Options SAMEORIGIN und Permission-Policy verwenden, um nicht autorisierten iFrame-Einbettungen und unnötigen Browser-API-Zugriffen entgegenzuwirken. Die client-seitige Angriffsfläche auf Login- und Transaktionsseiten wird reduziert.
Anwendungen des öffentlichen Sektors können Referrer-Policy auf Seiten anwenden, die sensible URL-Informationen enthalten. Dies reduziert das Risiko, dass URL-Fragmente, die mit Bürger-Sessions oder Transaktionskontexten verknüpft sind, an externe Seiten weitergegeben werden.
In älteren .NET- oder ähnlichen Anwendungen können Server, X-Powered-By und Framework-Versions-Header nach außen durchsickern. TR7 entfernt diese Header und erschwert es Angreifern, ein Technologie-Inventar zu erstellen.
SaaS-Anbieter können für jeden Tenant-vService unterschiedliche securityHeaders-Kombinationen anwenden. B2B-Tenants können eine permissivere Richtlinie verwenden, wo Compliance-Anforderungen dies erlauben; B2C-Abläufe können einen strengeren Header-Satz nutzen.
CSP, HSTS, Clickjacking-Schutz und Server-Fingerprint-Bereinigung — über eine einzige Richtlinie, ohne Änderung am Anwendungscode. Lassen Sie uns einen Live-Setup auf Ihren eigenen Services durchführen.