Lösen vom Zahlungsanbieter gehostete Kartenfelder alles?

Nein. Vom Zahlungsanbieter gehostete Kartenfelder (angezeigt in einem in Ihre Seite eingebetteten Fenster, das der Anbieter ausliefert) halten Kartendaten von Ihrem Server und vom Code Ihrer Seite fern und verkleinern deshalb den PCI-DSS-Prüfumfang deutlich. Die Seite drumherum gehört aber weiter Ihnen, und genau dort kann der Angriff stattfinden: ein gefälschtes Formular vor dem echten, ein ausgetauschtes Fenster, ein Button, der woandershin führt. Das PCI Security Standards Council sagt selbst, dass die Seite, die das Formular des Anbieters einbettet, im Prüfumfang bleibt.

Was gehostete Felder lösen

In diesem Modell gehören die Felder für Kartennummer, Ablaufdatum und Prüfnummer nicht zu Ihrer Seite: Sie liegen in einem kleinen eingebetteten Fenster (einem iframe), dessen Inhalt von der Adresse des Anbieters kommt. Browser trennen Inhalte unterschiedlicher Adressen voneinander, daher kann Code auf Ihrer Seite (auch Schadcode) nicht lesen, was der Kunde in dieses Fenster tippt. Die Daten gehen direkt an den Anbieter.

Das ist ein echter Gewinn. Weniger Daten laufen durch den Shop, weniger Anforderungen greifen, und viele Händler können den einfachsten Selbstbewertungsfragebogen nutzen, den SAQ A, sofern sie dessen Zulassungskriterien erfüllen. Wer gehostete Felder nutzt, sollte dabei bleiben. Entscheidend ist, Prüfumfang verkleinern nicht mit Risiko beseitigen zu verwechseln.

Wo das Risiko bleibt

Der Leitfaden des PCI SSC zur Sicherheit von Zahlungsseiten vom März 2025 ist eindeutig: Das Einbetten eines fremden Formulars nimmt die anzeigende Seite nicht vollständig aus dem Prüfumfang und macht die Anforderungen 6.4.3 und 11.6.1 nicht unanwendbar. Der Händler ist für die Skripte dieser Seite verantwortlich, und wenn ein Skript das Fenster erzeugt, fällt auch dieses Skript darunter. In der Praxis haben Täter mehrere Wege, ohne die Felder des Anbieters je zu berühren:

• Ein gefälschtes Formular vor dem echten. Im Februar 2026 berichtete das Forschungsunternehmen Sansec über eine international tätige Supermarktkette, deren echtes Kartenformular vom Zahlungsdienstleister stammte. Eingeschleuster Code auf der Shopseite zeigte zuerst ein gefälschtes Formular; Kunden gaben dort ihre Daten ein, sahen dann das echte Formular und tippten alles erneut. Laut Sansec bevorzugen Täter solche Overlays gerade deshalb, weil die Karteneingabe in Formulare der Anbieter gewandert ist.
• Das Fenster austauschen oder verdecken. Ihre Seite sagt dem Browser, woher das Zahlungsfenster geladen wird. Wird der zuständige Code verändert, kann das Fenster von einer ähnlich aussehenden Adresse kommen oder unter einer identischen Ebene verschwinden.
• Den Button umlenken. Der Bezahl-Button und die Schritte davor gehören ebenfalls zu Ihrer Seite und lassen sich so ändern, dass sie Kunden woandershin schicken.
• Daten außerhalb des Fensters. Name, E-Mail, Telefon und Adresse werden meist auf Ihrer Seite eingegeben, nicht beim Anbieter.
• Single-Page-Shops. Lädt der Browser zwischen den Schritten nicht neu, bleiben früh geladene Skripte bei der Zahlung aktiv; der Leitfaden zählt alle Ansichten zum Prüfumfang.

Was sich beim SAQ A geändert hat und was weiter gilt

Im Januar 2025 hat das PCI SSC die Anforderungen 6.4.3 und 11.6.1 aus dem SAQ A gestrichen, aber ein Zulassungskriterium ergänzt: Der Händler muss bestätigen, dass seine Website nicht anfällig für Skript-Angriffe ist, die seine E-Commerce-Systeme beeinträchtigen könnten. Das Council betonte, dass die Änderung die zugrunde liegenden Anforderungen des PCI DSS weder aufhebt noch abschwächt.

Im Februar 2025 stellte FAQ 1588 klar, dass dieses Kriterium für Shops gilt, deren Seite das Formular des Anbieters einbettet, nicht für Shops, die Kunden auf die Website des Anbieters umleiten. Es gibt zwei Wege, es zu erfüllen: Techniken wie die aus den Anforderungen 6.4.3 und 11.6.1 einsetzen, um die Seite vor Skripten zu schützen, die es auf Kontodaten abgesehen haben, selbst oder über einen Dritten; oder vom PCI-DSS-konformen Anbieter die Bestätigung einholen, dass seine Lösung diesen Schutz für die Händlerseite enthält, sofern sie nach seinen Vorgaben umgesetzt wird. Kurz: Der Fragebogen ist kürzer geworden, die Frage nach Ihrer Seite steht aber weiterhin darin.

Checkliste für Shops mit gehosteten Feldern

• Fragen Sie Ihren Anbieter schriftlich, ob und unter welchen Bedingungen seine Lösung Ihre Seite vor Skripten schützt, und halten Sie sich genau an seine Implementierungsvorgaben.
• Behandeln Sie die Seite mit dem Formular als sensibel. Lassen Sie dort nur unverzichtbare Skripte zu und wissen Sie, wer sie ändern darf.
• Erfassen und überwachen Sie die Skripte dieser Seite, so wie der Browser des Kunden sie erhält.
• Prüfen Sie auf dem Bildschirm des Käufers, dass das Zahlungsfenster von der Adresse des Anbieters kommt und kein anderes Kartenformular davor oder darüber erscheint.
• Schützen Sie, was außerhalb des Fensters liegt, etwa Name, E-Mail und Adresse.
• Nehmen Sie Berichte über doppelte Karteneingabe ernst.
• Klären Sie mit Ihrem Acquirer, welcher Fragebogen für Ihren Shop gilt.

Proteside schützt genau die Seite rund um die Felder des Anbieters: Es prüft im Browser des Käufers, dass das angezeigte Formular das echte ist und von der richtigen Adresse kommt, blockiert Overlays und liefert den Nachweis für die Anforderungen 6.4.3 und 11.6.1. Lernen Sie den Schutz für Kartenzahlungen und die Lösung für PCI-DSS-Konformität kennen und testen Sie 14 Tage kostenlos.