Ihren PrestaShop-Shop absichern: Ein verständlicher Leitfaden für Shop-Betreiber

Ein Online-Shop bedeutet: echtes Geld, echte Kundendaten — und damit bist du ein Ziel. Nicht weil du besonders interessant bist, sondern weil automatisierte Bots rund um die Uhr jede WordPress-, Magento- und PrestaShop-Installation im Netz nach bekannten Schwachstellen absuchen. Die gute Nachricht: Die meisten Angriffe gelingen nur durch grundlegende Fehler — und die lassen sich beheben. Dieser Leitfaden zeigt dir, worauf es wirklich ankommt, und zwar in der richtigen Reihenfolge.

SSL: Du hast es — aber läuft es auch richtig?

Heute hat jeder Shop ein SSL-Zertifikat. Die meisten haben es falsch konfiguriert. Das Schloss-Symbol im Browser bedeutet nur, dass die Seite selbst über HTTPS geladen wurde — nicht, dass dein Shop vollständig verschlüsselt ist. Das eigentliche Problem heißt Mixed Content: Bilder, Skripte oder Stylesheets, die auf einer HTTPS-Seite noch über unverschlüsseltes HTTP geladen werden. Browser blockieren das stillschweigend — ohne klare Fehlermeldung, aber mit defekten Funktionen.

Öffne die Chrome DevTools auf deiner Startseite, geh zur Konsole und suche nach „Mixed Content"-Warnungen. Behebe sie, indem du hartcodierte http://-URLs in deinem Theme, deinen Modulen oder den Datenbankeinstellungen aktualisierst. Überprüfe in PrestaShop unter Shop-Parameter → Allgemein, ob sowohl die Shop-Domain als auch die SSL-Domain auf deine HTTPS-URL verweisen.

Stell außerdem sicher, dass die HTTP-zu-HTTPS-Weiterleitung auf Serverebene funktioniert — nicht nur innerhalb von PrestaShop. Wenn jemand http://yourstore.com aufruft, sollte er schon vor dem Laden von PrestaShop einen 301-Redirect zu https://yourstore.com erhalten. Prüfe deine .htaccess — die Weiterleitungsregel muss vor den PrestaShop-Rewrite-Regeln stehen, nicht mittendrin.

Deine Admin-URL ist kein Geheimnis

Jede Standard-PrestaShop-Installation legt das Admin-Panel unter /admin mit einem zufälligen Suffix ab, das bei der Installation generiert wird. Dieses Suffix ist kein Sicherheitsmerkmal — es ist nur eine kleine Hürde. Bots probieren systematisch gängige Muster durch. Deine Admin-URL ist längst nicht so versteckt, wie du denkst.

Benenne das Admin-Verzeichnis in etwas um, das das Wort „admin" nicht enthält. Wähle etwas Bedeutungsloses — am besten keine Wörter aus dem Wörterbuch. Das hält einen entschlossenen Angreifer mit Dateizugriff nicht auf, aber es eliminiert sofort das automatisierte Massenscanning.

Wenn dein Hosting IP-Whitelisting per .htaccess unterstützt, nutze es. Füge in der .htaccess deines Admin-Ordners eine Require ip-Direktive hinzu, die nur deine Büro- und Heim-IP-Adressen zulässt. Ja, das ist unpraktisch auf Reisen. Ja, es lohnt sich trotzdem.

Mitarbeiter-Accounts: Eine Person, ein Account — keine Ausnahmen

Geteilte Admin-Accounts gehören zu den häufigsten Ursachen von Sicherheitsvorfällen — und sind danach am schwersten aufzuklären. Wenn sich alle Mitarbeiter als „admin" einloggen, gibt es keinen Audit-Trail. Du kannst nicht nachvollziehen, wer ein Produkt gelöscht, einen Preis geändert oder nachts um 2 Uhr die Kundenliste exportiert hat.

Erstelle individuelle Accounts für jede Person mit Backend-Zugriff. Nutze PrestaShops Berechtigungsprofile konsequent: Ein Kundendienstmitarbeiter braucht keinen Zugriff auf Zahlungseinstellungen. Ein Lagermitarbeiter braucht keinen Zugriff auf die Mitarbeiterverwaltung. Das Prinzip der minimalen Rechte ist keine Bürokratie — es begrenzt den Schaden, wenn ein Account kompromittiert wird.

