PCI DSS 4.0.1: Client-Side-Security-Pflicht 2026

Was PCI DSS 4.0.1 seit dem 31. März 2025 verlangt

PCI DSS 4.0.1 ist die aktuelle Fassung des Payment Card Industry Data Security Standard, einer begrenzten Überarbeitung der Version 4.0. Mit Version 4.0 wurde eine Reihe neuer Anforderungen als sogenannte zukunftsdatierte Best Practices eingeführt - mit einer Übergangsfrist, die am 31. März 2025 endete. Seit diesem Stichtag müssen diese Anforderungen im Rahmen einer PCI-DSS-Bewertung erfüllt werden (PCI Security Standards Council). Zwei davon zielen unmittelbar auf die Client-Side-Security von Bezahlseiten: Requirement 6.4.3 und Requirement 11.6.1.

Betroffen ist praktisch jeder, der Kartendaten über eine Bezahlseite entgegennimmt. Selbst wer die eigentliche Karteneingabe über ein eingebettetes Bezahlfenster eines Zahlungsdienstleisters auslagert, bleibt für die eigene Seite verantwortlich, die dieses Fenster einbindet - denn genau dort entscheidet sich, welche Skripte im Browser laufen. Der PCI Security Standards Council hat den Anwendungsbereich mit Version 4.0.1 ausdrücklich auch auf Händler ausgeweitet, die zuvor mit dem einfachsten Selbstauskunftsbogen ausgekommen sind (PCI Security Standards Council). Der Umfang der Payment-Seiten wird damit für nahezu alle Karten akzeptierenden Shops relevant.

Ein kurzer Blick auf die Zeitachse macht deutlich, warum das Thema jetzt drängt: Version 4.0 des Standards wurde bereits im März 2022 veröffentlicht, die präzisierende Fassung 4.0.1 folgte im Juni 2024 (PCI Security Standards Council). In dieser gesamten Zeit galten 6.4.3 und 11.6.1 als optionale Best Practice - ein bewusst langer Vorlauf, damit Betreiber die Kontrollen ohne Zeitdruck aufbauen konnten. Mit dem 31. März 2025 ist dieser Vorlauf ausgelaufen. Wer die Anforderungen bis dahin nicht umgesetzt hat, holt sie nun unter Prüfungsdruck nach, statt in Ruhe die passende Lösung auszuwählen.

Requirement 6.4.3: Skript-Inventar, Autorisierung und Integrität

Requirement 6.4.3 fordert, dass alle Skripte, die im Browser des Kunden auf der Payment-Seite geladen und ausgeführt werden, aktiv verwaltet werden. Aus einer bislang unsichtbaren, wild gewachsenen Skript-Landschaft wird damit ein kontrollierter, dokumentierter Bestand. Konkret nennt der Standard drei Bedingungen, die für jedes einzelne Skript erfüllt sein müssen (PCI Security Standards Council):

1. Autorisierung: Es gibt eine Methode, mit der bestätigt wird, dass jedes Skript ausdrücklich freigegeben ist. Ein Skript, das niemand freigegeben hat, gehört nicht auf die Bezahlseite.
2. Integrität: Es gibt eine Methode, mit der die Integrität jedes Skripts sichergestellt wird - also der Nachweis, dass die ausgelieferte Datei exakt dem freigegebenen Stand entspricht und nicht heimlich verändert wurde.
3. Inventar mit Begründung: Es wird ein Inventar aller Skripte geführt, in dem für jedes Skript schriftlich begründet ist, warum es notwendig ist (PCI Security Standards Council).

In der Praxis ist genau das die Hürde. Eine moderne Checkout-Seite lädt selten nur ein Skript: Tag-Manager, Analytics, Chat-Widgets, Betrugsprävention, Zahlungs-SDKs und Consent-Tools bringen jeweils eigenen Code mit - und viele davon laden ihrerseits weitere Skripte nach. Diese Ketten sind manuell kaum vollständig zu erfassen und ändern sich laufend. Warum jedes eingebundene Fremdskript ein eigenes Risiko darstellt, vertieft der Leitfaden zu den Risiken von Third-Party-Scripts.

Requirement 11.6.1: Wöchentliche Überwachung von Headern und Skripten

