Ihren PrestaShop-Shop absichern: ein klarer Leitfaden fuer Shopbetreiber

Wenn Sie einen PrestaShop-Shop betreiben und das Wort "Security" Ihnen kurz den Magen zusammenzieht, ist dieser Leitfaden fuer Sie. Sie muessen kein Entwickler sein. Sie muessen ein paar Ideen gut genug verstehen, um gute Entscheidungen zu treffen — und wissen, welche Aufgaben Sie selbst im Back Office erledigen koennen und welche Sie an einen Entwickler geben sollten. Genau das ist diese Seite: die klare Karte fuer PrestaShop-Shop-Sicherheit, in der Reihenfolge, in der Dinge wirklich zaehlen, mit jedem tieferen Thema zu einem eigenen vollstaendigen Leitfaden verlinkt, damit diese Seite nie zu einer 6.000-Woerter-Wand wird, die Sie nicht zu Ende lesen.

Eine Einordnung vor allem anderen: Sie werden nicht angegriffen, weil Ihr Shop wichtig ist. Sie werden angegriffen, weil ein Bot nicht weiss und nicht kuemmert, was Ihr Shop ist. Automatisierte Scanner durchsuchen das gesamte Internet nach jeder WordPress-, Magento- oder PrestaShop-Installation mit einer bekannten Schwachstelle, so wie ein Einbrecher eine Strasse entlanggeht und jede Türklinke prueft. Fast jeder erfolgreiche Angriff, den wir sehen, fuehrt auf eine grundlegende offene Tuer zurueck — eine alte Version, ein wiederverwendetes Passwort, ein nulled module — nicht auf irgendeinen genialen Hacker. Das ist wirklich gute Nachricht, weil einfache Tueren solche sind, die Sie selbst abschliessen koennen.

Das mentale Modell: Schichten, kein magischer Button

Es gibt keine einzelne Einstellung, die einen PrestaShop-Shop "sichert", und jedes Produkt, das das verspricht, verkauft Ihnen etwas. Echte Sicherheit besteht aus Schichten: Jede faengt ab, was die darueberliegende verpasst. Denken Sie daran wie bei Ihrem physischen Geschaeft — Tuer abschliessen, Kasse nachts leeren, Versicherung, Kamera. Keine einzelne Sache ist die Antwort; zusammen bedeuten sie, dass ein Fehler Sie nicht beendet.

Bei einem PrestaShop-Shop stapeln sich die Schichten ungefaehr so, und es hilft zu wissen, welche welche ist:

Beachten Sie, dass "wiederherstellen koennen" auf der Liste steht. Security-Leute sagen: Es geht nicht um ob, sondern um wann. Ein Shop, der in einer Stunde vollstaendig aus einem sauberen Backup wiederhergestellt werden kann, ist in einer voellig anderen Lage als einer, der das nicht kann — egal wie gut seine Abwehr ist. Wenn die Recovery-Schicht stimmt, wird jeder andere Fehler ueberlebbar.

Starten Sie hier: die fuenf Dinge, die die meisten Angriffe stoppen

Wenn Sie nur fuenf Dinge tun, tun Sie diese. Sie stehen in der Reihenfolge des Return-on-effort, und jedes einzelne kann ein nicht-technischer Betreiber ohne Entwickler erledigen.

1. Aktualisieren Sie PrestaShop, PHP und Ihre Module

Das ist langweilig und die wichtigste Gewohnheit ueberhaupt. Alte Software bekommt keine Security Patches mehr, also bleiben bekannte Loecher offen. PrestaShop liefert Sicherheitsfixes in Minor-Versionen aus — 8.1.0 zu betreiben, wenn 8.1.7 existiert, heisst, mit oeffentlich dokumentierten Loechern zu laufen, die Bots bereits finden koennen. Pruefen Sie Ihre PHP-Version im Back Office unter Advanced Parameters → Information; wenn dort eine End-of-life-Version wie 7.4 steht, bitten Sie Ihren Host um ein Upgrade. Minor Updates innerhalb desselben Branches (zum Beispiel 8.1.x auf 8.1.x) sind nach Backup und Staging-Test meist sicher. Module zaehlen genauso — ein verwundbares Modul ist der haeufigste Einstiegspunkt ueberhaupt.

