So auditieren Sie Ihren PrestaShop-Shop selbst — kostenloses Security-Scan-Modul

Zwei Wege, Ihren Shop zu prüfen

Für einen schnellen Überblick in Sekunden nutzen Sie unseren öffentlichen Security Scanner: Geben Sie Ihre Shop-URL ein, und er ermittelt passiv Ihre PrestaShop- und PHP-Versionen, prüft, ob diese Version öffentlich sichtbar oder End-of-Life ist, und untersucht Ihre HTTPS-Security-Header — keine Installation, nichts zu konfigurieren. Er liest nur, was jeder Besucher ohnehin sieht.

Genau das ist auch seine Grenze. Ein öffentlicher Check kann nicht erkennen, welche Modulversionen Sie tatsächlich einsetzen, wie Ihre Dateiberechtigungen aussehen, ob der Debug-Modus aktiv ist oder ob ein Backup als .sql in Ihrem Webroot liegt — und gerade diese letzte Kategorie ist der häufigste Grund, warum PrestaShop-Shops gehackt werden. Installieren Sie dafür das kostenlose Security Scan-Modul: Es scannt Ihren Shop von innen, wo die Einwilligung eingebaut ist, denn es ist Ihr Shop. Dieser Leitfaden zeigt Ihnen, wie Sie den Scan ausführen, wie Sie den Bericht lesen und — mit echten Befehlen — wie Sie die Funde beheben. Als tiefgehende Hardening-Referenz geht unsere begleitende PrestaShop-Security-Hardening-Checkliste noch weiter.

Was ein lokaler Scan prüft

Der Bericht ist nach Bereichen gruppiert — zuerst die bestätigten Prüfungen (Versionen, exponierte Dateien), danach die heuristischen (Malware und Code), die klar gekennzeichnet sind. Jeder Fund erklärt, was gefunden wurde, warum es wichtig ist und wie Sie es beheben.

Die Gruppen Malware und Code sind bewusst heuristisch — fundierte Vermutungen, die gelegentlich etwas Harmloses markieren. Wir zeigen Ihnen lieber einen False Positive, den Sie in zehn Sekunden verwerfen können, als eine Web-Shell stillschweigend zu übersehen.

Jeder Fund ist überprüfbar. Jeder Versions- und CVE-Treffer verlinkt direkt auf das offizielle Advisory — den CVE-Eintrag oder das GitHub Security Advisory des Herstellers — und trägt eine Vertrauensstufe, sodass Sie jede Markierung selbst nachprüfen können, statt uns einfach zu glauben. Wo der Scanner etwas nur ableiten kann oder eine Einstellung von außen nicht bestätigen kann, sagt er das klar und bewertet es niedrig. Er ist auf Genauigkeit ausgelegt, nicht auf Alarmismus.

So führen Sie den Scan aus

Installieren und aktivieren Sie das kostenlose Security Scan-Modul, öffnen Sie dann Konfigurieren → Security Scan → Scan & Report und klicken Sie auf Run scan now. Ein typischer Scan dauert wenige Sekunden. Die Prüfungen lesen nur die Dateien, Konfiguration und Datenbank Ihres Shops sowie Ihre eigenen öffentlichen URLs; das Modul schreibt lediglich seinen eigenen Scan-Verlaufseintrag und verändert daher niemals Shop-Dateien, Einstellungen, Produkte, Bestellungen oder Kunden — sicher auch im Live-Shop.

Bevorzugen Sie die Kommandozeile oder möchten Sie es automatisieren? Sie können denselben lokalen Scan aus einem gebootstrappten PrestaShop-Kontext auslösen (der Guard verhindert die Ausführung über das Web, falls Sie die Datei liegen lassen):

<?php
// scan-now.php — run from the CLI only; delete the file if you place it in the shop root
if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit;
}

require __DIR__ . '/config/config.inc.php';
require __DIR__ . '/modules/mprsecurityscan/vendor/autoload.php';

$run = \MPRSecurityScan\Service\ScanRunner::runAndStore('manual');
printf("Score %d/100 (grade %s) — %d issues\n",
    $run['result']['score'], $run['result']['grade'], $run['result']['problem_count']);

So lesen Sie Ihren Score

Sie erhalten eine einzelne Zahl von 100 und eine Buchstabennote. Der Score startet bei 100 und verliert Punkte pro echtem Problem, gewichtet nach Schweregrad — ein kritisches Problem kostet deutlich mehr als ein niedriges. Bestandene Prüfungen werden ebenfalls angezeigt, damit Sie sehen, was tatsächlich verifiziert wurde.

• Kritisch −30 pro Fund — jetzt ausnutzbar oder eine bestätigte Exposition. Noch heute beheben.
• Hoch −15 — ernst; diese Woche beheben.
• Mittel −7 — relevante Lücken bei Hardening oder Hygiene.
• Niedrig −3 — kleinere Verbesserungen.

