Anleitungen Guide

PrestaShop-Sicherheit: Die vollständige Checkliste

Umfassender Sicherheitsleitfaden für PrestaShop — Server-Härtung, Admin-Schutz, Modul-Audits, Datenbanksicherheit und Notfallreaktion.

PrestaShop-Sicherheit härten: Die vollständige Checkliste

Jede Woche werden Tausende von PrestaShop-Shops kompromittiert. Shopbetreiber erfahren davon, wenn Google ihre Seite markiert, wenn Kunden gestohlene Karten melden oder wenn die Startseite auf Spam weiterleitet. Der Schaden ist real: entgangener Umsatz, zerstörtes Vertrauen, DSGVO-Haftung und wochenlange Aufräumarbeiten.

Dieser Leitfaden basiert auf jahrelanger Erfahrung mit der Bereinigung gehackter Shops. Jede Empfehlung adressiert eine reale Schwachstelle, die wir in Produktivumgebungen ausgenutzt gesehen haben. Arbeiten Sie ihn von oben nach unten durch. Lesen Sie auch unseren Sicherheitsleitfaden.

1. Warum PrestaShop-Shops gehackt werden

SQL-Injection in Drittanbieter-Modulen

Dies ist der häufigste Angriffsvektor – und es ist nicht einmal knapp. Module von unerfahrenen Entwicklern übergeben Benutzereingaben oft direkt an SQL-Abfragen. Ein Angreifer sendet eine manipulierte Anfrage an den Front-Controller eines Moduls und extrahiert Ihre gesamte Datenbank. Die Schwachstelle liegt fast nie im PrestaShop-Core – sie steckt in den Modulen.

Brute-Force-Angriffe auf das Admin-Panel

PrestaShop verfügt über keine integrierte Ratenbegrenzung. Ein Angreifer, der den Namen Ihres Admin-Verzeichnisses kennt, kann Tausende von Passwortkombinationen pro Minute durchprobieren. Jedes Konto, das admin123 oder den Firmennamen verwendet, wird innerhalb von Minuten geknackt.

Sicherheitslücken beim Datei-Upload

Einige Module erlauben Datei-Uploads ohne ausreichende Validierung. Ein Angreifer lädt eine als Bild getarnte PHP-Shell hoch, ruft sie über den Browser auf und erlangt die volle Kontrolle über den Server.

Veraltetes PHP und veraltete Software

PHP-Versionen, die ihr Lebensende erreicht haben, weisen öffentlich dokumentierte Schwachstellen mit funktionierenden Exploits auf. Dasselbe gilt für veraltete Versionen von PrestaShop, Apache und MySQL.

Offenliegende Konfigurationsdateien

Fehlkonfigurierte Server liefern .env-Dateien, .git-Verzeichnisse und YAML-Konfigurationen an jeden aus, der sie anfordert – und legen damit Datenbank-Zugangsdaten und Verschlüsselungsgeheimnisse offen.

Realitätscheck: Die meisten Shopbetreiber denken „Mein Shop ist zu klein, um ein Ziel zu sein.“ Automatisierte Scanner interessieren sich nicht für die Größe. Sie scannen jede IP-Adresse im Internet. Wenn Sie PrestaShop betreiben, sind Sie ein Ziel.

2. Sicherheit auf Server-Ebene

PHP-Version und Konfiguration

Verwenden Sie die neüste PHP-Version, die Ihr PrestaShop unterstützt – PHP 8.1+ für PS 8.x, PHP 8.1-8.4 für PS 9.x. Betreiben Sie niemals eine Version, die ihr Lebensende erreicht hat.

Wichtige php.ini-Härtungsmaßnahmen:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen
expose_php = Off
allow_url_include = Off
display_errors = Off
log_errors = On
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.cookie_samesite = Lax
open_basedir = /var/www/html:/tmp:/usr/share/php
Hinweis: Einige Module benötigen exec() für Bildverarbeitung oder PDF-Erzeugung. Falls ein Modul nicht mehr funktioniert, aktivieren Sie nur die spezifische Funktion wieder, die es benötigt.

Dateiberechtigungen

  • Verzeichnisse: 755 – Eigentümer lesen/schreiben/ausführen, andere lesen/ausführen
  • Dateien: 644 – Eigentümer lesen/schreiben, andere nur lesen
  • Konfigurationsdateien: 400 – app/config/parameters.php sollte nur für den Eigentümer lesbar sein
