Änderungen im Checkout überwachen: was Sie prüfen und wann

Änderungen im Checkout zu überwachen heißt, rechtzeitig zu erfahren, wann etwas auf der Zahlungsseite anders funktioniert, als der Shop es freigegeben hat. Dazu gehören die Dateien auf dem Server, die Skripte, die die Seite lädt, die Sicherheits-Header und vor allem das, was auf dem Bildschirm des Käufers erscheint. Jede Ebene braucht eine andere Methode, und keine Methode sieht alle vier.

Warum die Zahlungsseite überwachen und nicht nur die Website

Der Checkout ist die einzige Seite, auf der ein Angriff sofort zu Geld wird. Ein Code, der Kartendaten kopiert oder den QR-Code von Pix (dem Sofortzahlungssystem der brasilianischen Zentralbank) tauscht, muss nur dort funktionieren und ist deshalb auf dem Rest der Website meist ausgeschaltet. Im September 2026 sahen brasilianische Shops, die von einem solchen Code betroffen waren, zuerst ein geschäftliches Symptom (mehr Kaufabbrüche bei Pix), noch vor jedem technischen Alarm.

Die Zahlungsseite zu überwachen ist auch Pflicht. Seit dem 31. März 2025 verlangt die Anforderung 11.6.1 des PCI DSS einen Mechanismus, der unautorisierte Änderungen am Inhalt der Seite und an den Sicherheits-Headern erkennt, mit mindestens wöchentlicher Prüfung oder in der Häufigkeit, die eine eigene Risikoanalyse des Unternehmens festlegt.

Was Sie überwachen sollten: die vier Ebenen

1. Dateien auf dem Server

Die Dateien der Plattform, des Themes und der Plugins. Eine Änderung außerhalb einer geplanten Veröffentlichung ist das klassische Anzeichen eines Einbruchs.

Was diese Ebene nicht sieht: Code, der von einer externen Adresse kommt und nur im Browser existiert.

2. Von der Seite geladene Skripte

Die Liste von allem, was die Zahlungsseite lädt: eigene Dateien, Analysewerkzeuge, Chat, Werbepixel, Skripte des Zahlungsanbieters. Das ist das Inventar, das Anforderung 6.4.3 des PCI DSS verlangt, mit Verantwortlichem, Grund und Integritätssicherung für jeden Eintrag.

Was diese Ebene nicht sieht: ein bereits freigegebenes Skript, das sein Verhalten ändert, ohne seinen Namen zu ändern, oder eine Erweiterung im Browser des Kunden.

3. Sicherheits-Header

Die Anweisungen, die der Server zusammen mit der Seite an den Browser schickt, etwa die Richtlinie, die festlegt, von wo Skripte geladen und wohin Daten gesendet werden dürfen. Lockert jemand diese Richtlinie, steht die Tür offen, ohne dass sich eine Datei ändert.

Was diese Ebene nicht sieht: einen Angriff über einen bereits freigegebenen Dienst. Im Juni 2026 beschrieben Forscher einen Code zum Diebstahl von Kartendaten, der einen bekannten Zahlungsdienst als Stützpunkt nutzte, gerade um Richtlinien zu umgehen, die diesem Dienst vertrauten.

4. Was der Bildschirm des Kunden zeigt

Der QR-Code von Pix, der Text des Pix Copia e Cola (der Zahlungscode als Text, den der Kunde kopiert und in die Banking-App einfügt), die linha digitável (die Nummer) des Boletos (des brasilianischen Bankzahlscheins), die Wallet-Adresse, das Formular für Kreditkarte und Debitkarte und das Ziel, an das dieses Formular die Daten sendet. Hier geschieht der Betrug, und hier zeigt er sich vollständig.

Was diese Ebene verlangt: das, was auf dem Bildschirm steht, mit dem zu vergleichen, was der Shop ausgestellt hat, und nicht nur festzuhalten, dass sich etwas geändert hat.

Wie oft

Es gibt keine einheitliche Häufigkeit. Die Faustregel lautet: eine pro Ebene festlegen.

