Anzeichen dafür, dass Ihr PrestaShop-Shop ein Sicherheitsaudit braucht (und wie Sie zuerst selbst prüfen)
Zuletzt aktualisiert: Juni 2026.
Die meisten PrestaShop-Shops müssen kein Sicherheitsprodukt kaufen. Sie müssen wissen, wie groß ihr tatsächliches Risiko ist — und die meisten Betreiber wissen das schlicht nicht, weil sichtbar nichts falsch läuft. Ein Skimmer kann wochenlang in der Kasse sitzen, während Bestellungen ganz normal eingehen. Ein anfälliges Modul kann jahrelang ungepatcht bleiben, bevor jemand gezielt danach scannt. Bei einer Sicherheitsprüfung geht es nicht um Angst; es geht darum, ein vages „Wird schon passen“ durch eine klare, belegbare Antwort zu ersetzen. Dieser Beitrag zeigt die konkreten Anzeichen, bei denen ein genauerer Blick sinnvoll ist, und gibt Ihnen einen Selbstcheck an die Hand, den Sie in rund zehn Minuten durchführen können, bevor Sie entscheiden, ob Sie überhaupt externe Hilfe brauchen.
Die Anzeichen, die wirklich zählen
Das ist keine Theorie. Jeder einzelne Punkt hat in echten Shops schon zu echten Vorfällen geführt. Lesen Sie sie als Risikofaktoren: Je mehr davon auf Sie zutreffen, desto eher lohnt sich ein strukturiertes Audit.
Sie verwenden eine alte oder nicht mehr unterstützte PrestaShop-Version
PrestaShop 1.6 ist schon lange am Ende seines Lebenszyklus, und der Großteil des 1.7.x-Zweigs erhält keine Sicherheitskorrekturen mehr. Selbst bei 8.x kann eine Installation, die ein paar Minor-Versionen zurückliegt, Patches für öffentlich bekannte Schwachstellen vermissen lassen. Ein alter Core ist der stärkste einzelne Hinweis auf ein erhöhtes Risiko, weil Angreifer keine neue Schwachstelle finden müssen — sie scannen einfach nach den bereits dokumentierten. Wenn Sie ohne Nachsehen nicht sagen können, welche exakte Version Sie nutzen, ist schon das ein Warnsignal.
Ihre Module wurden seit Jahren nicht aktualisiert
Das ist bei den meisten Shops die eigentliche Angriffsfläche. Der Core bekommt Aufmerksamkeit; Drittanbieter-Module veralten leise. Die Geschichte ist lang: die blockwishlist-SQL-Injection, Smarty-basierte serverseitige Template-Injection (SSTI), die in mehreren Modulen zu Remote Code Execution führte, und ein stetiger Strom weniger bekannter Schwachstellen. Ein Modul, das Sie einmal installiert und dann vergessen haben, ist gerade deshalb ein perfekter Einstiegspunkt, weil niemand darauf achtet. Wenn Ihre Modul-Update-Liste einen ganzen Stapel ausstehender Aktualisierungen zeigt oder Module von Anbietern enthält, die es nicht mehr gibt, sollten Sie das als deutliches Warnsignal behandeln.
Ihr Adminbereich liegt unter dem Standardpfad, ohne Rate-Limiting oder 2FA
Ein Backoffice, das unter einer vorhersehbaren URL erreichbar ist, ohne Brute-Force-Schutz und ohne Zwei-Faktor-Authentifizierung, ist eine offene Einladung für Credential-Stuffing und Bots zum Erraten von Passwörtern. Sie laufen permanent und müssen nicht besonders clever sein — sie brauchen nur ein einziges schwaches oder wiederverwendetes Passwort aus einem Mitarbeiterkonto.
Keine WAF, und Ihre Origin-IP ist sichtbar
Wenn Ihr Shop ohne Web Application Firewall direkt im offenen Internet steht, erreicht jede schädliche Anfrage ungefiltert Ihren Anwendungscode. Schlimmer noch: Wenn Sie ein CDN nutzen, Ihre echte Origin-IP aber irgendwo durchscheint (in der DNS-Historie, in Mail-Headern oder über eine alte Subdomain), können Angreifer den Schutz komplett umgehen und den Server direkt angreifen.
Unerklärliche Dateien, veränderter Core oder Admin-Konten, die Sie nicht kennen
Vereinzelte PHP-Dateien im Webroot, Core-Dateien, die von einer sauberen Version abweichen, oder ein Eintrag in Ihrer Mitarbeiterliste, den niemand im Team angelegt hat — jedes einzelne dieser Dinge kann bedeuten, dass Ihr Shop bereits kompromittiert wurde. Backdoors sind darauf ausgelegt, unauffällig zu wirken und still zu bleiben, deshalb melden sie sich selten von selbst.
Eine Kasse oder ein Zahlungsformular, das „irgendwie anders aussieht“
Das ist der Punkt, der am teuersten werden kann. Skimmer im Magecart-Stil schleusen ein paar Zeilen JavaScript ein, die Kartendaten unbemerkt kopieren, während Kunden sie eingeben, und sie anschließend an den Server eines Angreifers senden. Die Seite funktioniert weiter. Die Bestellung wird weiter abgeschlossen. Nur die Kartendaten fließen ab. Wenn Ihre Kasse subtil anders wirkt — ein zusätzliches Feld, eine verschobene Darstellung, ein Skript, an dessen Einbindung Sie sich nicht erinnern — nehmen Sie das ernst. Wie so etwas genau funktioniert, haben wir in unserem Beitrag zur Anatomie eines Magecart-Angriffs auf einen PrestaShop-Skimmer beschrieben.
Keine Datei-Integritätsüberwachung und keine externen Backups
Wenn Sie nicht erkennen können, dass sich eine Datei geändert hat, können Sie einen sauberen Shop nicht von einem kompromittierten unterscheiden — und meistens erfahren Sie es dann von einem Kunden oder Ihrem Zahlungsdienstleister. Und wenn Ihre einzigen Backups auf demselben Server liegen (oder Sie eine Wiederherstellung nie wirklich getestet haben), kann eine Kompromittierung oder eine defekte Festplatte nicht nur den Tag, sondern das Geschäft beenden.
Sie speichern mehr Kundendaten, als Sie brauchen
Jedes zusätzliche Feld, das Sie aufbewahren, ist eine Haftung, die Sie mittragen. Vollständige Kartendaten zu speichern, jahrelang personenbezogene Daten ohne Aufbewahrungsrichtlinie vorzuhalten oder sensible Details zu protokollieren, macht aus einem „peinlichen“ Vorfall schnell ein PCI-DSS- und DSGVO-Problem mit realem finanziellem und rechtlichem Gewicht. Die sichersten Daten sind die, die Sie nie gespeichert haben.
Ein 10-Minuten-Selbstcheck
Bevor Sie jemanden um Hilfe bitten — auch uns — führen Sie diese Prüfung selbst durch. Sie kostet nichts und sagt Ihnen viel:
- Bestätigen Sie Ihre exakte PrestaShop-Version und prüfen Sie, ob sie noch unterstützt wird. Wenn es 1.6.x oder eine frühe 1.7.x-Version ist, haben Sie Ihre Antwort bereits.
- Öffnen Sie die Modul-Update-Liste in Ihrem Backoffice und zählen Sie die ausstehenden Aktualisierungen. Notieren Sie alle Module von Anbietern, die verschwunden sind.
- Listen Sie Ihre Admin-Mitarbeiter auf. Schauen Sie in die
ps_employee-Tabelle oder auf die Teamseite und prüfen Sie jedes Konto mit Backoffice-Zugriff darauf, ob Sie es kennen. - Vergleichen Sie Ihre Core-Dateien mit einer sauberen Kopie derselben PrestaShop-Version. Alles, was in
/classes,/controllersoder im Root geändert wurde und nicht von Ihnen stammt, verdient genaue Prüfung. - Sortieren Sie das Webroot nach Änderungsdatum. Kürzlich geänderte Dateien, die Sie nicht zuordnen können, sind der schnellste Weg, eine Backdoor zu entdecken.
- Bestätigen Sie, dass Ihre Backups extern existieren und sich tatsächlich wiederherstellen lassen. Ein Backup, das Sie nie getestet haben, ist Hoffnung, kein Backup.
Wenn alle sechs Punkte sauber ausfallen, ist das wirklich beruhigend — und möglicherweise müssen Sie keinen Cent ausgeben. Wenn Ihnen einer davon Bauchschmerzen bereitet, ist genau dieses Unbehagen das nützliche Signal.
Wenn Sie Shell- oder Datenbankzugriff haben: drei schreibgeschützte Befehle
Diese Befehle bestätigen einige der oben genannten Prüfungen und sind strikt schreibgeschützt — sie listen und vergleichen, ändern aber nichts. Passen Sie den Tabellenpräfix ps_ an Ihren eigenen an.
# 1. List every account with back-office access — look for anyone you don't recognise
SELECT id_employee, email, lastname, firstname, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;
# 2. Spot recently-modified PHP files in the webroot (a common backdoor tell)
find /path/to/your/shop -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %p\n' \
| sort
# 3. Confirm your stored PrestaShop version, then compare it to the supported list
mysql -e "SELECT value FROM ps_configuration WHERE name='PS_VERSION_DB';"Die Mitarbeiterabfrage ist der schnellste Weg, ein fremdes Admin-Konto zu entdecken; eine unbekannte E-Mail-Adresse oder eine active=1-Zeile, die niemand angelegt hat, ist ein ernstes Warnsignal. Der find-Befehl zeigt Dateien, die in den letzten 30 Tagen angefasst wurden — gleichen Sie jede davon mit tatsächlich durchgeführten Arbeiten ab. Keiner dieser Punkte beweist für sich allein eine Kompromittierung, aber alles Unerklärliche an dieser Stelle ist genau das „nützliche Signal“, das eine Eskalation rechtfertigt.
Der ehrliche Teil: erst diagnostizieren, dann kaufen
Hier kommt die Wendung, die die meisten Sicherheitsangebote auslassen. Die richtige Reaktion auf diese Anzeichen ist fast nie „ein Produkt kaufen“. Sie lautet: „Herausfinden, was wirklich falsch läuft.“ Manchmal liegt die Lösung in der Konfiguration oder beim Hosting — ein falsch konfigurierter Server, eine fehlende WAF, eine offengelegte Origin-IP — dann ist ein Hosting-Audit der relevante nächste Schritt, nicht ein Modul. Manchmal geht es um Härtung: den Adminpfad absichern, Rate-Limiting und 2FA ergänzen. Genau hier verdient ein Modul mit offen einsehbarem Code wie Security Revolution seinen Platz — aber erst, wenn Sie bestätigt haben, dass genau dort die Lücke liegt. Und manchmal geht es um Bereinigung, weil bereits etwas eingedrungen ist; das ist dann eine eigene, fokussierte Aufgabe.
Genau deshalb lohnt es sich, zuerst ein Sicherheitsaudit durchzuführen: Es bildet Ihr reales Risiko ab und zeigt Ihnen, auf welchem dieser drei Wege Sie tatsächlich stehen, damit Sie kein Geld für ein Problem ausgeben, das Sie gar nicht haben. Sie starten es, indem Sie Ihre Shop-URL auf der Seite für das Sicherheitsaudit eingeben; daraufhin läuft ein schreibgeschützter Bereitschaftscheck gegen die URL, und erst danach wird das Audit beauftragt.
Wenn es Sie nervös macht, Zugriff zu gewähren — das sollte es —, ist dieser Instinkt richtig, und wir haben unseren Ablauf genau darauf ausgerichtet. Das Audit wird schreibgeschützt durchgeführt: Wir schauen nach, wir schreiben nichts, und wir greifen niemals auf Ihre Kundendatenbank zu. Was das genau bedeutet und worauf wir zugreifen bzw. nicht zugreifen, haben wir in unserem Leitfaden zur Audit-Bereitschaft Ihres Shops dokumentiert. Es lohnt sich, ihn vor der Bestellung zu lesen, damit Sie genau wissen, womit Sie einverstanden sind. Sicherheit und Performance hängen oft zusammen. Wenn Sie den Zustand Ihres Shops ohnehin erfassen, lohnt sich deshalb auch ein Blick auf die weiter gefassten Expertenleistungen und das Performance-Audit.
Führen Sie den Zehn-Minuten-Check heute durch. Wenn er sauber ist, genießen Sie die Ruhe — Sie haben sie sich kostenlos verdient. Wenn nicht, wissen Sie jetzt genug, um die richtige Frage zu stellen, und das ist deutlich mehr wert als jedes einzelne Produkt.
Häufig gestellte Fragen
Bereinigt ein Sicherheitsaudit eine Infektion oder findet es sie nur?
Ein Audit diagnostiziert — es bildet Ihr Risiko ab und sagt Ihnen, ob bereits etwas eingedrungen ist. Die Bereinigung ist eine separate, fokussierte Aufgabe, denn eine Backdoor sicher zu entfernen bedeutet, jeden Einstiegspunkt zu finden, nicht nur den einen, den Sie bemerkt haben, und anschließend die Lücke zu schließen, durch die sie hereingekommen ist, damit sie nicht zurückkehrt. Das Audit sagt Ihnen, ob Sie überhaupt eine Bereinigung brauchen und wie tief sie gehen muss. Behandeln Sie jedes Versprechen nach dem Motto „Wir scannen und beheben alles in einem Durchgang“ mit Vorsicht; eine stille, hartnäckige Backdoor lässt sich selten so sauber entfernen.
Ich betreibe einen aktuellen PrestaShop 8 mit allen Updates. Brauche ich trotzdem ein Audit?
Möglicherweise nicht, und das ist eine gute Ausgangslage. Ein aktueller Core plus aktualisierte Module beseitigen die größten, am häufigsten gescannten Risiken. Die verbleibenden Fragen, die ein Audit beantwortet, sind die, die Updates nicht abdecken: Wird Ihre Origin-IP hinter dem CDN offengelegt, ist der Adminpfad per Brute Force angreifbar, haben Sie Datei-Integritätsüberwachung und ein getestetes externes Backup, und speichern Sie mehr Kundendaten, als Sie sollten? Wenn der Zehn-Minuten-Selbstcheck auch hier sauber ausfällt, ist Ihr Shop wirklich gut aufgestellt.
Benötigen Sie mein Admin-Passwort oder eine Kopie meiner Datenbank?
Nein. Ein Sicherheitsaudit beginnt nur mit Ihrer Shop-URL und läuft weitgehend von außen nach innen. Wenn eine Prüfung einen Blick ins Backoffice erfordert, genügt ein schreibgeschütztes Mitarbeiterkonto, und wir verlangen oder erstellen niemals eine Kopie Ihrer Kunden- oder Bestelldaten. Das vollständige Zugriffsmodell finden Sie im Leitfaden zur Audit-Bereitschaft Ihres Shops — lesen Sie ihn vor der Bestellung, damit Sie genau wissen, was dazugehört.
Wie unterscheide ich beim Selbstcheck zwischen einer echten Kompromittierung und einem Fehlalarm?
Allein können Sie das oft nicht, und das ist die ehrliche Grenze eines Selbstchecks — er ist dafür gebaut, Warnsignale zu liefern, nicht sie endgültig zu bestätigen. Eine kürzlich geänderte Datei kann ein legitimes Update sein; ein unbekannter Mitarbeiter kann ein ehemaliger Dienstleister sein. Die Aufgabe des Selbstchecks ist es, Ihnen zu sagen, ob Sie genauer hinschauen sollten. Wenn etwas Unerklärliches auftaucht und Sie es nicht zuordnen können, ist genau das der Punkt, an dem sich eine externe Prüfung bezahlt macht, denn die Bestätigung „das ist in Ordnung“ hat denselben Wert wie die Bestätigung „das ist es nicht“.
Wie oft sollte ich den Selbstcheck durchführen?
Die Zehn-Minuten-Version ist unkompliziert genug, um sie quartalsweise durchzuführen, außerdem nach jeder größeren Änderung: einem PrestaShop-Upgrade, einem neuen Zahlungsmodul, einem Theme-Wechsel oder Personalwechsel, der den Adminzugriff betrifft. Die zwei Prüfungen, die Sie besser automatisieren als immer wieder manuell durchführen, sind Datei-Integritätsüberwachung und getestete externe Backups. Sobald diese kontinuierlich laufen, geht es beim Rest vor allem darum zu bestätigen, dass nichts abgedriftet ist.
Kommentare
Noch keine Kommentare. Seien Sie der Erste!
Stellen Sie als Erster eine Frage oder teilen Sie hilfreiches Feedback.
Kommentar schreiben
Teilen Sie eine Frage, ein Installationsdetail oder Feedback, das anderen Lesern helfen kann.