Ein Online-Shop kann tadellos funktionieren, schnell laden und trotzdem bei jeder Bestellung heimlich Kreditkartendaten an Kriminelle ausliefern. Genau das leistet Web-Skimming, oft nach der bekanntesten Angreifergruppe Magecart benannt: Angreifer schleusen wenige Zeilen JavaScript in die Checkout-Seite ein, die im Browser des Kunden die Zahlungsfelder mitlesen und an eine fremde Domain senden. Das Tückische ist der Ort des Angriffs. Der Schadcode läuft clientseitig im Browser, nicht auf dem Server -- er umgeht damit klassische serverseitige Malware-Scans und löscht seine Spuren oft nach dem Diebstahl selbst. Das Ausnutzen von Schwachstellen war zuletzt in 20 Prozent der Sicherheitsverletzungen der erste Zugangsweg, ein Anstieg um 34 Prozent gegenüber dem Vorjahr (Verizon DBIR, 2025). Weil ein solcher Skimmer über Monate aktiv bleiben kann -- eine Datenpanne wird im Schnitt erst nach 241 Tagen erkannt und eingedämmt (IBM Cost of a Data Breach, 2025) -- hat der Payment-Card-Standard reagiert: Seit dem 31. März 2025 sind ein Skript-Inventar und eine Tamper-Erkennung am Checkout Pflicht (PCI Security Standards Council, 2025). Dieser Beitrag zeigt, wie Sie mit Third-Party-Skript-Inventar, Subresource Integrity, einer restriktiven Content-Security-Policy und kontinuierlichem Monitoring der Checkout-Skripte Web-Skimming stoppen -- und warum das etwas anderes ist als serverseitiges Malware-Scanning.
Das Wichtigste in Kürze
- Web-Skimming läuft clientseitig im Browser: Der Skimmer liest die Zahlungsfelder direkt im Checkout aus und sendet sie an eine fremde Domain -- serverseitige Malware-Scans sehen davon nichts.
- Ein vollständiges Inventar aller Third-Party-Skripte auf der Zahlungsseite ist die Grundlage: Nur was man kennt, lässt sich absichern (PCI DSS 4.0, Anforderung 6.4.3).
- Subresource Integrity bindet externe Skripte an einen Hash, eine Content-Security-Policy erlaubt nur freigegebene Quellen -- manipulierte oder fremde Skripte blockiert der Browser.
- Tamper-Detection prüft mindestens alle sieben Tage, ob Skripte oder HTTP-Header der Zahlungsseite unautorisiert verändert wurden (PCI DSS 4.0, Anforderung 11.6.1).
- Kontinuierliches Change- und Integritäts-Monitoring verwandelt eine über Monate unbemerkte Manipulation in einen Alarm binnen Minuten.
Wie Web-Skimming am Checkout funktioniert
Web-Skimming beginnt selten an der Zahlungsseite selbst, sondern an einer Schwachstelle davor. Typische Einfallstore sind ein verwundbares Plugin, ein gekapertes Redaktions- oder Adminkonto oder ein manipuliertes Fremdskript, das über ein Content-Delivery-Netzwerk eingebunden ist. 88 Prozent der grundlegenden Angriffe auf Web-Anwendungen nutzten gestohlene Zugangsdaten (Verizon DBIR, 2025) -- ein einziger geleakter Admin-Zugang genügt, um Schadcode in das Template der Checkout-Seite zu schreiben. Ist der Skimmer erst platziert, läuft er im Browser jedes Kunden mit: Er hängt sich an die Eingabefelder für Kartennummer, Ablaufdatum und Prüfziffer, liest die Werte bei der Eingabe oder beim Absenden aus und schickt sie per unauffälligem Bild-Request oder Fetch an einen Server der Angreifer.
Moderne Skimmer sind auf Tarnung optimiert. Viele laden ihren Schadcode nur auf der Zahlungsseite und nur für echte Besucher, nicht für Administratoren oder bekannte Analyse-Werkzeuge. Andere verschleiern den Code mehrfach, tarnen die Abfluss-Domain als scheinbar harmlose Analyse- oder Schrift-Adresse und entfernen sich nach erfolgreichem Diebstahl wieder aus der Seite. Genau diese Selbstlöschung macht die nachträgliche Spurensuche schwer -- und ist der Grund, warum eine Momentaufnahme selten genügt und nur eine kontinuierliche Beobachtung der ausgelieferten Seite verlässlich anschlägt.
Der Skimmer löscht seine Spuren
Warum serverseitige Malware-Scans Skimmer übersehen
Serverseitiges Malware-Scanning ist wichtig und findet Backdoors, Web-Shells und veränderte PHP-Dateien -- doch gegen Web-Skimming ist es strukturell im Nachteil. Ein Scanner auf dem Server prüft Dateien und Datenbank auf dem Host. Ein Skimmer entsteht aber oft erst im Browser: Er kann über ein extern eingebundenes Skript nachgeladen werden, das auf dem eigenen Server gar nicht liegt, oder sich nur unter bestimmten Bedingungen aktivieren, die ein Server-Scan kaum auslöst. Deshalb trennen wir beide Ebenen bewusst. Wie ein gründlicher serverseitiger Malware-Scan aufgebaut ist, behandeln wir an anderer Stelle; hier geht es um die clientseitige Verteidigung, die genau dort ansetzt, wo der Skimmer arbeitet. Der Payment-Card-Standard zieht dieselbe Grenze und verlangt in Anforderung 11.6.1 ausdrücklich eine Erkennung von Veränderungen an den im Browser ausgelieferten Skripten und HTTP-Headern (PCI Security Standards Council, 2025).
| Aspekt | Serverseitiges Malware-Scanning | Clientseitige Skript-Integrität |
|---|---|---|
| Prüft | Dateien und Datenbank auf dem Server | Im Browser ausgelieferte Skripte und Header |
| Findet | Backdoors, Web-Shells, injizierte PHP-Dateien | Skimmer, manipulierte und fremde Skripte |
| Externe Skripte | Nicht erfasst (liegen nicht am Server) | Über SRI und CSP abgesichert |
| Bedingter Schadcode | Wird oft nicht ausgelöst | Wird beim echten Seitenaufruf sichtbar |
| PCI DSS 4.0 | Ergänzende Basis-Hygiene | Anforderungen 6.4.3 und 11.6.1 |
| Rolle | Schutz des Servers | Schutz der Zahlungsseite |
Zwei Schichten, nicht zwei Alternativen
Third-Party-Skript-Inventar: die Grundlage nach 6.4.3
Man kann nur schützen, was man kennt. Deshalb steht am Anfang jeder Checkout-Absicherung ein vollständiges Inventar aller Skripte, die auf der Zahlungsseite und den Seiten davor geladen werden. Anforderung 6.4.3 des Payment-Card-Standards verlangt genau das: Jedes Skript auf der Zahlungsseite muss autorisiert sein, in seiner Integrität abgesichert werden und eine dokumentierte Begründung für seinen Einsatz besitzen (PCI Security Standards Council, 2025). In der Praxis überrascht dieses Inventar regelmässig -- ein typischer Shop lädt neben eigenen Skripten Zahlungs-Widgets, Chat-Tools, Consent-Manager und Analyse-Bibliotheken, oft mit weiteren, nachgeladenen Abhängigkeiten, die niemand mehr bewusst eingebunden hat.
- Alle Skript-Quellen erfassen: eigene und externe, statisch eingebunden und dynamisch nachgeladen, inklusive der Skripte in Zahlungs- und Consent-Widgets.
- Jede Quelle einer Verantwortung zuordnen: Wer betreibt sie, welchem Zweck dient sie, ist sie für den Checkout wirklich nötig?
- Nicht benötigte Skripte entfernen: Was auf der Zahlungsseite nicht gebraucht wird, gehört dort nicht hin -- die kleinste Angriffsfläche ist die beste.
- Verbleibende Skripte absichern: per Subresource Integrity an einen Hash binden und in der Content-Security-Policy explizit freigeben.
- Das Inventar versionieren: Bei jedem Deploy und jeder Änderung an Fremdskripten wird die Liste aktualisiert und neu freigegeben.
Dieses Inventar ist kein einmaliges Dokument, sondern lebt mit dem Shop. Jedes Update kann neue Skripte einführen, jedes Fremd-Widget kann seine eingebundenen Dateien ohne Vorwarnung ändern. Wir pflegen das Skript-Inventar deshalb als festen Bestandteil der laufenden Shopware-Wartung und verbinden es mit einem regelmässigen Plugin- und Skript-Audit, damit die Liste der freigegebenen Skripte und die tatsächlich ausgelieferten Skripte nicht auseinanderlaufen.
Subresource Integrity und Content-Security-Policy
Sind die Skripte inventarisiert, folgen die beiden zentralen Browser-Mechanismen. Subresource Integrity (SRI) hängt an jedes extern eingebundene Skript einen kryptografischen Hash. Der Browser führt das Skript nur aus, wenn sein Inhalt exakt zu diesem Hash passt -- verändert ein Angreifer die Datei auch nur um ein Zeichen, verweigert der Browser die Ausführung. Die Content-Security-Policy (CSP) legt darüber hinaus fest, aus welchen Quellen Skripte überhaupt geladen werden dürfen und wohin die Seite Daten senden darf. Ein Skimmer, der Kartendaten an eine fremde Domain schicken will, scheitert an einer restriktiven connect-src-Regel, selbst wenn es ihm gelungen ist, Code einzuschleusen.
<!-- Externes Skript an einen Integritäts-Hash binden (SRI) -->
<script src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8Kuxy9rx7HNQlGYl1kPzQho1wxYawnHQ8w"
crossorigin="anonymous"></script>
# Restriktive Content-Security-Policy als HTTP-Header
Content-Security-Policy:
default-src 'self';
script-src 'self' https://cdn.example.com 'nonce-Rk9PMjAyNg';
connect-src 'self' https://pay.example.com;
object-src 'none';
base-uri 'self';
report-uri /csp-reportSubresource Integrity
Bindet jedes externe Skript an einen Hash. Weicht der Inhalt ab, blockiert der Browser die Ausführung -- so wird eine manipulierte CDN-Datei wirkungslos.
Content-Security-Policy
Erlaubt Skripte nur aus freigegebenen Quellen und begrenzt die Ziel-Domains für ausgehende Daten. Eingeschleuster Code kann so nichts nach aussen senden.
Beide Mechanismen haben Grenzen, die man kennen muss. SRI wirkt zuverlässig bei statisch versionierten Dateien, weniger bei Skripten, die sich bei jedem Abruf legitim ändern -- für diese braucht es eine CSP mit nonce oder hash und einen vertraglich abgesicherten Anbieter. Eine CSP wiederum entfaltet ihre Wirkung nur, wenn sie restriktiv gehalten und konsequent gepflegt wird; eine mit unsafe-inline aufgeweichte Richtlinie schützt kaum noch. Deshalb gehören CSP-Pflege und das Einspielen von Sicherheitsupdates zusammen, ergänzt um einen vorgelagerten WAF- und Bot-Schutz, der bekannte Angriffsmuster abfängt, bevor sie die Anwendung erreichen. Täglich werden rund 78 neue Schwachstellen bekannt, ein Plus von 14 Prozent gegenüber dem Vorjahr (BSI Lagebericht, 2024) -- die Regeln von heute passen selten unverändert auf die Bedrohungen von morgen.
Tamper-Detection nach PCI DSS 4.0
Inventar, SRI und CSP verringern die Wahrscheinlichkeit einer erfolgreichen Manipulation, schließen sie aber nicht vollständig aus. Deshalb verlangt Anforderung 11.6.1 zusätzlich eine aktive Überwachung: einen Mechanismus, der unautorisierte Veränderungen an den Skripten und den sicherheitsrelevanten HTTP-Headern der Zahlungsseite erkennt und mindestens alle sieben Tage prüft (PCI Security Standards Council, 2025). Praktisch bedeutet das, den tatsächlich im Browser ausgelieferten Zustand der Checkout-Seite regelmässig gegen einen freigegebenen Referenzzustand abzugleichen -- die Skript-Liste, die Inhalts-Hashes und die Header. Jede Abweichung löst einen Alarm aus.
Was Tamper-Detection prüft
Der Schwellenwert von sieben Tagen ist das Minimum, nicht das Ziel. Bei einem Angriffsmuster, in dem 70 Prozent der Ausnutzungsversuche zu einem vollständigen Eindringen führen und 68 Prozent in ausgeführtem Schadcode enden (ENISA Threat Landscape, 2025), sind sieben Tage eine lange Zeit, in der ein Skimmer ungestört Karten abgreifen kann. Sinnvoll ist ein deutlich engeres Intervall bis hin zur kontinuierlichen Prüfung -- und ein vorbereiteter Notfallplan für den Ernstfall, damit auf einen Alarm sofort strukturierte Schritte folgen statt Hektik. Das Ausnutzen von Schwachstellen war zuletzt mit 21,3 Prozent der zweithäufigste Erstzugang in europäischen Vorfällen (ENISA Threat Landscape, 2025).
Vier Schutzschichten am Checkout
1. Skript-Inventar
Vollständige, versionierte Liste aller Skripte auf der Zahlungsseite mit Zweck und Verantwortung -- die Grundlage nach Anforderung 6.4.3.
2. Subresource Integrity
Jedes externe Skript an einen Hash gebunden. Veränderte Dateien werden vom Browser nicht ausgeführt.
3. Content-Security-Policy
Nur freigegebene Skript-Quellen, streng begrenzte Ziel-Domains für ausgehende Daten. Eingeschleuster Code läuft ins Leere.
4. Tamper-Detection
Kontinuierlicher Abgleich der ausgelieferten Seite gegen den Referenzzustand mit Alarm bei jeder Abweichung -- Anforderung 11.6.1.
Keine dieser Schichten ist für sich allein ausreichend, doch gemeinsam bilden sie eine gestaffelte Verteidigung, die den PCI-Anforderungen entspricht. Besonders wichtig ist das für kleinere Händler: 80 Prozent der angezeigten Angriffe richteten sich gegen kleine und mittlere Unternehmen (BSI Lagebericht, 2024), denen oft die Ressourcen für eine dauerhafte Überwachung fehlen. Checkout-Sicherheit ist damit kein einmaliges Projekt, sondern eine laufende Aufgabe -- genau wie die Barrierefreiheit des Shops nach BFSG oder die Zustellbarkeit von Shop-Mails über DMARC Teil einer kontinuierlichen Wartung sind.
Kontinuierliches Change- und Integritäts-Monitoring
Der wirksamste Hebel gegen Web-Skimming ist Zeit -- genauer: sie den Angreifern zu nehmen. Ein Skimmer richtet umso mehr Schaden an, je länger er unbemerkt bleibt, und die Ausgangslage ist unbequem: Nur rund 54 Prozent der kritischen Schwachstellen in exponierten Systemen wurden vollständig behoben, im Median erst nach 32 Tagen (Verizon DBIR, 2025). Ein wöchentlicher oder gar manueller Blick reicht dagegen selten aus. Kontinuierliches Change- und Integritäts-Monitoring beobachtet die Checkout-Skripte, die Inhalts-Hashes und die HTTP-Header laufend und schlägt bei jeder unautorisierten Änderung Alarm -- lange bevor ein Skimmer eine nennenswerte Zahl an Karten abgreifen kann.
Web-Skimming lebt von unbeobachteter Zeit. Wer die Checkout-Skripte kontinuierlich überwacht, verwandelt einen monatelangen Datenabfluss in einen Alarm binnen Minuten.
Genau hier setzt unser kontinuierliches Change- und Integritäts-Monitoring an: Wir erstellen das Skript-Inventar, richten Subresource Integrity und eine restriktive Content-Security-Policy ein, definieren den Referenzzustand der Zahlungsseite und überwachen ihn laufend gegen unautorisierte Veränderungen -- gemeinsam mit einem strukturierten Patch- und CVE-Management, das die häufigsten Einfallstore schließt. 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, Ranking-Verlust, mögliche Bussgelder und Vertrauensschaden bleiben. Dem gegenüber steht ein Bruchteil dieser Summe für laufende Überwachung. Als Teil eines SLA-Wartungsvertrags und unserer gesamten Managed-Wartungsleistungen wird die Checkout-Absicherung so von einem Compliance-Pflichtpunkt zu einem ruhigen, nachvollziehbaren Prozess im Hintergrund.