Penetrationstest für den Shop: wann er sich wirklich lohnt

Ein Schwachstellenscanner arbeitet wie ein Abgleich. Er erkennt Betriebssystem, Webserver, Shopsoftware und Erweiterungen samt Versionsnummer und vergleicht sie mit den Einträgen seiner Datenbank. So findet er veraltete Software, fehlende Patches und Fehlkonfigurationen, schnell und so oft wie nötig. Das US-Standardisierungsinstitut NIST beschreibt in seinem Leitfaden SP 800-115 auch die Kehrseite: Obwohl der Ablauf weitgehend automatisiert ist, können Scanner eine hohe Quote an Fehlalarmen haben, also Schwachstellen melden, die es gar nicht gibt (NIST). Die Ergebnisse sollte deshalb jemand mit Erfahrung in Netzwerk- und Systemsicherheit einordnen, bevor daraus Arbeit entsteht.

Ein Penetrationstest geht einen Schritt weiter. Nach der Beschreibung des NIST ahmen die Prüfer echte Angriffe nach, um Wege zu finden, die Sicherheitsfunktionen einer Anwendung zu umgehen; die meisten Tests suchen dabei nach Kombinationen von Schwachstellen, die zusammen mehr Zugriff verschaffen als jede einzelne (NIST). Der PCI Security Standards Council, der die Sicherheitsregeln der Kartenzahlungsbranche herausgibt, nennt den Penetrationstest im Kern eine manuelle Arbeit (PCI SSC 2017). Werkzeuge helfen bei Routineschritten, die Entscheidungen trifft der Prüfer. Das NIST hält fest, dass manuelle Prüfungen neue oder ungewöhnliche Schwachstellen finden können, die automatische Scanner übersehen (NIST).

Für einen Shop ist der Unterschied greifbar. Die OWASP, eine offene Gemeinschaft für Anwendungssicherheit, beschreibt in ihrem Testleitfaden WSTG einen Shop, in dem ein Angreifer nach der Zusammenfassung des Warenkorbs zurückspringt, in derselben gültigen Sitzung einen niedrigeren Preis einschleust und die Bestellung abschließt. Solche Fehler in der Geschäftslogik kann ein Schwachstellenscanner nach dem Leitfaden nicht erkennen; ihr Fund hängt am Können und an der Kreativität des Prüfers (OWASP). Ähnlich bei Zugriffsrechten: Für die OWASP Top 10 der Ausgabe 2025 wurde bei 100 Prozent der getesteten Anwendungen irgendeine Form fehlerhafter Zugriffskontrolle gefunden, darunter der Fall, dass sich fremde Konten über deren Kennung ansehen oder bearbeiten lassen (OWASP). Im Shop heißt das: Wer die Nummer in der Adresse seiner Bestellung ändert, darf nicht die Rechnung eines anderen Kunden sehen. Ob das so ist, prüft ein Mensch mit zwei Testkonten in wenigen Minuten, ein Scanner in der Regel gar nicht.

Nicht jeder Shop braucht jedes Jahr einen Penetrationstest. Ein Standardshop ohne eigenen Code, mit gepflegten Erweiterungen aus bekannten Quellen und einer ausgelagerten Zahlungsseite profitiert zuerst von den Grundlagen: zeitnahe Sicherheitsupdates, regelmäßige Scans, ein gehärteter Server und abgesicherte Admin-Zugänge. Auch das BSI empfiehlt, vor einem Penetrationstest zunächst eine IS-Kurzrevision durchzuführen, also stichprobenartig die Basisabsicherung zu prüfen (BSI). Das NIST rät, zwischen den Tests weniger aufwendige Prüfungen regelmäßig laufen zu lassen; ein Programm aus regelmäßigen Netzwerk- und Schwachstellenscans, ergänzt um gelegentliche Penetrationstests, kann viele Arten von Angriffen verhindern (NIST).

In der Breite ist systematisches Testen noch keine Routine: 2024 setzten 34,64 Prozent der Unternehmen in der EU mit mindestens 10 Beschäftigten Sicherheitstests ihrer IT ein (Eurostat 2024). Für einen Shop, der Zahlungen, Kundenkonten und Bestellhistorien verwaltet, ist die Frage deshalb weniger, ob geprüft wird, sondern wie tief: Der Scan deckt die Breite ab, der Penetrationstest die Stellen, an denen eigener Code und eigene Abläufe hängen.

Der häufigste Fehler beim Beauftragen ist ein unklarer Umfang. Das BSI empfiehlt, auf Basis von Bedrohungslage und Schutzbedarf die Systeme in den Fokus zu nehmen, die besonders bedroht oder geschäftskritisch sind, und aus Angreifersicht zu schauen, wo Schnittstellen liegen (BSI). Im Shop sind das in der Regel Checkout und Zahlungsrückmeldung, Kundenkonto und Bestellhistorie, Gutscheine und Rabatte, die Verwaltungsoberfläche, die Programmierschnittstellen für App, ERP oder Marktplatz sowie alle eigenen Erweiterungen. Dazu gehört die Prüftiefe: Das BSI empfiehlt grundsätzlich einen Whitebox-Test, bei dem die Prüfer umfangreiche Informationen über das System erhalten, weil bei einem Blackbox-Test Schwachstellen übersehen werden können (BSI). Für einen Shop heißt das: Testkonten mit verschiedenen Rollen, eine Liste der installierten Erweiterungen und, wo vorhanden, Zugang zum Code eigener Plugins.