chown -R www-data:www-data /var/www/html/prestashop
find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chmod 400 /var/www/html/prestashop/app/config/parameters.php

# Writable directories PrestaShop needs
chmod -R 775 /var/www/html/prestashop/var/cache
chmod -R 775 /var/www/html/prestashop/var/logs
chmod -R 775 /var/www/html/prestashop/img
chmod -R 775 /var/www/html/prestashop/upload
chmod -R 775 /var/www/html/prestashop/download

Setzen Sie niemals etwas auf 777. Wenn ein Tutorial Ihnen sagt, chmod 777 auszuführen, suchen Sie sich ein besseres Tutorial.

SSL/TLS-Konfiguration

Aktivieren Sie SSL in PrestaShop (Shopparameter > Allgemein) und fügen Sie dann HSTS-Header hinzu:

# Apache .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Nginx
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$reqüst_uri;
}
server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Verzeichnislisting deaktivieren und .htaccess härten

Fügen Sie diese Regeln in Ihre Root-.htaccess ein:

Options -Indexes

# Block sensitive file types
<FilesMatch "\.(env|yml|yaml|log|sql|bak|old|orig|save|swp|dist|config|ini|phps)$">
    Require all denied
</FilesMatch>

# Block hidden files and directories (.git, .env, etc.)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule (^\.|/\.) - [F]
</IfModule>

# Block composer files
<FilesMatch "^(composer\.json|composer\.lock)$">
    Require all denied
</FilesMatch>

# Block config, vendor, and log directories
<IfModule mod_rewrite.c>
    RewriteRule ^config/ - [F]
    RewriteRule ^vendor/ - [F]
    RewriteRule ^var/logs/ - [F]
    RewriteRule ^app/config/ - [F]
</IfModule>

# Block PHP execution in upload directories
<Directory "/var/www/html/prestashop/upload">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/prestashop/img">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

Nginx-Entsprechung:

location ~* \.(env|yml|yaml|log|sql|bak|old|swp|dist|config|ini)$ { deny all; return 404; }
location ~ /\. { deny all; return 404; }
location ~* ^/(upload|img|download)/.*\.php$ { deny all; return 404; }
location ~* ^/(config|vendor|var/logs|app/config)/ { deny all; return 404; }
autoindex off;
Testen Sie es: Versuchen Sie nach dem Hinzufügen dieser Regeln, https://ihrshop.com/.env und https://ihrshop.com/app/config/parameters.php in Ihrem Browser aufzurufen. Sie sollten einen 403- oder 404-Fehler erhalten – niemals den tatsächlichen Inhalt.

3. PrestaShop-Admin-Sicherheit

Admin-Verzeichnis umbenennen

PrestaShop generiert bei der Installation einen zufälligen Namen für das Admin-Verzeichnis. Benennen Sie es niemals in admin, backoffice oder panel um. Falls er vorhersehbar ist, ändern Sie ihn:

mv /var/www/html/prestashop/admin /var/www/html/prestashop/admin-x7k9m2p4
rm -rf /var/www/html/prestashop/var/cache/*

Verwenden Sie mindestens 10 zufällige Zeichen. Setzen Sie ein Lesezeichen für die URL – sie muss nicht einprägsam sein.

Starke Passwörter und 2FA

Jedes Admin-Konto muss ein einzigartiges Passwort mit mindestens 16 Zeichen aus einem Passwort-Manager verwenden. Ohne Ausnahme.

Aktivieren Sie die Zwei-Faktor-Authentifizierung für alle Konten (Erweiterte Einstellungen > Verwaltung). PrestaShop 1.7.6+ unterstützt Google Authenticator nativ. Diese einzelne Maßnahme stoppt die überwiegende Mehrheit der Brute-Force-Angriffe.

Admin-Zugang per IP einschränken

Wenn Ihr Team von festen IP-Adressen aus arbeitet, schränken Sie den Admin-Zugang entsprechend ein:

# .htaccess inside admin directory
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
    RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.20$
    RewriteRule .* - [F,L]
</IfModule>

Wenn Sie ein VPN verwenden, beschränken Sie den Zugang auf die VPN-IP – Mitarbeiter können von überall aus arbeiten und bleiben trotzdem IP-beschränkt.

Unnötige Mitarbeiterkonten deaktivieren

Überprüfen Sie die Mitarbeiterkonten regelmäßig (Erweiterte Einstellungen > Team > Mitarbeiter):

  • Löschen Sie Konten ehemaliger Mitarbeiter und externer Auftragnehmer
  • Entfernen Sie Testkonten aus der Ersteinrichtung
  • Stellen Sie sicher, dass jeder Mitarbeiter das minimal notwendige Profil hat – Lagerpersonal benötigt keinen SuperAdmin-Zugang

Überwachung der Admin-Anmeldungen

Richten Sie fail2ban für den Brute-Force-Schutz ein:

# /etc/fail2ban/filter.d/prestashop-admin.conf
[Definition]
failregex = ^<HOST> -.*"POST .*/admin.*/index\.php\?controller=AdminLogin.*" (200|302)