Überprüfe deine Mitarbeiterliste vierteljährlich. Lösche Accounts von Personen, die nicht mehr bei dir arbeiten. Ehemalige Mitarbeiter mit aktiven Zugangsdaten sind ein reales Risiko — und eines, das du vollständig selbst kontrollierst.

Modul-Sicherheit: Die Angriffsfläche, die du ignorierst

Module sind der häufigste Einstiegspunkt für kompromittierte PrestaShop-Shops. Ein verwundbares Modul — auch eines, das du aktiv nicht mehr nutzt — kann ausgenutzt werden, solange es installiert und aktiv ist. Angreifer interessiert es nicht, dass du dieses Zahlungsmodul seit zwei Jahren nicht mehr angefasst hast. Wenn es da ist und eine Lücke hat, ist es eine offene Tür.

Installiere nur Module aus vertrauenswürdigen Quellen. Der PrestaShop Addons Marketplace prüft Einreichungen — zufällige Drittanbieterseiten und GitHub-Repos hingegen nicht. Nulled Module — also kostenpflichtige Module, die illegal kostenlos verbreitet werden — enthalten fast immer Backdoors. Die Logik ist einfach: Warum sollte jemand bezahlte Software verschenken? Weil er etwas hinzugefügt hat.

Entferne Module, die du nicht verwendest. Nicht nur deaktivieren — deinstallieren und die Dateien löschen. Jedes installierte Modul fügt Code hinzu, der bei jeder Anfrage geladen wird, und vergrößert damit sowohl die Angriffsfläche als auch die Ladezeit. Mach ein Modul-Audit: Was du seit sechs Monaten nicht genutzt hast und nicht planst zu nutzen, fliegt raus.

Halte deine Module aktuell. Die meisten Sicherheitslücken in Modulen werden nach ihrer Entdeckung schnell gepatcht — aber der Patch hilft nur, wenn du ihn auch einspielst. Unser Modul Security Revolution enthält eine Dateiintegritätsüberwachung, die unerwartete Änderungen an deinen Moduldateien meldet. Unser Modul Total Defender bietet darüber hinaus aktive Schutzschichten, darunter Bot-Blocking und Protokollierung verdächtiger Aktivitäten.

Datenbank-Backups: Die einzige Garantie für eine Wiederherstellung

Backups sind keine Sicherheitsmaßnahme — sie sind eine Wiederherstellungsmaßnahme. Der Unterschied ist wichtig, weil er deine Denkweise verändert. Keine Backup-Strategie verhindert einen Angriff. Gute Backups sorgen dafür, dass ein Angriff nicht das Ende deines Geschäfts bedeutet.

Automatisiere deine Backups. Manuelle Backups werden übersprungen, verschoben und vergessen. Richte einen Cron-Job ein, der deine Datenbank nächtlich sichert und die Kopie auf einen anderen Server überträgt. „Auf einen anderen Server" bedeutet: an einen Ort, an dem eine Kompromittierung deines Webservers nicht gleichzeitig deine Backups betrifft — ein separater Cloud-Speicher, dein lokaler Rechner, irgendwo außerhalb der Maschine, die potenziell gelöscht werden könnte.

Teste deine Wiederherstellungen. Ein Backup, das du noch nie eingespielt hast, ist kein Backup — es ist eine Datei mit unbekanntem Inhalt. Führe mindestens einmal pro Quartal eine Testwiederherstellung in einer Staging-Umgebung durch. Der erste Restore aus einem Backup sollte nicht während eines echten Vorfalls stattfinden.

Bewahre mehrere Wiederherstellungspunkte auf. Tägliche Backups der letzten 30 Tage, wöchentliche der letzten sechs Monate. Manche Angriffe — insbesondere Datenbankmanipulationen — werden nicht sofort entdeckt. Du musst in der Lage sein, einen Zustand vor dem Beginn des Angriffs wiederherzustellen.

Passwörter und Zwei-Faktor-Authentifizierung