Während 6.4.3 den Bestand ordnet, sorgt Requirement 11.6.1 für die laufende Überwachung. Gefordert ist ein Mechanismus zur Änderungs- und Manipulationserkennung, der das zuständige Personal über unbefugte Modifikationen alarmiert - also über Kompromittierungsindikatoren, Änderungen, Ergänzungen und Löschungen an den sicherheitsrelevanten HTTP-Headern und den Skript-Inhalten der Payment-Seite, so wie sie im Document Object Model (DOM) des Kundenbrowsers ankommen (PCI Security Standards Council). Entscheidend ist die Perspektive: nicht der Zustand auf dem Server zählt, sondern das, was der Browser des Kunden am Ende wirklich lädt und ausführt.

Für die Häufigkeit dieser Prüfung lässt der Standard zwei Wege zu - eine feste Vorgabe und eine risikobasierte Alternative:

Wer keine dokumentierte Risikoanalyse führen möchte, landet damit beim wöchentlichen Mindesttakt. Für eine Bedrohung, die innerhalb von Minuten Kartendaten abgreifen kann, ist eine Woche allerdings ein langes Fenster - viele Betreiber prüfen daher deutlich häufiger. Die Targeted Risk Analysis nach Requirement 12.3.1 verlangt ohnehin, das geschützte Gut, die Bedrohung und die Faktoren zu benennen, die eine Realisierung wahrscheinlicher machen (PCI Security Standards Council); das Ergebnis ist fast immer ein engeres Intervall als sieben Tage.

Warum Client-Side-Angriffe wie Magecart so gefährlich sind

Magecart ist der Sammelbegriff für eine Reihe von Gruppen, die Web-Skimming betreiben. Das Muster ähnelt sich: Angreifer schleusen JavaScript in die Checkout-Seite ein, das die Eingabefelder mitliest und die erbeuteten Kartendaten an einen fremden Server ausleitet - während die Bestellung für den Kunden völlig normal abläuft. Weil nichts abstürzt und keine Fehlermeldung erscheint, bleibt die Manipulation oft lange unentdeckt. Die Dimension ist erheblich: Laut dem Verizon Data Breach Investigations Report 2024 gingen rund 18 % der Datenpannen im Einzelhandel auf Magecart- beziehungsweise digitales Skimming zurück (Verizon DBIR 2024). Im Handel wurden bei den analysierten Vorfällen in etwa 37 % der Fälle Zahlungsdaten und in rund 35 % Zugangsdaten kompromittiert (Verizon DBIR 2024). Insgesamt bestätigte der Bericht 10.626 Datenpannen aus 30.458 untersuchten Sicherheitsvorfällen (Verizon DBIR 2024).

Der Weg des Schadcodes in die Seite führt selten über die Haustür. Häufiger nutzen Angreifer das Vertrauen, das Betreiber ihren eingebundenen Fremdkomponenten entgegenbringen:

Eine kompromittierte Bezahlseite antwortet dem Kunden mit einem sauberen Kaufabschluss und dem Angreifer mit frischen Kartendaten. Ohne kontinuierliche Überwachung des tatsächlich ausgelieferten Codes bemerkt der Betreiber beides zuletzt.

— XICTRAQ Security-Redaktion (Projekterfahrung)

Charakteristisch ist die Verzögerung zwischen Kompromittierung und Entdeckung. Weil ein Skimmer weder Fehlermeldungen noch Ausfälle produziert, verstreichen bis zum Auffallen oft Wochen - und in dieser Zeit fließen bei jeder Bestellung frische Kartendaten ab. Der Fall British Airways verdeutlicht die Größenordnung: Dort war der manipulierte Code über einen Zeitraum von mehreren Wochen aktiv, bevor die Manipulation überhaupt bemerkt wurde. Genau diese Lücke schließt eine engmaschige Überwachung des im Browser ausgelieferten Codes, statt sich auf Zufallsfunde oder Hinweise von außen zu verlassen.

Was OWASP zu Drittanbieter-Skripten sagt

Die OWASP Foundation betrachtet eingebundenes Fremd-JavaScript seit Langem als eigene Risikoklasse. Der Kern des Problems: Ein Drittanbieter-Tag wird mit denselben Rechten ausgeführt wie der eigene Seitencode. Es kann das DOM lesen, auf Cookies zugreifen und Formulareingaben erfassen - also genau die Daten, die auf einer Bezahlseite anfallen (OWASP Foundation). Das Vertrauen in einen externen Anbieter ist damit zugleich ein Vertrauen in dessen Sicherheit.

OWASP unterscheidet drei grundlegende Risiken beim Einsatz von Drittanbieter-Skripten (OWASP Foundation):