# /etc/fail2ban/jail.d/prestashop.conf
[prestashop-admin]
enabled = true
filter = prestashop-admin
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 600
bantime = 3600

4. Modul-Sicherheit

Module sind die größte Angriffsfläche in jeder PrestaShop-Installation. Betrachten Sie jedes Modul als potenzielles Risiko, bis das Gegenteil bewiesen ist.

Nur aus vertraünswürdigen Quellen installieren

Sichere Quellen: PrestaShop Addons Marketplace, etablierte Entwickler mit nachgewiesener Erfolgsbilanz und gut gepflegte Open-Source-Module auf GitHub.

Installieren Sie niemals Module von „Nulled“- oder „Gratis-Download“-Seiten, unbekannten Entwicklern oder zufälligen Forenbeiträgen.

Warnung: Nulled (raubkopierte) Module sind der schnellste Weg, gehackt zu werden. Angreifer schleusen Hintertüren in legitime Module ein und verbreiten sie kostenlos. Die Hintertür gibt ihnen die Kontrolle über jeden Shop, der das Modul installiert. Wir haben das hundertfach beobachtet. Es gibt keine Ausnahmen.

Modul-Code prüfen

Suchen Sie vor der Installation eines Moduls nach diesen Warnsignalen:

# Dangerous — arbitrary code execution
eval($variable)
eval(base64_decode($something))
assert($user_input)

# Dangerous — remote code loading
file_get_contents('http://external-domain.com/...')
include('http://...')

# Dangerous — unsanitized SQL
"SELECT * FROM ps_table WHERE id = " . $_GET['id']
Db::getInstance()->execute("... " . $_POST['value'] . " ...")

Sicherer Code verwendet parametrisierte Abfragen und die Validierungsmethoden von PrestaShop:

// SAFE: Cast to integer, use pSQL()
$id = (int)Tools::getValue('id');
$name = pSQL(Tools::getValue('name'));

Module aktuell halten

  • Prüfen Sie mindestens wöchentlich auf Updates
  • Abonnieren Sie die Sicherheitsbulletins der Entwickler
  • Verfolgen Sie die Friends of Presta Sicherheitshinweise für PrestaShop-Modul-CVEs
  • Erstellen Sie immer ein Backup vor dem Update

Unbenutzte Module vollständig entfernen

Ein Modul nur zu deaktivieren reicht nicht aus. Die Dateien eines deaktivierten Moduls existieren weiterhin auf Ihrem Server und seine Front-Controller bleiben über direkte URL erreichbar. Wenn es eine Schwachstelle hat, bietet die Deaktivierung keinerlei Schutz.

# Uninstall via Back Office, then delete the files
rm -rf /var/www/html/prestashop/modules/unused_module

Gehen Sie jetzt Ihre Modulliste durch. Wenn Sie vor sechs Monaten etwas zum Testen installiert haben – löschen Sie es. Jedes ungenutzte Modul ist unnötige Angriffsfläche.

Modul-Berechtigungen prüfen

find /var/www/html/prestashop/modules -type d -exec chmod 755 {} \;
find /var/www/html/prestashop/modules -type f -exec chmod 644 {} \;

5. Datenbank-Sicherheit

Niemals Root für die Anwendung verwenden

Erstellen Sie einen dedizierten Benutzer mit minimalen Berechtigungen:

CREATE USER 'prestashop_user'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES
      ON prestashop_db.* TO 'prestashop_user'@'localhost';
FLUSH PRIVILEGES;

Wenn ein Angreifer eine SQL-Injection ausnutzt, begrenzt ein eingeschränkter Benutzer den Schaden. Root kann auf andere Datenbanken zugreifen, Serverdateien lesen und Systembefehle ausführen.