PrestaShop unterstützt Zwei-Faktor-Authentifizierung nativ seit Version 1.7.6. Wenn du sie für deine Admin-Accounts noch nicht nutzt, aktiviere sie jetzt. Die Einrichtung dauert fünf Minuten. Geh in deinem Back Office zu deinem Profil und aktiviere 2FA mit einer Authenticator-App wie Google Authenticator oder Authy.

Mache 2FA für alle Admin-Accounts zur Pflicht — nicht nur für deinen eigenen. Ein Mitarbeiter mit einem schwachen Passwort und ohne 2FA ist das schwächste Glied in deiner Sicherheitskette.

Zu Passwörtern: Nutze einen Passwort-Manager und generiere lange, zufällige Passwörter für jeden Account. „Lang" bedeutet mindestens 20 Zeichen für Admin-Accounts. Wiederhole niemals Passwörter über verschiedene Dienste hinweg. Dein PrestaShop-Admin-Passwort sollte nirgendwo sonst auftauchen — nicht in deinem Hosting-Panel, nicht in deiner E-Mail, nicht in deinem Modul-Marketplace-Account.

Dateirechte: Die Grundlagen zählen

Die korrekten Dateirechte für eine PrestaShop-Installation sind 755 für Verzeichnisse und 644 für Dateien. Wenn du oder dein Hosting-Anbieter Rechte jemals auf 777 gesetzt haben „um ein Problem zu lösen", geh zurück und löse es richtig. World-writable Dateien bedeuten, dass jeder Prozess auf dem Server — einschließlich durch eine Schwachstelle eingeschleuster Code — sie verändern kann.

Überprüfe die Rechte deiner config/settings.inc.php-Datei im Besonderen. Sie enthält deine Datenbankzugangsdaten. Sie sollte 444 oder 640 haben — lesbar für den Webserver, von niemandem schreibbar.

Bei Shared Hosting ist dein Risikoprofil höher, weil du einen Server mit anderen Websites teilst. Eine Kompromittierung einer anderen Website auf deinem Server kann sich potenziell auf deinen Shop auswirken, wenn die Rechte zu offen sind. Das ist ein echtes Argument für VPS statt Shared Hosting für Shops mit realem Transaktionsvolumen.

PrestaShop und PHP aktuell halten

Alte PHP-Versionen sind nicht nur langsamer — sie erhalten auch keine Sicherheits-Patches mehr. PHP 7.4 hat im November 2022 das End-of-Life erreicht. Wenn dein Hoster noch darauf läuft (und viele Shared-Hoster tun das), betreibst du bekannte, ungepatchte Schwachstellen in der Laufzeitumgebung deines Servers. Prüfe deine PHP-Version im PrestaShop Back Office unter Erweiterte Parameter → Informationen.

PrestaShop veröffentlicht Sicherheits-Patches in Minor-Versionen. Wenn du 8.1.0 betreibst, während 8.1.7 verfügbar ist, hast du bekannte Sicherheitslücken. Major-Version-Upgrades erfordern mehr Sorgfalt, aber Minor-Updates innerhalb desselben Zweigs sind in der Regel sicher und sollten nach einem Backup und einem Staging-Test zeitnah eingespielt werden.

.htaccess-Härtung

PrestaShops Standard-.htaccess ist ein Ausgangspunkt — keine fertige Sicherheitskonfiguration. Füge diese Regeln hinzu, um den direkten Zugriff auf Verzeichnisse zu sperren, die niemals öffentlich zugänglich sein sollten:

• Direkten Zugriff auf /config/ sperren — enthält Datenbankzugangsdaten und Verschlüsselungsschlüssel
• Direkten Zugriff auf /var/ sperren — enthält Cache-Dateien und Logs
• Direkten Zugriff auf /vendor/ sperren — enthält Drittanbieter-Bibliotheken
• Direkten Zugriff auf /src/ sperren — enthält Core-Quelldateien
• Ausführung von PHP-Dateien innerhalb von /upload/ blockieren — ein häufiges Ziel für Malware-Uploads