• Dateien auf dem Server: bei jeder Veröffentlichung und täglich, mit sofortigem Alarm bei Änderungen außerhalb einer Veröffentlichung.
• Skripte und Header: kontinuierlich, mit mindestens wöchentlicher Prüfung durch einen Menschen, dem Minimum von 11.6.1.
• Bildschirm des Kunden: bei jedem Laden der Zahlungsseite. Ein QR-Code, der am Dienstag um 10:00 Uhr getauscht wurde, hat um 10:01 Uhr schon Geld empfangen.

Methoden und was jede erkennt

• Dateiüberwachung auf dem Server. Gut bei Einbrüchen, die den Code des Shops verändern. Blind für das, was im Browser zusammengesetzt wird.
• Externer Scan per Bot. Ein Bot öffnet regelmäßig den Checkout und protokolliert, was die Seite lädt. Das hilft beim Aufbau des Inventars, aber er sieht nur seine eigene Sitzung, und Schadcode kann sich gegenüber Besuchern, die automatisiert wirken, anders verhalten.
• Browserberichte zur Sicherheitsrichtlinie. Der Browser des Kunden meldet, wenn etwas von einer nicht erlaubten Quelle laden wollte. Das zeigt blockierte Versuche, nicht das, was über eine freigegebene Adresse durchkam.
• Überwachungsskript auf der Seite selbst. Es läuft im Browser des echten Kunden und sieht, was die Seite tatsächlich geladen und nach dem Öffnen verändert hat.
• Prüfung der Zahlungsdaten. Ein Schritt weiter: Sie erkennt nicht nur, dass sich der QR-Code geändert hat, sondern vergleicht ihn mit dem QR-Code, den der Shop ausgestellt hat, und blockiert, wenn er nicht übereinstimmt.

Die ersten drei Methoden sagen „etwas hat sich geändert“. Nur die letzte sagt „der Kunde ist dabei, die falsche Person zu bezahlen“.

So richten Sie Alarme ein, auf die jemand reagiert

1. Legen Sie fest, was freigegeben ist. Ohne eine Liste der erwarteten Skripte und Ziele ist jeder Alarm nur Rauschen.
2. Trennen Sie Dringendes von Routine. Ein neues Skript auf der Zahlungsseite und ein abweichender QR-Code sind dringend. Ein Versionswechsel bei einem Analysewerkzeug ist Routine für die Prüfung im Wochenverlauf.
3. Schicken Sie Dringendes an jemanden, der handeln kann. Einen Kanal mit Bereitschaftsdienst, kein E-Mail-Postfach.
4. Verbinden Sie technische und geschäftliche Signale. Die Quote offener Pix-Zahlungen, Abbrüche im Checkout und Beschwerden über Zahlungen ohne Bestellung zählen genauso viel wie ein Dateialarm.
5. Sichern Sie Nachweise. Datum, Seite, was sich geändert hat und wer es freigegeben hat. Das verlangt der PCI-DSS-Auditor, und es hilft, den Vorfall dem Kunden zu erklären.

Kurze Checkliste

• Liste der Skripte auf der Zahlungsseite, mit Verantwortlichem und Grund.
• Alarm bei Dateiänderungen außerhalb einer Veröffentlichung.
• Content Security Policy mit aktiven Berichten.
• Überwachung im Browser des echten Kunden, nicht nur per Bot.
• Prüfung von QR-Code, Copia e Cola, linha digitável und Kartenformular gegen das, was der Shop ausgestellt hat.
• Tägliches Dashboard mit der Quote offener Pix-Zahlungen.
• Protokoll jeder freigegebenen Änderung und jedes bearbeiteten Alarms.

Den Hintergrund zu den Angriffen, die diese Überwachung verhindert, finden Sie in Magecart: was es ist und wie Sie Ihren Onlineshop schützen. Zu den Anforderungen siehe Drittanbieter-Skripte auf der Zahlungsseite.

Wo Proteside ins Spiel kommt

Proteside deckt die zweite und die vierte Ebene im Browser des Käufers ab: Es führt das Inventar der Skripte auf der Zahlungsseite und prüft bei jeder Bestellung, ob QR-Code, Copia e Cola, linha digitável und Kartenformular die sind, die der Shop ausgestellt hat. Wenn nicht, blockiert es den Tausch vor der Bestätigung, benachrichtigt den Shop und protokolliert den Fall als Nachweis für PCI DSS. Siehe so funktioniert es.