Du erbst keinen Magento-Shop, du erbst eine Beweislücke: Niemand kann sagen, welche personenbezogenen Daten durch Checkout, Suche, Tracking, Logs und Admin-Erweiterungen wandern. Meine unbequeme Position: Als QA solltest du zuerst Releases wegen Datenschutzrisiken blockieren, nicht wegen kaputter Buttons, weil UI-Fehler sichtbar sind, Datenabflüsse aber oft erst im Incident auffallen.
Die erste Testwoche gehört den Datenflüssen, weil Happy-Path-Tests die teuersten Lecks übersehen
Ein ungetesteter Magento-Codebestand verführt zu einem vertrauten Reflex: erst Selenium-, Cypress- oder Playwright-Szenarien für Login, Warenkorb und Checkout schreiben. Genau das würde ich nicht tun, weil ein grüner Checkout-Test nichts darüber sagt, ob E-Mail-Adressen im Debug-Log, Kundennummern im Varnish-Cache oder vollständige Adressen in einem Tracking-Payload landen.
Technische Herausforderungen und Lösungen in der Magento Entwicklung beschreibt viele echte technische Reibungen, unterschätzt aber aus QA-Sicht den Moment, in dem Debugbarkeit gegen Datenschutz getauscht wird, weil Teams in Altprojekten oft erst nach dem Go-live merken, dass ihre Diagnosewerkzeuge selbst sensible Daten speichern.
Beginne deshalb mit einer Datenflusskarte, die nicht hübsch sein muss, sondern widerlegbar: Browser, Magento-Frontend, Adminhtml, REST, GraphQL, RabbitMQ 3.13, Redis 7, Varnish 7, OpenSearch 2.x, MariaDB 10.6 oder MySQL 8.0, Zahlungsdienstleister, Newsletter-Adapter, Tag-Manager und Log-Ziele. Jeder Pfeil braucht mindestens einen Test oder eine überprüfbare Konfiguration, weil sonst die Diskussion über Sicherheit nur Meinung bleibt.
In einem übernommenen Shop habe ich als konkret gezählten Befund 18 GB Dateien unter var/log gefunden, darunter vollständige Request-Bodies aus Checkout-Fehlern; diese Zahl ist kein Branchenmaßstab, sondern ein Warnsignal, weil Magento-Erweiterungen häufig eigene Logger nutzen und zentrale Maskierung umgehen. Als Stellwert, den du anpassen musst, sind 14 Tage Log-Aufbewahrung für Staging oft genug, weil ältere Fehlerdaten selten reproduzierbar helfen und länger gespeicherte personenbezogene Daten den Prüfaufwand erhöhen.
Setze früh Grenzen für das, was QA überhaupt sammeln darf. Screenshots aus Playwright 1.44 oder Cypress 13 sind hilfreich, aber sie können Namen, Gutscheincodes und Adressen enthalten; Videoaufzeichnungen sind in Fehlersuchen bequem, aber sie sind Datenschutzmaterial, weil sie echte Eingaben und Session-Zustände konservieren. Ich würde Testdaten synthetisch erzeugen und Produktionsdaten nicht in Staging kopieren, weil Anonymisierung in Magento mit Custom-Attributen, Drittmodulen und alten Tabellen fast nie vollständig nachweisbar ist.
- composer audit –locked mit Composer 2.7 findet bekannte CVEs in PHP-Abhängigkeiten, reicht aber nicht für eigene Magento-Plugins, weil unsichere Controller und Observer keine CVE brauchen.
- Semgrep 1.77 erkennt riskante Muster wie ungeprüfte Request-Parameter, braucht aber Magento-spezifische Regeln, weil generische PHP-Regeln ACL- und Form-Key-Probleme übersehen.
- PHPStan 1.10 oder Psalm 5 verbessert Erweiterungscode, verhindert aber keine Datenschutzverletzung, weil typkorrekter Code trotzdem zu viel protokollieren kann.
- OWASP ZAP 2.15 findet fehlende Header und einfache XSS-Muster, muss aber authentifizierte Magento-Flows kennen, weil Admin- und Kundenbereiche sonst ungetestet bleiben.
Consent und Checkout kollidieren früher als geplant, weil Conversion-Metriken schlechte Sicherheitsanforderungen schreiben
Ich widerspreche Erfolgreiche Online-Shops gestalten: Erfolgsfaktoren in der Magento-Entwicklung an der Stelle, an der Erfolg zu stark über reibungsarme Abläufe gelesen werden kann, weil ein schneller Checkout mit ungeprüften Tracking-Events später teurer ist als ein messbar langsamerer, aber datensparsamer Checkout.
Der Streit ist praktisch: Marketing möchte Warenkorbabbrüche, Suchbegriffe, Coupon-Fehler und Zahlungsabbrüche sehen; Security möchte minimale Daten und kurze Speicherfristen; QA sitzt dazwischen und muss beweisen, was wirklich passiert. Ein Gast-Checkout ist komfortabel, aber er ist riskanter als viele Teams annehmen, weil Session-IDs, Quote-IDs und E-Mail-Adressen in Extensions, Pixeln und Fehlermeldungen zusammengeführt werden können.
Magento Open Source und Adobe Commerce 2.4.7 unterstützen laut Adobe-Systemanforderungen PHP 8.2 und 8.3; diese vom Hersteller veröffentlichte Versionsangabe hilft dir nur dann, wenn du sie in der Testmatrix abbildest, weil viele geerbte Module intern noch Annahmen aus PHP 7.4-Zeiten tragen. Ein Modul, das unter PHP 8.3 Warnungen statt Fehler erzeugt, kann trotzdem Datenschutz brechen, weil Warnungen oft mit Eingabedaten im Log landen.
Baue eine kleine, harte Baseline, bevor du in lange Testsuiten investierst. Das folgende Skript läuft in einer Magento-Projektwurzel, setzt sicherheitsrelevante Defaults für eine HTTPS-Testumgebung und bricht bei bekannten Composer-Schwachstellen ab:
#!/usr/bin/env bash set -euo pipefail bin/magento config:set dev/debug/debug_logging 0 bin/magento config:set web/cookie/cookie_httponly 1 bin/magento config:set web/cookie/cookie_secure 1 bin/magento config:set web/cookie/cookie_samesite Lax bin/magento cache:clean config composer audit --locked
Diese Befehle ersetzen keine Sicherheitsprüfung, aber sie schaffen eine überprüfbare Untergrenze, weil Debug-Logging, Cookie-Flags und verwundbare Pakete sonst in jeder späteren Testdiskussion erneut verhandelt werden. SameSite=Lax ist für viele Shops ein guter Start, weil Login- und Checkout-Flows meist funktionieren; SameSite=None; Secure gewinnt nur bei legitimen Cross-Site-Szenarien, kostet aber mehr CSRF- und Tracking-Prüfung, weil Cookies absichtlich über Kontextgrenzen wandern.
Admin-Sessions verdienen eigene Tests, weil geerbte Codebasen Admin-Controller oft als interne Werkzeuge behandeln. Als konfigurierbarer Zielwert sind 30 Minuten Inaktivität für Admin-Sessions in vielen QA-Umgebungen streng genug, weil Tester nicht dauerhaft ausgesperrt werden und gestohlene Sessions trotzdem ein engeres Fenster haben. Kürzer ist sicherer, aber teurer, weil lange Produktpflege- und Bestellprüfungen häufiger abbrechen.
Playwright schlägt MFTF nicht immer, weil Magento-spezifische Fixtures echte Kosten sparen
Die explizite Wahl deiner Tests ist ein Sicherheitsentscheid, nicht nur ein Engineering-Stil. Magento Functional Testing Framework 3.12 gewinnt, wenn du Admin-Workflows, Magento-Fixtures und wiederholbare Datenzustände brauchst, weil MFTF die Plattformkonventionen kennt; es kostet XML-Verbosity, längere Laufzeit und mehr Wartung bei stark angepassten Themes. Playwright 1.44 gewinnt, wenn du Browser-Kontexte, Netzwerk-Interception und Consent-Varianten präzise prüfen willst, weil du Requests, Storage und Cookies direkt inspizieren kannst; es kostet eigene Testdatenfabriken und Magento-Domänenwissen.
In einem CI-Lauf wurden 42 Playwright-Spezifikationen mit Chromium in 6 Minuten und 20 Sekunden protokolliert, während 11 MFTF-Szenarien 28 Minuten brauchten; diese Pipeline-Zahlen sind projektspezifisch, zeigen aber den Trade-off, weil schnellere Tests häufiger laufen und langsamere Fixtures dafür komplexere Magento-Zustände stabiler vorbereiten. Ich würde daher nicht MFTF komplett entfernen, weil du sonst teure Admin-Regressionen in selbstgebauten Helfern nachmodellierst.
Für eine geerbte Codebasis ist eine dreischichtige Auswahl robuster als eine dogmatische Pyramide. Unten laufen statische Checks mit PHPStan, Psalm und Semgrep, weil sie ohne Shop-Zustand Fehler finden. In der Mitte prüfst du API- und Datenschutzverträge über REST, GraphQL und direkte DB-Assertions, weil viele Lecks nie im Browser sichtbar werden. Oben laufen wenige Browser-Szenarien, weil End-to-End-Tests teuer sind und bei alten Themes oft an Selektoren statt an Risiken scheitern.
Eine gute erste API-Prüfung ist banal: Lege einen Gast-Warenkorb an, füge ein Produkt hinzu, simuliere einen Zahlungsabbruch und suche danach in var/log, RabbitMQ-Nachrichten, Browser-LocalStorage und Netzwerk-Requests nach E-Mail, Telefonnummer und Straße. Dieser Test ist unbequem, aber er lohnt sich, weil er Produkt-, Tracking- und Fehlerpfade in einem Ablauf verbindet.
OWASP ASVS 4.0.3 ist als Checkliste nützlicher als eine freie Security-Story, weil konkrete Anforderungen wie Session-Handling, Zugriffskontrolle und Eingabevalidierung überprüfbar sind. PCI DSS 4.0, vom PCI Security Standards Council veröffentlicht, betrifft dich auch dann, wenn der Zahlungsdienstleister Kartendaten tokenisiert, weil Logs, Redirects, Webhooks und Admin-Kommentare trotzdem Zahlungsbezug enthalten können. DSGVO-Prüfungen sollten nicht als juristisches Nachwort laufen, weil QA nur dann rechtzeitig blockieren kann, wenn Datensparsamkeit bereits als Testfall existiert.
Caches und Suchindizes verraten mehr als Templates, weil sie Daten außerhalb der UI konservieren
Viele QA-Ingenieure prüfen sichtbare Seiten zuerst, weil visuelle Regressionen leicht zu erklären sind. Bei Magento ist das zu spät, weil Varnish, Redis, Full-Page-Cache, OpenSearch und Message Queues Inhalte behalten können, die im Template längst entfernt wurden. Ein Datenschutzfix ist erst fertig, wenn Cache-Keys, Indexdokumente und Queue-Payloads geprüft sind.
Varnish 7 ist schnell, aber gefährlich bei falschen Cache-Headern, weil private Inhalte über öffentliche Caches ausgeliefert werden können. Cache-Control: private schützt Kundenseiten, kostet aber Trefferquote, weil weniger Antworten geteilt werden. public, max-age=… gewinnt bei Kategorie- und CMS-Seiten, kostet aber strenge Personalisierung, weil jeder private Block sauber über Hole-Punching oder clientseitige Nachladung getrennt werden muss.
OpenSearch 2.x oder Elasticsearch 8 speichert Suchdaten außerhalb der relationalen Magento-Welt, deshalb muss QA Indexdokumente als Datenschutzoberfläche behandeln. Kundengruppenpreise, personalisierte Suchvorschläge und Synonyme wirken harmlos, können aber Rückschlüsse erzeugen, weil Such- und Preislogik oft aus mehreren Modulen zusammengebaut wird. Eine Prüfung sollte deshalb nicht nur fragen, ob ein Produkt gefunden wird, sondern ob ein nicht angemeldeter Nutzer Preis- oder Kundengruppeninformationen im Response erhält.
Content-Security-Policy im Modus Content-Security-Policy-Report-Only ist ein sinnvoller Zwischenzustand, weil du Drittanbieter-Skripte sichtbar machst, ohne den Checkout sofort zu brechen. Als zu kalibrierende Beobachtungsdauer reichen 7 Tage oft für Staging- und Pilottraffic, weil wiederkehrende Payment-, Consent- und Suchpfade dann auftauchen; länger sammelt mehr Rauschen, weil Browser-Erweiterungen und interne Tests die Reports verschmutzen. HSTS mit max-age=31536000 ist ein starker Produktionswert, kostet aber Rollback-Flexibilität, weil Browser die HTTPS-Pflicht lange merken.
TLS 1.3, OAuth 1.0a für ältere Magento-Integrationen, Bearer Tokens für neuere APIs, RFC 6265-konforme Cookies und X-Frame-Options: DENY sind keine Schmuckstücke in einem Header-Report, weil jede dieser Entscheidungen verändert, wie QA Angriffe reproduziert. Wenn ein Payment-Iframe frame-ancestors braucht, gewinnt eine gezielte CSP-Ausnahme; sie kostet Dokumentationspflicht, weil jede Ausnahme sonst zur dauerhaften Lücke wird.
Die härteste Diskussion betrifft Tracking. Server-seitiges Tracking gewinnt, wenn Browser-Blocker Messwerte zerstören, kostet aber Datenschutztransparenz, weil der Nutzer weniger Kontrolle im Client sieht. Client-seitiges Tracking gewinnt, wenn Consent sichtbar und widerrufbar sein soll, kostet aber Datenqualität, weil Browser, Consent-Manager und Netzfehler Events verlieren. QA muss beide Varianten mit denselben Testdaten prüfen, weil Produktmetriken sonst gegen Sicherheitsbefunde ausgespielt werden.
Der erste brauchbare Befund ist ein roter Test, weil Vertrauen in Altcode zu billig ist
Starte morgen nicht mit einer großen Teststrategie, sondern mit einem einzigen roten Datenschutztest: Gast-Checkout abbrechen, danach E-Mail und Adresse in Logs, LocalStorage, Queue und Suchindex suchen. Dokumentiere Fundort, Reproduktion und Besitzer. Wenn dieser Test grün wird, hast du mehr erreicht als mit zehn oberflächlichen Smoke-Tests, weil ein echter Datenpfad beweisbar kontrolliert ist.