Wenn Sie auf einer aelteren PrestaShop-Version festhaengen, die Sie gerade nicht sicher upgraden koennen — eine reale Situation fuer viele etablierte Shops —, gibt es Wege, die Luecken ohne Upgrade zu schliessen. Wir behandeln sie in Advanced Hardening fuer Shops, die noch nicht upgraden koennen.

2. Aktivieren Sie Zwei-Faktor-Authentifizierung fuer jeden Admin

PrestaShop bietet in 1.7/8-Installationen keine universelle eingebaute 2FA; ergaenzen Sie sie mit einem serioesen Modul oder einer externen Identity-/Security-Schicht. Das bedeutet: Selbst wenn jemand Ihr Passwort stiehlt, kann er sich ohne den Code auf Ihrem Telefon nicht einloggen. Die Einrichtung dauert mit einer App wie Google Authenticator oder Authy etwa fuenf Minuten. Aktivieren Sie sie fuer jeden Mitarbeiteraccount, nicht nur fuer Ihren — ein Mitarbeiter mit schwachem Passwort und ohne 2FA ist das schwaechste Glied, und Angreifer gehen immer auf das schwaechste Glied. Die komplette Anleitung plus Passwort-Policies fuers Back Office steht in 2FA, Passwort-Policies und Admin Security fuer PrestaShop.

3. Stellen Sie sicher, dass HTTPS wirklich funktioniert

Fast jeder Shop hat heute ein SSL-Zertifikat, aber "Schloss im Browser" heisst nicht "voll sicher". Das Schloss bestaetigt nur, dass die Seite selbst ueber HTTPS geladen wurde — es sagt nichts ueber Bilder oder Scripts, die sich ueber normales http:// einschleichen (Mixed Content, den Browser still blockieren und damit Dinge ohne offensichtlichen Fehler brechen). Es garantiert auch nicht, dass jemand, der Ihre http://-Adresse eingibt, auf die sichere Version umgeleitet wird, bevor PrestaShop ueberhaupt laedt. Beides lohnt sich. Die Schritt-fuer-Schritt-Anleitung — von SSL unter Shop Parameters → General aktivieren bis Mixed Content und Server-Redirect fixen — steht in SSL und HTTPS in PrestaShop einrichten.

4. Eine Person, ein Account — und Least Privilege

Gemeinsame Logins ("alle melden sich als admin an") sind eine der haeufigsten Ursachen fuer Incidents und nachtraeglich am schwersten zu untersuchen, weil Sie keinen Audit Trail haben. Sie koennen nicht sehen, wer einen Preis geaendert, ein Produkt geloescht oder die Kundenliste um 2 Uhr morgens exportiert hat. Erstellen Sie fuer jede Person mit Back-Office-Zugriff einen eigenen Account und nutzen Sie PrestaShops permission profiles (unter Advanced Parameters → Team), damit jede Person nur bekommt, was sie fuer ihre Arbeit braucht. Ein Customer-Service-Mitarbeiter braucht keine Payment Settings; ein Lageroperator braucht kein Employee Management. Das ist keine Buerokratie — es begrenzt den Schaden, wenn ein Account kompromittiert wird. Pruefen Sie die Liste vierteljaehrlich und loeschen Sie Accounts ausgeschiedener Personen.

5. Installieren Sie keine Software, der Sie nicht vertrauen koennen — und entfernen Sie, was Sie nicht nutzen

Module sind die haeufigste Tuer, durch die Angreifer gehen, und ein verwundbares Modul kann ausgenutzt werden, selbst wenn Sie es nicht aktiv nutzen. Zwei Regeln decken den groessten Teil des Risikos ab. Erstens: Installieren Sie nur Module aus Quellen, denen Sie vertrauen — der offizielle PrestaShop Addons Marketplace oder etablierte Entwickler mit echtem Support und Track Record. Nulled modules (bezahlte Module, gecrackt und kostenlos verteilt) enthalten fast immer eine Backdoor; die Oekonomie macht es offensichtlich — niemand verschenkt bezahlte Software aus Freundlichkeit. Zweitens: Entfernen Sie Module, die Sie nicht nutzen. Nicht nur deaktivieren — deaktivierte Module koennen weiterhin erreichbare Dateien auf der Festplatte lassen. Deinstallieren und loeschen Sie ungenutzte Module, um diese Angriffsoberflaeche zu entfernen. Wenn Sie es sechs Monate nicht genutzt haben und nicht nutzen werden, geht es weg.