Regelmäßige Backups

# Crontab entries
# Database backup — daily at 3 AM
0 3 * * * mysqldump -u backup_user -p'password' prestashop_db | gzip > /backups/db/ps_$(date +\%Y\%m\%d).sql.gz

# File backup — daily at 3:30 AM
30 3 * * * tar -czf /backups/files/ps_files_$(date +\%Y\%m\%d).tar.gz /var/www/html/prestashop/

# Cleanup backups older than 30 days
0 4 * * * find /backups/ -name "*.gz" -mtime +30 -delete

Wichtige Regeln:

  • Backups außerhalb des Servers speichern – wenn der Server kompromittiert wird, sind lokale Backups es auch
  • Backups monatlich testen – stellen Sie sie in einer Testumgebung wieder her und prüfen Sie, ob die Seite funktioniert
  • Vor der externen Übertragung verschlüsseln – Dumps enthalten personenbezogene Kundendaten
  • Mindestens 30 Tage tägliche Backups aufbewahren – manche Kompromittierungen werden nicht sofort entdeckt

phpMyAdmin absichern (oder entfernen)

Die sicherste Option: Installieren Sie phpMyAdmin nicht auf dem Produktivserver. Verwenden Sie stattdessen SSH-Tunnel:

# From your LOCAL machine
ssh -L 3307:localhost:3306 user@yourserver.com
# Then connect your local MySQL client to localhost:3307

Falls Sie phpMyAdmin betreiben müssen: Schränken Sie den Zugriff per IP ein, verwenden Sie einen zufälligen URL-Pfad, aktivieren Sie HTTP Basic Auth und deaktivieren Sie den Root-Login:

$cfg['Servers'][$i]['AllowRoot'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

6. Überwachung und Erkennung

Dateiintegritätsüberwachung

Angreifer verändern Dateien – sie schleusen Hintertüren ein, fügen Shells in Upload-Verzeichnisse ein oder ändern die .htaccess. Erkennen Sie Änderungen mit einem täglichen Cron-Job:

#!/bin/bash
# /usr/local/bin/prestashop-integrity-check.sh
SHOP_DIR="/var/www/html/prestashop"
BASELINE="/var/backups/prestashop-file-hashes.txt"
CURRENT="/tmp/prestashop-file-hashes-current.txt"
ALERT_EMAIL="admin@yourdomain.com"

find "$SHOP_DIR" -type f \
    -not -path "*/var/cache/*" \
    -not -path "*/var/logs/*" \
    -not -path "*/img/p/*" \
    -not -path "*/img/c/*" \
    -exec md5sum {} \; | sort > "$CURRENT"

if [ -f "$BASELINE" ]; then
    DIFF=$(diff "$BASELINE" "$CURRENT")
    if [ -n "$DIFF" ]; then
        echo "$DIFF" | mail -s "ALERT: PrestaShop files modified" "$ALERT_EMAIL"
    fi
fi

Erstellen Sie die Baseline nach einem sauberen Deployment – dann benachrichtigt Sie dieses Skript per E-Mail, sobald Dateien unerwartet geändert werden.

Log-Überwachung

Durchsuchen Sie Zugriffsprotokolle nach Angriffsmustern:

# SQL injection attempts
grep -iE "(union\s+select|or\s+1=1|information_schema)" /var/log/apache2/access.log

# File inclusion attempts
grep -iE "(etc/passwd|\.\.\/\.\.\/)" /var/log/apache2/access.log

# Direct module file access (potential exploit attempts)
grep -E "modules/.*/ajax|modules/.*/api" /var/log/apache2/access.log

Richten Sie tägliche Log-Zusammenfassungen per Cron ein oder speisen Sie Logs in ein zentralisiertes System wie Graylog oder Papertrail ein, um Echtzeit-Warnungen zu erhalten.

Verfügbarkeitsüberwachung

  • Verwenden Sie UptimeRobot, Hetrix Tools oder selbst gehostetes Uptime Kuma
  • Überwachen Sie sowohl die Startseite als auch die Bestellseite
  • Prüfen Sie auf bestimmte Seiteninhalte, nicht nur auf HTTP 200 – eine veränderte Seite gibt ebenfalls 200 zurück
  • Prüfen Sie alle 1–5 Minuten mit Benachrichtigungen per E-Mail, SMS oder Slack

Admin-Login-Benachrichtigungen

Lassen Sie sich über jede Admin-Anmeldung mit einem einfachen Hook benachrichtigen:

public function hookActionAdminLoginControllerLoginAfter($params)
{
    $employee = $params['employee'];
    $ip = Tools::getRemoteAddr();

    Mail::Send(
        (int)Configuration::get('PS_LANG_DEFAULT'),
        'alert_admin_login',
        "Admin Login: {$employee->email} from {$ip}",
        ['{body}' => "Employee: {$employee->email}
IP: {$ip}
Time: " . date('Y-m-d H:i:s')],
        'security@yourdomain.com',
        'Security Alert'
    );
}

7. Was tun, wenn Sie gehackt wurden

Sofortreaktion (erste 30 Minuten)

  • Löschen Sie noch nichts – Sie benötigen die Dateien für die forensische Analyse
  • Nehmen Sie den Shop offline mit einer Wartungsseite, um weiteren Schaden zu stoppen
  • Ändern Sie ALLE Passwörter: SSH, FTP, Datenbank, Admin-Konten, Hosting-Panel, Payment-Gateway-Schlüssel
  • Sichern Sie den kompromittierten Zustand – kennzeichnen Sie ihn als „kompromittiert“ für die spätere Analyse
  • Benachrichtigen Sie Ihren Zahlungsdienstleister, falls Sie Zahlungen direkt verarbeiten
# Quick maintenance mode
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.ADDRESS$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule .* /maintenance.html [R=503,L]

Die Hintertür finden

Angreifer hinterlassen immer Hintertüren für den erneuten Zugang. Die sichtbare Manipulation zu bereinigen, ohne die Hintertür zu finden, bedeutet eine erneute Kompromittierung innerhalb von Tagen.

# Search for backdoor patterns
grep -rn "eval(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "base64_decode" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "shell_exec\|passthru\|system(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"

# Find recently modified PHP files
find /var/www/html/prestashop/ -name "*.php" -mtime -7 -not -path "*/cache/*"

# Find PHP files in directories where they should not exist
find /var/www/html/prestashop/img/ -name "*.php"
find /var/www/html/prestashop/upload/ -name "*.php"

# Check for obfuscated code (very long single lines)
find /var/www/html/prestashop/ -name "*.php" -exec awk 'NR==1 && length>5000' {} +

Überprüfen Sie auch die Datenbank:

SELECT id_cms, meta_title FROM ps_cms_lang WHERE content LIKE '%<?php%' OR content LIKE '%eval(%';
SELECT * FROM ps_employee ORDER BY date_add DESC LIMIT 10;

Wiederherstellungsprozess

  1. Ermitteln Sie den Einstiegspunkt aus den Zugriffsprotokollen – suchen Sie nach ungewöhnlichen POST-Anfragen an Modul-Controller zum Zeitpunkt der Kompromittierung
  2. Stellen Sie ein sauberes Backup wieder her, falls verfügbar. Vergewissern Sie sich, dass das Backup vor der Kompromittierung erstellt wurde.
  3. Falls kein sauberes Backup vorhanden ist: Ersetzen Sie alle Core-Dateien durch einen frischen Download Ihrer exakten PS-Version, installieren Sie alle Module aus den Originalquellen neu, behalten Sie nur Ihr Theme und das img/-Verzeichnis (scannen Sie diese gründlich)
  4. Durchsuchen Sie die Datenbank nach eingeschleustem Inhalt in ps_configuration, ps_cms_lang und ps_meta_lang
  5. Aktualisieren Sie alles – Core, Module, PHP, MySQL, Betriebssystem

Prävention nach der Bereinigung

  • Entfernen oder patchen Sie die spezifische Schwachstelle, die ausgenutzt wurde
  • Überwachen Sie im ersten Monat intensiv – Angreifer versuchen oft, zurückzukehren
  • Ziehen Sie eine WAF in Betracht (Cloudflare Free-Tarif, Sucuri oder ModSecurity)
  • Falls Zahlungsdaten möglicherweise kompromittiert wurden, konsultieren Sie einen Anwalt bezüglich der DSGVO-Meldepflichten (72-Stunden-Frist)
Harte Wahrheit: Wenn Sie nicht feststellen können, wie der Angreifer eingedrungen ist, gehen Sie davon aus, dass er erneut eindringen wird. Ein professionelles Sicherheitsaudit kostet nur einen Bruchteil eines zweiten Sicherheitsvorfalls.

8. Sicherheits-Checkliste

Drucken Sie diese Liste aus und arbeiten Sie sie durch. Jeder nicht abgehakte Punkt ist ein potenzieller Einstiegspunkt.

Server und PHP

  • PHP-Version ist aktuell und wird unterstützt
  • Gefährliche PHP-Funktionen deaktiviert
  • expose_php = Off
  • display_errors = Off in der Produktivumgebung
  • allow_url_include = Off
  • Session-Cookies: HttpOnly, Secure, SameSite
  • open_basedir gesetzt
  • Betriebssystem, MySQL und Webserver aktuell
  • SSH-Schlüsselauthentifizierung aktiviert, Passwort-Authentifizierung deaktiviert
  • Firewall konfiguriert (nur notwendige Ports offen)

Dateisystem

  • Verzeichnisse: 755, Dateien: 644
  • parameters.php: 400
  • Keine Dateien auf 777 gesetzt
  • PHP-Ausführung in upload/, img/, download/ blockiert
  • Verzeichnislisting deaktiviert
  • .env, .git, YAML- und Konfigurationsdateien vom Web blockiert
  • vendor/ und var/logs/ vom Web blockiert

SSL und HTTPS

  • Gültiges SSL-Zertifikat mit automatischer Verlängerung
  • HTTP-zu-HTTPS-Weiterleitung eingerichtet
  • HSTS-Header konfiguriert
  • SSL in PrestaShop aktiviert (alle Seiten)
  • Keine Mixed-Content-Warnungen

Admin-Panel

  • Admin-Verzeichnis hat einen zufälligen Namen
  • Alle Passwörter mindestens 16 Zeichen aus einem Passwort-Manager
  • 2FA für alle Konten aktiviert
  • Admin-Zugang per IP eingeschränkt (falls möglich)
  • Unnötige Konten gelöscht
  • Jeder Mitarbeiter hat die minimal notwendigen Berechtigungen
  • Brute-Force-Schutz (fail2ban oder gleichwertig)

Module

  • Alle Module aus vertraünswürdigen Quellen
  • Keine raubkopierten/geknackten Module
  • Alle Module aktuell
  • Unbenutzte Module gelöscht (nicht nur deaktiviert)
  • Modul-Code auf eval() und unsanitisiertes SQL geprüft
  • Sicherheitshinweise abonniert

Datenbank

  • Dedizierter Datenbankbenutzer (nicht Root)
  • Minimale Berechtigungen vergeben
  • Starkes Datenbankpasswort (20+ Zeichen)
  • MySQL nur an localhost gebunden
  • phpMyAdmin entfernt oder per IP eingeschränkt
  • Tabellenpräfix vom Standard ps_ geändert

Backups

  • Automatisierte tägliche Datenbank-Backups
  • Automatisierte tägliche Datei-Backups
  • Backups außerhalb des Servers gespeichert
  • Backups vor der Übertragung verschlüsselt
  • Mindestens 30 Tage Aufbewahrung
  • Wiederherstellung in den letzten 30 Tagen getestet

Überwachung

  • Dateiintegritätsüberwachung aktiv
  • Zugriffsprotokolle auf Angriffsmuster überwacht
  • Verfügbarkeitsüberwachung mit Inhaltsprüfung
  • Admin-Login-Benachrichtigungen aktiviert
  • Sicherheitsheader implementiert

Vorfallbereitschaft

  • Vorfallreaktionsplan dokumentiert
  • Kontaktdaten von Hoster und Zahlungsdienstleister zugänglich
  • DSGVO-Meldeprozess dokumentiert
  • Wartungsseite einsatzbereit
  • Alle kritischen Passwörter in einem Passwort-Manager

Sicherheit ist ein fortlaufender Prozess, kein einmaliges Setup. Planen Sie eine vierteljährliche Überprüfung ein. Die Zeit, die Sie jetzt investieren, ist unbedeutend im Vergleich zu den Kosten einer Wiederherstellung nach einem Sicherheitsvorfall. Beginnen Sie mit den wirkungsvollsten Maßnahmen: Aktualisieren Sie alles, aktivieren Sie 2FA, entfernen Sie ungenutzte Module und konfigurieren Sie Backups. Arbeiten Sie dann den Rest ab.

Ihre Kunden vertrauen Ihnen ihre persönlichen Daten an. Ehren Sie dieses Vertrauen.

Nach oben