Daraus ergibt sich eine Note — A 90+, B 75+, C 60+, D 40+, F unter 40. Betrachten Sie den Score als Priorisierungswerkzeug, nicht als Garantie: Ein hoher Score bedeutet, dass der Scanner in dem, was er sehen kann, keine bekannten Probleme gefunden hat.

Praxisbeispiel: ein exponiertes .git-Verzeichnis

Dies ist einer der häufigsten — und gefährlichsten — Funde. Wenn Sie per git clone oder git pull in Ihr Webroot deployt haben, kann der gesamte .git-Ordner (mit Ihrer kompletten Quellhistorie und allen jemals committeten Geheimnissen) herunterladbar sein. Der Scanner bestätigt das, indem er tatsächlich /.git/HEAD über HTTP anfragt und prüft, ob die Antwort wie VCS-Metadaten aussieht.

Kritisch — VCS-Metadaten sind öffentlich erreichbar. Der Scanner hat bestätigt, dass /.git/HEAD VCS-Metadaten über HTTP zurückliefert.

Beheben Sie es in zwei Schritten. Sichern Sie zuerst, aus Ihrem Shop-Root, die Metadaten und entfernen Sie sie (die Guards stellen sicher, dass nichts gelöscht wird, solange das Backup nicht erfolgreich war):

# run from your shop root
set -eu

paths=()
[ -d .git ] && paths+=(.git)
[ -d .svn ] && paths+=(.svn)

if [ "${#paths[@]}" -gt 0 ]; then
  tar czf "$HOME/vcs-metadata-backup-$(date +%F-%H%M%S).tgz" "${paths[@]}"
  rm -rf "${paths[@]}"
fi

Sorgen Sie dann dafür, dass der Webserver Punkt-Verzeichnisse verweigert, selbst wenn eines wieder auftaucht. Apache (.htaccess oder vhost) — dies blockiert Punkt-Dateien und Punkt-Verzeichnispfade wie /.git/HEAD, während /.well-known/ erhalten bleibt:

<FilesMatch "^\.">
  Require all denied
</FilesMatch>

RedirectMatch 404 "(^|/)\.(?!well-known(?:/|$))"

Oder nginx:

location ^~ /.well-known/ {
    try_files $uri =404;
}

location ~ /\.(?!well-known(?:/|$)) {
    return 404;
}

Führen Sie den Scan erneut aus; der Fund sollte verschwinden (die URL liefert jetzt 403/404). Falls jemals ein Geheimnis in dieser Historie lag, rotieren Sie es.

Was Sie zuerst beheben sollten (mit den Befehlen)

Arbeiten Sie den Bericht von oben nach unten ab. Hier sind die Korrekturen für die Funde, die Ihnen am häufigsten begegnen werden.

Backup-Archive im Webroot

Eine store.sql oder backup.zip neben der index.php ist eine vollständige Kopie Ihres Shops, nur einen Rateversuch entfernt. Listen Sie sie auf und verschieben Sie dann jeden Treffer aus dem Docroot (mv -n überschreibt niemals):

# review the list first
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) -ls

# then move every match out of the webroot
mkdir -p "$HOME/private-backups"
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) \
  -exec mv -n -- {} "$HOME/private-backups/" \;

Übrig gebliebenes /install-Verzeichnis

PrestaShop fordert Sie auf, dieses nach der Einrichtung zu löschen. Statt es direkt zu löschen, stellen Sie es unter Quarantäne (aus Ihrem Shop-Root ausführen):

# run from your shop root
set -eu
test -f config/config.inc.php

backup="$HOME/prestashop-install-dirs-$(date +%F-%H%M%S)"
mkdir -p "$backup"
[ -d install ] && mv install "$backup/"
[ -d install-dev ] && mv install-dev "$backup/"

Debug-Modus noch aktiv

Der Entwicklermodus gibt Stack-Traces und Pfade an Besucher preis. Bearbeiten Sie die vorhandene Zeile in config/defines.inc.php (oder config/defines_custom.inc.php) — fügen Sie keine zweite darunter hinzu:

<?php
// change the EXISTING _PS_MODE_DEV_ line to false (never true on a live shop)
define('_PS_MODE_DEV_', false);

Weltweit beschreibbare Ordner (0777)

Der Scanner markiert Verzeichnisse mit 0777. Stellen Sie Least-Privilege-Berechtigungen wieder her — niemals chmod 777, und halten Sie die geheimen Konfigurationsdateien unlesbar (eine weltweit lesbare parameters.php ist selbst ein Fund). Aus Ihrem Shop-Root ausführen:

# run from your shop root; set these to your real PHP-FPM/web user + group
WEB_USER=www-data
WEB_GROUP=www-data

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