Die naechste Schicht: Traffic, den Sie nicht wollten

Sobald die Basics abgeschlossen sind, bemerken die meisten Betreiber als Naechstes unerwuenschten Traffic — Bots, die die Login-Seite haemmmern, Scraper, Spam ueber Kontakt- und Review-Formulare, gelegentlich missbraeuchliche Besucher. Dafuer brauchen Sie keinen Entwickler; es ist meist Konfiguration und das richtige Tool.

• Bad Bots und unerwuenschte Crawler. Nicht alle Bots sind schlecht (Googles Bot wollen Sie), also ist das Ziel Filtern, nicht pauschales Blockieren. Die Praxis steht in Visitor Control: Bad Bots und unerwuenschten Traffic blockieren.
• Problematische Einzelpersonen. Wenn es eine konkrete Person ist — Betrueger, Serial Chargeback, missbraeuchlicher Kunde —, wollen Sie Zusatzinfos auf Bestellungen erfassen und per IP sperren. Behandelt in Customer Extra Info und IP Bans.
• Spam in Formularen. Kontaktformulare, Registrierung und Reviews ziehen Bot-Spam an. reCAPTCHA stoppt Bots, ohne echte Kunden durch Reifen springen zu lassen — siehe reCAPTCHA fuer PrestaShop.
• Die Faceted-search-?q=-Flut. Ein technischerer Punkt, den man kennen sollte: Aggressive Crawler koennen PrestaShops Layered-Navigation-Filter in versehentliche Denial-of-service-Last verwandeln. Wenn Ihr Shop unter Bot-Traffic langsam wirkt, lesen Sie die ?q=-Flut ueberleben.

Die Server-Level-Schicht (wo Hilfe sinnvoll sein kann)

Ein Teil des Hardening liegt unterhalb von PrestaShop, auf Webserver- und Dateisystemebene. Sie koennen das selbst tun, aber es ist die Schicht, bei der es am vernuenftigsten ist, Ihren Host oder Entwickler zu fragen, wenn Sie unsicher sind — eine falsche .htaccess-Regel kann eine Seite offline nehmen.

Die Kurzversion: Dateirechte sollten 755 fuer Verzeichnisse und 644 fuer Dateien sein, niemals 777, und die Datei mit Ihrem Datenbankpasswort (app/config/parameters.php in PrestaShop 1.7 und 8 oder config/settings.inc.php in legacy 1.6) sollte noch enger gesperrt sein. Ihre .htaccess sollte direkten oeffentlichen Zugriff auf Ordner wie /app/config/, /var/ und /vendor/ blockieren und PHP-Ausfuehrung in Upload-Ordnern verhindern — damit etwas Boeses, falls es hochgeladen wird, nicht laufen kann. PrestaShops Standard-.htaccess ist ein Ausgangspunkt, keine fertige Konfiguration. Das komplette Regelset, copy-paste-faehig, steht in PrestaShop .htaccess: Security- und Performance-Regeln.

Bei Apache/vhost-Zugriff sollte die Upload-Execution-Regel explizit sein. Die Pfade unten passen zu einem typischen PrestaShop Document Root; passen Sie sie an Ihren Server an.

# Apache: stop uploaded PHP from executing
<Directory "/var/www/html/img">
    php_admin_flag engine off
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/upload">
    php_admin_flag engine off
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

Ein Dashboard ist erst nuetzlich, nachdem die kostenlosen Hardening-Basics erledigt sind.

Wenn Sie verstehen wollen, gegen welche Art Angriff dieses Server-Hardening schuetzt — wie ein realer Card Skimmer auf einen PrestaShop-Shop kommt und Zahlungsdaten stiehlt —, macht die Anleitung in Anatomie eines Magecart-artigen Angriffs das Abstrakte konkret. Einmal lesen lohnt sich, damit der Rest nicht mehr theoretisch wirkt.

Die Recovery-Schicht: Backups, die Sie wirklich getestet haben

Backups sind keine Sicherheitsmassnahme — sie sind eine Wiederherstellungsmassnahme, und dieser Unterschied aendert, wie Sie sie behandeln. Kein Backup stoppt einen Angriff. Gute Backups bedeuten, dass ein Angriff Ihr Business nicht beendet. Drei Gewohnheiten trennen eine echte Backup-Strategie von einem falschen Sicherheitsgefuehl:

• Automatisieren Sie es. Manuelle Backups werden uebersprungen und vergessen. Ein naechtlicher Cronjob, der die Datenbank dumpt und off-server kopiert — an einen Ort, den ein kompromittierter Webserver nicht ebenfalls loeschen kann —, ist die Basis.
• Testen Sie den Restore. Ein Backup, das Sie nie restored haben, ist nur eine Datei mit unbekanntem Inhalt. Restoren Sie einmal pro Quartal auf eine Staging-Seite. Der erste Restore Ihres Lebens sollte nicht waehrend eines Live-Incidents stattfinden.
• Behalten Sie mehrere Restore Points. Taeglich fuer den letzten Monat, woechentlich fuer sechs Monate. Manche Angriffe — besonders stille Datenbankmanipulation — werden erst nach Wochen bemerkt, und Sie brauchen einen Punkt von vor dem Start.

Wenn das Schlimmste passiert

Auch ein gut gesicherter Shop kann kompromittiert werden, und der falsche Instinkt in der ersten Stunde richtet echten Schaden an — Menschen loeschen Dateien (und damit die Beweise, die sie brauchen) oder versuchen Malware chirurgisch zu reinigen, die sie nie vollstaendig finden werden. Es gibt eine richtige Reihenfolge: isolieren, erhalten, Einstiegspunkt identifizieren, aus sauberem Backup wiederherstellen, alle Zugangsdaten rotieren und Benachrichtigungspflichten erfuellen (DSGVO verlangt Meldung innerhalb von 72 Stunden nach Bekanntwerden eines Breach mit personenbezogenen Daten). Versuchen Sie nicht, sich das unter Druck zu merken — wir haben das ruhige Schritt-fuer-Schritt-Playbook geschrieben, damit Sie es befolgen koennen, wenn es zaehlt: was tun, wenn Ihr Shop gehackt wird.

Wo mypresta.rocks-Module hineinpassen

Das meiste auf dieser Seite kostet nichts ausser Aufmerksamkeit — Updates, 2FA, sinnvolle Rechte, echte Backups. Ein Modul verdient seinen Platz dort, wo Aufgaben muhsam oder von Hand unmoeglich sind: Ihre Dateien kontinuierlich auf Aenderungen beobachten, die Sie nicht gemacht haben, feindlichen Traffic in Echtzeit filtern und Cookie-/Consent-Handling korrekt halten, ohne die Storefront zu brechen. Unsere Security-Module existieren, um genau diese Jobs zu automatisieren, damit Sie sie nicht um Mitternacht manuell machen — der Nutzen ist eine Sache weniger, die ein nicht-technischer Betreiber ueberwachen muss, und Aenderungen, die Sie sonst verpassen wuerden, erscheinen im Dashboard statt im Incident Report. Sie sind eine Schicht ueber den kostenlosen Grundlagen hier, kein Ersatz fuer sie. Schliessen Sie zuerst die kostenlosen Tueren; greifen Sie zu Tooling fuer die Teile, die wirklich rund um die Uhr beobachtet werden muessen.

Die eine Gewohnheit, die alles zusammenhaelt

Security ist kein Feature, das Sie einmal einschalten und vergessen — es ist Wartung, wie Ihren Katalog korrekt oder Lagerbestaende ehrlich zu halten. Betreiber, die aus Schwierigkeiten herausbleiben, sind nicht die, die die meiste Software gekauft haben; es sind die, die sich eine wiederkehrende Erinnerung setzen. Einmal pro Quartal, zwanzig Minuten: bestaetigen, dass PrestaShop und Module aktuell sind, pruefen, dass 2FA fuer alle aktiv ist, Ex-Mitarbeiter-Accounts entfernen und — am wichtigsten — verifizieren, dass ein Backup wirklich restored. Zwanzig Minuten alle drei Monate sind dramatisch billiger als die Erholung von einem Breach, und sie machen das ganze Thema von einer Quelle der Angst zu einer Routine, an die Sie kaum denken.

Wenn Sie denselben Bereich lieber als abhakbare Liste haben wollen, die Sie direkt durcharbeiten koennen, statt als gefuehrte Tour, ist der Begleiter die vollstaendige PrestaShop Security Hardening Checklist. Starten Sie dort, wenn Sie die Konzepte schon kennen und nur sicherstellen wollen, dass nichts fehlt.