Ein Online-Shop kann jede Bestellung sauber abwickeln und trotzdem gegen eine verbindliche Sicherheitsvorgabe verstoßen, ohne dass es jemandem auffällt. Seit dem 31. März 2025 sind zwei zuvor als Empfehlung geführte Anforderungen des Payment-Card-Standards verpflichtend: Anforderung 6.4.3 verlangt ein Inventar aller Skripte auf der Zahlungsseite, jedes autorisiert und in seiner Integrität abgesichert, und Anforderung 11.6.1 verlangt eine mindestens wöchentliche Erkennung unautorisierter Änderungen an diesen Skripten und den HTTP-Headern der Seite (PCI Security Standards Council, PCI DSS 4.0.1). Betroffen ist nicht der exotische Sonderfall, sondern der Alltag: Analyse-Tags, Tag-Manager, Chat-Widgets und Consent-Skripte laufen im Browser des Kunden genau dort, wo Kartendaten eingegeben werden. Weil das Ausnutzen von Schwachstellen zuletzt in 20 Prozent der Datenpannen der erste Zugangsweg war, ein Anstieg um 34 Prozent gegenüber dem Vorjahr (Verizon DBIR 2025), und sich die Beteiligung von Drittparteien auf 30 Prozent verdoppelt hat (Verizon DBIR 2025), rückt die Kette aus fremden Skripten in den Fokus. Anders als der Beitrag zu Web-Skimming am Checkout, der die Angriffstechnik beschreibt, geht es hier um die konkrete Compliance-Pflicht und ihren Nachweis: was PCI DSS 4.0.1 fordert, wie ein sauberes Inventar samt CSP, Subresource Integrity und wöchentlichem Monitoring der Zahlungsseite aussieht -- und warum das eine laufende Aufgabe bleibt.
Was PCI DSS 4.0.1 seit dem 31. März 2025 fordert
PCI DSS ist der Payment Card Industry Data Security Standard -- das Regelwerk, das jeder Betreiber einhalten muss, der Kartenzahlungen entgegennimmt. Die aktuelle Fassung 4.0.1 ist eine begrenzte Überarbeitung der Version 4.0 und seit ihrem Erscheinen die maßgebliche Grundlage. Die beiden hier entscheidenden Anforderungen waren in Version 4.0 zunächst als künftige Best Practice ausgewiesen und wurden mit Ablauf der Übergangsfrist am 31. März 2025 verbindlich (PCI Security Standards Council, PCI DSS 4.0.1). Seither sind sie prüfbar: Ein Assessor darf ihre Umsetzung verlangen, und ein fehlendes Skript-Inventar oder eine fehlende Tamper-Detection ist kein offener Punkt mehr, sondern eine Abweichung. Der Hintergrund ist eine messbare Verschiebung der Angriffe in den Browser. Gestohlene Zugangsdaten und ausgenutzte Schwachstellen führen die Erstzugänge an -- 88 Prozent der grundlegenden Angriffe auf Web-Anwendungen nutzten gestohlene Zugangsdaten (Verizon DBIR 2025), und der menschliche Faktor war an 60 Prozent der Datenpannen beteiligt (Verizon DBIR 2025). Ein einziger übernommener Zugang genügt, um ein fremdes Skript in die Zahlungsseite zu schreiben.
Von der Empfehlung zur Pflicht
Welche Skripte auf der Zahlungsseite betroffen sind
Die Frage, welche Skripte überhaupt betroffen sind, überrascht in der Praxis regelmäßig. Anforderung 6.4.3 gilt für jedes Skript, das im Browser auf der Zahlungsseite geladen wird -- eigene wie fremde, statisch eingebunden wie dynamisch nachgeladen. Ein typischer Shop bindet weit mehr davon ein, als bewusst dokumentiert ist: Neben dem eigenen Code laufen Analyse- und Marketing-Tags, ein Tag-Manager, ein Chat- oder Support-Widget, ein Consent-Banner und die Skripte des Zahlungsdienstleisters. Viele davon laden ihrerseits weitere Dateien nach, sodass die tatsächlich ausgelieferte Skript-Kette länger ist als die Liste im Quelltext. Genau diese nachgeladenen Abhängigkeiten sind das Risiko: Ändert ein Anbieter eine ausgelieferte Datei, läuft die Änderung ungeprüft im Checkout mit.
Analyse- und Marketing-Tags
Zähl-Pixel, Conversion-Tags und Analyse-Bibliotheken laufen oft auch auf der Zahlungsseite mit. Jedes davon ist ein autorisierungs- und integritätspflichtiges Skript nach Anforderung 6.4.3.
Tag-Manager
Ein Tag-Manager lädt weitere Skripte dynamisch nach und kann seinen Inhalt jederzeit ändern -- ohne Deploy im Shop. Das macht ihn wirkmächtig und zugleich zum kritischen Element im Inventar.
Chat- und Support-Widgets
Support-Chats binden externe Bibliotheken ein, die auf jeder Seite mitlaufen. Auf der Zahlungsseite gehören sie inventarisiert, begründet und in ihrer Integrität überwacht -- oder von dort entfernt.
Consent- und Zahlungs-SDKs
Consent-Manager und die SDKs der Zahlungsdienstleister laden Ressourcen dynamisch und wechseln mitunter ihre Quellen. Auch sie fallen unter das Inventar und die Tamper-Detection.
Der erste Ertrag eines Inventars ist deshalb oft Reduktion. Ein Skript, das auf der Zahlungsseite keinen Zweck erfüllt, gehört dort nicht hin -- die kleinste Skript-Kette ist die am leichtesten zu überwachende. Ein regelmäßiges Plugin- und Skript-Audit hält diese Kette schlank und sorgt dafür, dass die Liste der freigegebenen Skripte und die tatsächlich ausgelieferten Skripte nicht auseinanderlaufen.
Anforderung 6.4.3: das Skript-Inventar mit Autorisierung
Man kann nur absichern, was man kennt. Anforderung 6.4.3 macht das zur Regel und verlangt vier Dinge für jedes Skript auf der Zahlungsseite: eine Autorisierung, eine Integritätssicherung, einen Eintrag im Inventar und eine dokumentierte Begründung, warum das Skript dort geladen wird (PCI Security Standards Council). Das Inventar ist damit mehr als eine Liste von Dateinamen -- es ist die Verbindung aus welches Skript, wer hat es freigegeben, wie wird seine Unversehrtheit geprüft und wozu ist es nötig. Erst diese Verbindung macht das Inventar prüffähig.
- Alle Skripte erfassen: eigene und externe, statisch eingebunden und dynamisch nachgeladen, inklusive der Skripte, die Tag-Manager, Consent- und Zahlungs-Widgets ihrerseits laden.
- Jedes Skript autorisieren: festhalten, wer es freigegeben hat und wann -- die Autorisierung ist der Kern der Anforderung, nicht die bloße Existenz der Liste.
- Die Integrität sichern: jedes externe Skript per Subresource Integrity an einen Hash binden und über die Content-Security-Policy nur aus freigegebenen Quellen zulassen.
- Die Begründung dokumentieren: für jedes Skript festhalten, welchem Zweck es auf der Zahlungsseite dient -- was sich nicht begründen lässt, wird entfernt.
- Das Inventar versionieren: bei jedem Deploy und jeder Änderung an einem Fremdskript wird die Liste aktualisiert und neu freigegeben, damit sie den tatsächlichen Zustand abbildet.
Was ein prüffähiges Inventar enthält
Anforderung 11.6.1: wöchentliche Tamper-Detection
Ein Inventar beschreibt den Soll-Zustand. Anforderung 11.6.1 verlangt zusätzlich, den Ist-Zustand laufend dagegen zu prüfen: einen Mechanismus, der unautorisierte Änderungen an den Skripten und den sicherheitsrelevanten HTTP-Headern der Zahlungsseite erkennt und die Verantwortlichen alarmiert -- und der mindestens einmal pro Woche läuft (PCI Security Standards Council). Praktisch heißt das, den tatsächlich im Browser ausgelieferten Zustand der Seite regelmäßig gegen den freigegebenen Referenzzustand abzugleichen: die Liste der geladenen Skripte, die Inhalts-Hashes und die Header wie die Content-Security-Policy. Jede Abweichung -- ein neues Skript, eine geänderte Datei, ein manipulierter Header -- löst einen Alarm aus.
Sieben Tage sind das Minimum, nicht das Ziel
Wichtig ist, was die Tamper-Detection leisten muss und was einzelne Browser-Mechanismen allein nicht abdecken. Das ergänzende Informationsdokument des Standards zur Zahlungsseiten-Sicherheit hält ausdrücklich fest, dass Content-Security-Policy und Subresource Integrity die Anforderung 11.6.1 nicht vollständig erfüllen (PCI Security Standards Council, Payment Page Security and Preventing E-Skimming). Beide sichern die Integrität einzelner Skripte, erkennen aber weder das Löschen eines Skripts noch verhaltensbasierte Manipulation noch Änderungen an den HTTP-Headern zuverlässig. Deshalb kombiniert eine belastbare Erkennung mehrere Verfahren -- etwa die Beobachtung der ausgelieferten Seite im Browser, den Abgleich von Inhalts-Hashes und die Prüfung der Header gegen den Referenzzustand.
CSP und SRI: notwendig, aber nicht ausreichend
Damit ist die häufigste Fehlannahme benannt: dass eine gut gepflegte Content-Security-Policy und Subresource Integrity die neuen Anforderungen bereits abdecken. Beide sind unverzichtbar und tragen den Löwenanteil der Integritätssicherung nach 6.4.3 -- doch für den Nachweis nach 11.6.1 reichen sie nicht. Erschwerend kommt hinzu, dass CSP in der Praxis oft aufgeweicht ist: Nur rund 22 Prozent aller Hosts liefern überhaupt eine Content-Security-Policy aus (HTTP Archive Web Almanac 2025), und über 92 Prozent der Seiten mit CSP erlauben unsafe-inline und heben damit einen zentralen Schutz weitgehend auf (HTTP Archive Web Almanac 2025). Die Wirkung der Mechanismen hängt also nicht nur von ihrer Existenz ab, sondern von ihrer Konfiguration und Pflege.
| Mechanismus | Was er absichert | Grenze für den Nachweis |
|---|---|---|
| Content-Security-Policy | Beschränkt Skript-Quellen und Ziel-Domains für Daten | Erkennt gelöschte Skripte und Verhaltensänderungen nicht |
| Subresource Integrity | Bindet ein externes Skript an einen Inhalts-Hash | Wirkt nur bei statisch versionierten Dateien |
| Webseiten-Monitoring | Beobachtet die ausgelieferte Seite auf neue oder geänderte Skripte | Braucht einen gepflegten Referenzzustand |
| Inventar und Autorisierung | Belegt Zweck und Freigabe jedes Skripts | Ist nur haltbar, wenn es bei jeder Änderung mitgeführt wird |
Wie eine restriktive Content-Security-Policy und ihre Pflege im Detail aussehen, behandelt der Beitrag zu HTTP-Security-Headern mit CSP und HSTS; wie eingeschleuste Skripte am Checkout konkret zu Datenabfluss führen, zeigt der Beitrag zu Web-Skimming am Checkout. Für den PCI-Nachweis kommt beides zusammen: die technische Absicherung durch CSP und SRI und die laufende, protokollierte Überwachung, die eine Abweichung sichtbar und belegbar macht. Diese Doppelung aus Kontrolle und Nachweis teilt PCI DSS 4.0.1 mit anderen Regelwerken -- etwa den NIS2-Pflichten für Online-Shops, bei denen ebenfalls nicht nur die Maßnahme, sondern ihr Beleg zählt.
Wie der Nachweis für PCI DSS 4.0.1 aussieht
Der eigentliche Unterschied dieser Anforderungen zu vielen anderen Sicherheitsmaßnahmen liegt im Wort Nachweis. Es genügt nicht, ein Inventar zu führen und eine Überwachung zu betreiben -- beides muss belegbar sein. Ein Assessor oder eine interne Revision fragt nicht nur, ob eine Tamper-Detection existiert, sondern will sehen, dass sie im geforderten Takt gelaufen ist, welche Skripte freigegeben wurden und wie auf eine Abweichung reagiert wurde. Dieser Nachweis entsteht nicht rückwirkend; er muss laufend anfallen. Deshalb protokollieren wir jede relevante Änderung: die Freigabe eines Skripts, die Anpassung einer CSP-Regel, den Alarm bei einer erkannten Abweichung und die darauf folgende Reaktion. Die Kosten eines Versäumnisses sind real -- eine Datenpanne wird im Schnitt erst nach 241 Tagen erkannt und eingedämmt (IBM Cost of a Data Breach 2025), Zeit, in der ein unbemerktes Fremdskript ungestört mitliest.
- Ein versioniertes Skript-Inventar mit Autorisierung, Integritätsnachweis und Begründung je Skript (Anforderung 6.4.3).
- Ein Protokoll der Prüfläufe, das den mindestens wöchentlichen Takt der Tamper-Detection belegt (Anforderung 11.6.1).
- Eine nachvollziehbare Änderungshistorie der Zahlungsseiten-Skripte und der sicherheitsrelevanten HTTP-Header.
- Ein Alarm- und Reaktionsprotokoll, das zeigt, wie auf eine erkannte Abweichung reagiert wurde und wann sie behoben war.
- Eine dokumentierte Begründung für das gewählte Prüfintervall, falls es vom wöchentlichen Standardtakt abweicht.
Bei den neuen PCI-Anforderungen entscheidet nicht, ob ein Shop seine Skripte im Griff hat, sondern ob er es belegen kann. Wer den Nachweis erst zum Assessment zusammensucht, hat ihn nicht.
Warum das laufende Wartung statt Einmal-Projekt ist
All das erklärt, warum die Erfüllung dieser Anforderungen kein einmaliges Projekt ist. Ein Shop verändert sich ständig: Themes werden aktualisiert, Extensions kommen hinzu, ein Zahlungsdienstleister stellt sein SDK um, ein Tag-Manager lädt ein neues Skript nach. Jede dieser Änderungen kann ein neues Skript in die Zahlungsseite bringen oder ein bestehendes verändern -- und damit das Inventar veralten lassen und einen Alarm der Tamper-Detection auslösen, der bewertet und dokumentiert werden will. Das ergänzende Informationsdokument des Standards beschreibt zudem Angriffsmuster wie den Double-Entry-Betrug, bei dem Kunden über ein vorgeschaltetes falsches Formular dazu gebracht werden, ihre Kartendaten ein zweites Mal einzugeben (PCI Security Standards Council, Payment Page Security and Preventing E-Skimming) -- solche Varianten entstehen genau in den Lücken, die zwischen zwei Einmal-Prüfungen aufgehen.
Deshalb betreiben wir Skript-Inventar, CSP- und SRI-Pflege und die wöchentliche Tamper-Detection als festen Bestandteil der laufenden Sicherheitsupdate-Betreuung und des Monitorings der Zahlungsseite -- eng verzahnt mit dem Patch- und CVE-Management, das die häufigsten Einfallstore schließt, und mit der Shopware-Wartung im laufenden Betrieb. Wo Consent- und Analyse-Skripte im Spiel sind, greift das in die DSGVO-Updates hinein; wo es um die Stabilität der Zahlungsseite unter Last geht, in das Checkout- und Transaktions-Monitoring und den Lasttest für Spitzenlast. Die durchschnittlichen Gesamtkosten einer Datenpanne lagen zuletzt bei 4,44 Millionen US-Dollar weltweit (IBM Cost of a Data Breach 2025); für kleinere Shops fällt der Betrag geringer aus, doch Umsatzausfall, mögliche Sanktionen und Vertrauensschaden bleiben. Als Teil eines SLA-Wartungsvertrags und unserer gesamten Managed-Wartungsleistungen wird aus der PCI-Pflicht ein ruhiger, nachvollziehbarer Prozess mit Nachweis -- statt einer Aufgabe, die erst zum nächsten Assessment auffällt.