• Kontrollverlust: Änderungen des Anbieters werden sofort und ohne Freigabe ausgeliefert - der Betreiber prüft den neuen Code in der Regel nicht, bevor er im Browser seiner Kunden läuft.
• Ausführung beliebigen Codes: Nicht überprüftes Skript wird auf der Client-Seite ausgeführt und kann nach einer Server-Kompromittierung beim Anbieter selbst zum Träger von Schadcode werden.
• Informationsabfluss: Der Drittanbieter erhält HTTP-Header, Referrer, Cookies und DOM-Daten und kann daraus Nutzerprofile bilden.

Als technische Gegenmaßnahme empfiehlt OWASP unter anderem Subresource Integrity (SRI): Ein hinterlegter kryptografischer Hash sorgt dafür, dass ausschließlich der überprüfte Code ausgeführt wird - allerdings setzt das die CORS-Unterstützung des Anbieters voraus und muss laufend überwacht werden, weil jede legitime Aktualisierung den Hash verändert (OWASP Foundation). SRI, eine Content-Security-Policy und die kontinuierliche Skript-Überwachung greifen ineinander. Wie sich Client-Side-Risiken in die aktuelle Bedrohungslage einordnen, zeigt die Übersicht zu den OWASP Top 10 der Web-Risiken 2025.

Script-Integrity-Monitoring: 6.4.3 und 11.6.1 technisch erfüllen

Genau an dieser Stelle setzt das Script-Integrity-Monitoring an. Es bildet für jedes überwachte Dritt-Skript eine SHA-256-Baseline, ruft die Dateien in kurzem Takt erneut ab und schlägt an, sobald sich der Inhalt vom freigegebenen Stand entfernt. Parallel überwacht es die sicherheitsrelevanten HTTP-Header der Seite. Damit übersetzt es die abstrakten Anforderungen 6.4.3 und 11.6.1 in konkrete, nachweisbare Kontrollen.

Im Zusammenspiel mit dem Security-Scan, der fehlende Schutz-Header und veraltete Komponenten aufdeckt, entsteht eine durchgängige Absicherung der Client-Seite. Wer zusätzlich das Verhalten von Marketing- und Consent-Tags im Blick behalten will, findet im Leitfaden zum Überwachen von Consent-Tag-Drift einen datenschutznahen Anwendungsfall derselben Idee.

So setzen Sie 6.4.3 und 11.6.1 praktisch um

Der Weg von der Anforderung zum belastbaren Nachweis lässt sich in sechs Schritten strukturieren. Sie führen von der Bestandsaufnahme über die laufende Überwachung bis zur Dokumentation, die ein Qualified Security Assessor (QSA) im Audit sehen möchte:

1. Payment-Seiten und Skripte inventarisieren: Erfassen Sie jede Seite, auf der Kartendaten eingegeben werden, und alle darauf im Browser geladenen Skripte - auch nachgeladene.
2. Autorisierung und Begründung dokumentieren: Halten Sie für jedes Skript fest, wer es freigegeben hat und warum es notwendig ist. Das erfüllt den Inventar- und Begründungsteil von Requirement 6.4.3.
3. Integritäts-Baseline festlegen: Hinterlegen Sie je Skript einen SHA-256-Fingerabdruck als Referenz für den freigegebenen Stand.
4. Überwachungstakt bestimmen: Legen Sie fest, ob Sie den Standardtakt von sieben Tagen nutzen oder eine engere Frequenz per Targeted Risk Analysis nach Requirement 12.3.1 begründen.
5. Header- und Skript-Drift kontinuierlich überwachen: Richten Sie die automatische Prüfung samt Alarmierung ein, damit unbefugte Änderungen erkannt und gemeldet werden - das Herzstück von 11.6.1.
6. Nachweise vorhalten: Bewahren Sie Inventar, Baselines und Änderungshistorie auf. Diese Protokolle sind der Beleg gegenüber dem QSA.

Client-Side-Security ist dabei ein Baustein einer breiteren Härtung. Auch die Absicherung der Markenkommunikation zahlt darauf ein - etwa mit einem verifizierten Logo in der E-Mail, wie es der Beitrag zu BIMI und dem VMC-Markenzertifikat beschreibt. Und wer digitale Produkte herstellt, sollte die parallele CRA-Schwachstellen-Meldepflicht mitdenken. Für die datenschutzrechtliche Seite eines Vorfalls lässt sich die Überwachung mit der DSGVO-Compliance verzahnen.

Beginnen Sie mit dem Skript-Inventar und der Baseline - das ist die Grundlage, auf der beide Requirements aufsetzen. Die Registrierung dauert wenige Minuten, eine Demo zeigt den gesamten Funktionsumfang im Zusammenhang, und die Preisübersicht ordnet die Pläne ein.