Für das Upload-Verzeichnis speziell: Füge eine .htaccess innerhalb von /upload/ hinzu, die PHP-Ausführung verweigert. Wenn ein Angreifer über eine Datei-Upload-Schwachstelle eine PHP-Shell hochlädt, verhindert diese Regel die Ausführung.

DSGVO und Cookie-Sicherheit

Cookie-Sicherheit ist nicht nur eine Compliance-Frage — falsch konfigurierte Cookies können Session-Tokens und Authentifizierungsdaten preisgeben. Stelle sicher, dass deine Session-Cookies mit dem Secure-Flag (nur über HTTPS übertragen) und dem HttpOnly-Flag (für JavaScript nicht zugänglich) gesetzt sind. Wenn du eine ordentliche DSGVO-konforme Cookie-Consent-Implementierung brauchst, die die Funktionalität deines Shops nicht beeinträchtigt, übernimmt unser Modul Cookies Revolution das korrekt.

Wenn du gehackt wirst: Was jetzt zu tun ist

Erstens: Kein Panik, aber sofort handeln. Jede Stunde Verzögerung bedeutet mehr potenziellen Schaden.

Sofort isolieren. Nimm deinen Shop offline oder versetze ihn in den Wartungsmodus. Wenn dein Hosting eine „Website sperren"-Option hat, nutze sie. Zuerst die Blutung stoppen, dann die Wunde untersuchen.

Noch nichts löschen. Der Instinkt sagt: aufräumen. Aber du musst Beweise sichern, um zu verstehen, was passiert ist. Erstelle zunächst ein vollständiges Backup des kompromittierten Zustands, bevor du Dateien entfernst.

Datei-Änderungsdaten prüfen. Suche nach Dateien, die in den letzten 30 Tagen geändert wurden. Vergleiche mit deiner Deployment-Historie. Dateien, die sich ohne entsprechendes Update geändert haben, sind Anzeichen einer Kompromittierung. Achte besonders auf PHP-Dateien in /upload/, /img/ und Modul-Verzeichnissen — dort werden Datei-Schreibvorgänge erwartet und lassen sich leichter verstecken.

Aus einem sauberen Backup wiederherstellen. Versuche nicht, Malware chirurgisch aus einem laufenden System zu entfernen — Angreifer sind gut darin, Backdoors zu verstecken, und du wirst etwas übersehen. Stelle aus einem Backup wieder her, von dem du sicher bist, dass es vor dem Angriff liegt.

Alle Passwörter ändern. Datenbankpasswort, FTP-Zugangsdaten, Hosting-Panel, PrestaShop-Admin-Accounts, E-Mail-Accounts der Domain. Gehe davon aus, dass während des Angriffs alles lesbar war.

Den Einstiegspunkt finden. Das ist entscheidend, um eine Wiederholung zu verhindern. Häufige Einstiegspunkte: ein verwundbares Modul, kompromittierte Mitarbeiter-Zugangsdaten, ein durch Brute-Force geknacktes Admin-Passwort. Wenn du nicht herausfindest, wie es passiert ist, wird es wieder passieren.

Angemessen benachrichtigen. Wenn Kundendaten zugegriffen wurde — E-Mail-Adressen, Bestellhistorie, Zahlungsdaten — hast du je nach Zuständigkeit wahrscheinlich gesetzliche Meldepflichten. Die DSGVO verlangt eine Meldung innerhalb von 72 Stunden nach Bekanntwerden eines Vorfalls. Schiebe das nicht auf.

Sicherheit ist kein Feature, das man einmal hinzufügt und dann vergisst. Es ist Wartung — wie das Aktualisieren von Inhalten oder die Pflege des Lagerbestands. Setze dir eine vierteljährliche Erinnerung, um Mitarbeiter-Accounts zu prüfen, Modul-Updates zu kontrollieren und sicherzustellen, dass deine Backups tatsächlich wiederherstellbar sind. Zwanzig Minuten alle drei Monate sind viel günstiger als die Bewältigung eines Sicherheitsvorfalls.

Verwandte Artikel

• Zahlungssicherheit in PrestaShop: PCI Compliance, 3D Secure und Betrugsprävention
• PrestaShop Sicherheit haerten: Die vollstaendige Checkliste
• Datenpanne: Was tun, wenn Ihr Shop gehackt wird