# lock down the secret config files: owned by the web user, readable by owner+group only
# (never world-readable — but still readable by the PHP process). Adjust owner/group above.
for f in app/config/parameters.php config/settings.inc.php; do
  [ -f "$f" ] || continue
  chown "$WEB_USER:$WEB_GROUP" "$f"
  chmod 640 "$f"
done

# only the writable dirs need to be owned by the web user
for dir in var/cache var/logs img upload download; do
  [ -d "$dir" ] || continue
  chown -R "$WEB_USER:$WEB_GROUP" "$dir"
  find "$dir" -type d -exec chmod 775 {} \;
  find "$dir" -type f -exec chmod 664 {} \;
done

Schwache oder fehlende .htaccess

Generieren Sie die Schutzregeln von PrestaShop im Back Office neu (Shop-Parameter → Traffic & SEO → .htaccess neu generieren) und prüfen Sie anschließend, dass sensible Dateien blockiert sind und das Directory-Listing aus ist. Ein minimaler Schutz:

<FilesMatch "(?i)(parameters\.php|settings\.inc\.php|\.env|composer\.(json|lock))$">
  Require all denied
</FilesMatch>

Options -Indexes

Grenzen der reinen Erkennung

Zur guten Nutzung jedes Sicherheitswerkzeugs gehört Ehrlichkeit über seine Grenzen: Es erkennt Probleme, behebt sie aber nicht für Sie; die heuristischen Prüfungen können Harmloses markieren (vor dem Löschen verifizieren); die Advisory-Abdeckung ist kuratiert, nicht erschöpfend; und es ist kein Penetrationstest. Für die vollständige Behebungsreferenz — Server-Hardening, Admin-Absicherung, Datenbank und Monitoring — folgen Sie der Security-Hardening-Checkliste.

Wann Sie aufhören sollten zu scannen und sich Hilfe holen

Manche Funde bedeuten: Jetzt braucht es einen Menschen, kein Werkzeug. Malware-artige Dateien, alles, was wie ein Payment-Skimmer aussieht, Admin-Konten, die Sie nicht kennen, exponierte Zugangsdaten oder wiederholte Neuinfektionen — das ist ein Sicherheitsvorfall. Wenn Sie es lieber uns übergeben möchten, buchen Sie ein Security-Audit.

Wann automatische Korrekturen sinnvoll sind

Der kostenlose Scanner ist bewusst ein Einmal-Werkzeug: Sie führen ihn aus, lesen den Bericht und beheben die Dinge von Hand. Perfekt für den gelegentlichen Check-up. Wenn Sie das lieber nicht manuell tun — oder dauerhaft abgesichert bleiben möchten — wendet Security Revolution Ein-Klick-Korrekturen an, härtet Ihren Shop, überwacht die Integrität der Core-Dateien, alarmiert Sie bei Änderungen und verwaltet eine ganze Flotte von Shops über ein Dashboard. Dieselben Funde; es handelt nur danach und wacht weiter.

FAQ

Sendet der Scan meine Daten irgendwohin? Bei einem eigenständigen Dashboard- oder CLI-Scan nein — der Bericht bleibt auf Ihrem Server, und die einzigen ausgehenden Anfragen sind Selbstprüfungen Ihrer eigenen öffentlichen URLs, abgesichert gegen Zugriffe auf interne Adressen (SSRF). Wenn Sie den optionalen Fleet-Connector ausdrücklich aktivieren, werden Scan-Ergebnisse — über einen signierten Kanal — an den von Ihnen konfigurierten Hub gesendet.

Behebt es Probleme automatisch? Nein — dieses Modul ist reine Erkennung. Automatische Korrekturen und Monitoring stecken in Security Revolution.

Ist es im Live-Shop sicher? Ja. Es liest Ihre Dateien, Konfiguration und Datenbank und schreibt nur seinen eigenen Scan-Verlaufseintrag — es verändert niemals Shop-Inhalte, Einstellungen, Produkte, Bestellungen oder Kunden.

Wie oft sollte ich scannen? Nach jedem PrestaShop- oder Modul-Update und mindestens monatlich. Die Verlaufsseite verfolgt Ihren Score über die Zeit.

Kann es einen Entwickler ersetzen? Nein. Es ist ein schneller, nützlicher erster Durchgang, der häufige, wohlbekannte Risiken erwischt. Tiefe Audits und echte Vorfälle brauchen weiterhin einen Menschen.

Weiterführende Lektüre

• PrestaShop Security Hardening: Die komplette Checkliste — der Behebungs-Begleiter zu dieser Seite.
• Security Scan — das hier beschriebene kostenlose Modul.
• Security Revolution — automatische Korrekturen, Hardening und Datei-Integritätsüberwachung.