Dann die Frage, wo getestet wird. Eine Staging-Umgebung, die der Produktion in Versionen, Erweiterungen und Konfiguration gleicht, schützt laufende Bestellungen und echte Kundendaten. Das BSI weist aber darauf hin, dass Ergebnisse aus einer nachgebauten Umgebung nur bedingt auf das Originalsystem übertragbar sind (BSI). Deshalb kommt es auf die Parität zur Produktion an: gleiche Versionen, gleiche Erweiterungen, gleiche Servereinstellungen, aber anonymisierte Testdaten. Wird doch die Produktion getestet, gehören ein Zeitraum mit wenig Betrieb und eine frische, geprüfte Sicherung dazu. Das NIST erinnert daran, dass Systeme während eines Penetrationstests beschädigt oder unbrauchbar werden können und sich dieses Risiko nicht vollständig ausschließen lässt (NIST).

Eine Besonderheit betrifft Schutzschichten vor dem Shop. Das BSI empfiehlt, einen Webauftritt zunächst ohne vorgeschaltetes Sicherheitsgateway zu untersuchen (BSI). Der PCI SSC begründet das so: Ziel des Tests ist die Anfälligkeit der Dienste selbst, nicht die Fähigkeit der Schutzsysteme, Angriffe abzuwehren (PCI SSC 2017). Fällt eine Web Application Firewall später aus oder wird sie umgangen, soll die Anwendung trotzdem standhalten. Praktisch heißt das: Die Prüfadressen werden in der Firewall für den Testzeitraum freigegeben, statt dass der Test an ihr abprallt und einen zu guten Eindruck hinterlässt.

Das NIST teilt einen Penetrationstest in vier Phasen: Planung, Erkundung, Angriff und Bericht (NIST). In der Planung werden Regeln festgelegt, die Freigabe der Leitung dokumentiert und Testziele gesetzt; getestet wird in dieser Phase noch nicht (NIST). Das BSI gliedert den Meilensteinplan in Einarbeitungs-, Test- und Berichtsphase (BSI). Für den Shop-Betrieb ist eine Gliederung in fünf Schritte praktisch, weil sie die Vorbereitung der Testumgebung und den Nachtest ausdrücklich einschließt:

Die Dauer hängt am Umfang. Ein Test, der nur Checkout und Kundenkonto eines Standardshops prüft, ist kleiner als einer, der zusätzlich eine ERP-Schnittstelle und die Verwaltung einschließt. Das BSI rät, bei begrenzten Mitteln zuerst die Schnittstellen zu testen, an denen ein Angriff am wahrscheinlichsten ist, und weitere Bereiche in späteren Tests nachzuholen (BSI). Für viele Shops ist das der vernünftige Einstieg: lieber Checkout, Konto und eigene Erweiterungen gründlich als den ganzen Server oberflächlich.

Ein Bericht, der in einem Ordner liegt, verbessert nichts. Das NIST formuliert es knapp: Die Ergebnisse eines Penetrationstests sollten ernst genommen und gefundene Schwachstellen behoben werden (NIST). Im Shop-Betrieb gelingt das, wenn jeder Befund dort landet, wo ohnehin geplant wird: im Wartungsplan, mit Verantwortlichem, Frist und Nachweis. Die Stufen aus dem BSI-Leitfaden lassen sich dafür direkt übersetzen:

Für die mittleren und niedrigen Befunde gilt dieselbe Disziplin wie für jedes Update: erst auf Staging, dann mit Regressionstests in einem geplanten Wartungsfenster. Befunde, die sich nicht sofort beheben lassen, etwa weil eine Erweiterung noch keinen Patch hat, bekommen eine Übergangsmaßnahme und eine dokumentierte Entscheidung. Ein akzeptiertes Risiko ist legitim, solange jemand es bewusst trägt und mit Datum festgehalten hat. Fehlalarme gehören mit Begründung ebenfalls in die Liste, damit der nächste Test sie nicht erneut als offen führt. Für hohe Befunde braucht es zudem einen Weg außerhalb des regulären Fensters, etwa über den Notfall-Support.

Ein Penetrationstest ist eine Momentaufnahme. Das BSI empfiehlt, im Vertrag festzuhalten, dass die Ergebnisse nur zum Zeitpunkt des Tests gültig sind (BSI). Was zwischen zwei Tests passiert, entscheidet die Wartung: Sie spielt Sicherheitsupdates zeitnah ein, lässt regelmäßige Schwachstellenscans laufen, beobachtet Auffälligkeiten im Monitoring und dokumentiert jede Änderung. Im Rahmen eines SLA-Wartungsvertrags bereiten wir den Test auf der Shopseite vor und arbeiten die Befunde danach im Wartungsplan ab. Den Test selbst führen bei Bedarf spezialisierte Partner durch.

Wer unsicher ist, ob ein Test im eigenen Fall ansteht, beginnt mit einer Bestandsaufnahme: welche eigenen Erweiterungen, welche Schnittstellen, welche Zahlungsanbindung und wann die letzte Prüfung war. Daraus ergibt sich, ob Scan und Härtung zunächst genügen oder ob ein Penetrationstest den größeren Nutzen bringt. Die Übersicht unserer Leistungen und die Seite zur Shopware-Wartung zeigen, wie Wartung, Monitoring und Notfallhilfe zusammenhängen; für eine Einschätzung zu Ihrem Shop erreichen Sie uns über die Kontaktseite.