Zum Hauptinhalt springen
How Can We Help?
< All Topics

Die Datenbank enthält alles Wertvolle: Inhalte, Benutzer mit Passwort-Hashes, Bestellungen, Formulareinträge, API-Keys in Options. Sie wird selten direkt angegriffen, aber SQL-Injection in Plugins, offene Datenbankports und herumliegende Dumps sind reale Risiken.

Eigener Datenbankbenutzer pro Site

Jede Installation erhält einen eigenen DB-Benutzer, der nur auf die eigene Datenbank zugreifen darf. Nie den Root-Benutzer verwenden.

CREATE USER 'wp_example'@'localhost' IDENTIFIED BY 'langes-zufälliges-passwort';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP,
      CREATE TEMPORARY TABLES, LOCK TABLES
  ON wp_example.* TO 'wp_example'@'localhost';

Rechte wie FILE, SUPER, PROCESS oder GRANT OPTION braucht WordPress nicht. Gerade FILE würde bei einer SQL-Injection das Schreiben von Dateien ermöglichen.

Weiter einschränken? CREATE, ALTER und DROP im Normalbetrieb zu entziehen ist möglich, bricht aber Core-Updates mit Datenbank-Migrationen und viele Plugin-Aktivierungen. Wer das will, braucht einen separaten Benutzer für Updates.

Netzwerkzugriff

  • MySQL/MariaDB nur auf localhost oder im privaten Netz binden (bind-address = 127.0.0.1), nie Port 3306 öffentlich.
  • Bei getrenntem DB-Server: TLS für die Verbindung (MYSQL_CLIENT_FLAGS mit MYSQLI_CLIENT_SSL) und Firewall auf die Webserver-IP beschränken.
  • phpMyAdmin und Adminer nicht öffentlich betreiben; wenn nötig, hinter VPN, IP-Whitelist oder zusätzlicher Authentifizierung. Vergessene adminer.php-Dateien im Webroot sind ein beliebtes Einfallstor.

Tabellenpräfix

Ein individuelles Präfix statt wp_ erschwert automatisierte SQL-Injection-Payloads minimal. Es ersetzt keine Härtung und lohnt die Umstellung auf bestehenden Sites meist nicht (Risiko von Fehlern bei wp_options/wp_usermeta-Schlüsseln, die das Präfix enthalten). Für Neuinstallationen: ja, kostet nichts.

Backups und Dumps

  • SQL-Dumps nie im Webroot ablegen. backup.sql, db.sql.gz und ähnliche Dateien werden aktiv gescannt.
  • Dumps verschlüsseln, wenn sie extern gespeichert werden.
  • Staging- und Entwicklungs-Datenbanken mit Kundendaten genauso schützen wie Produktion oder anonymisieren.

Versionen

WordPress empfiehlt MySQL 8.0+ oder MariaDB 10.6+; das Hosting-Handbuch nennt für Neuinstallationen MySQL 8.4 bzw. MariaDB 10.11/11.4 und neuer. MySQL 5.7 ist seit Oktober 2023 end-of-life.

Sensible Daten in Options

Viele Plugins speichern API-Keys im Klartext in wp_options. Wo möglich, Secrets per Konstante in der wp-config.php oder per Umgebungsvariable hinterlegen. Ab WordPress 7.0 verwaltet die Connectors-Seite KI-Anbieter zentral; auch dort gilt: nur wirklich genutzte Anbieter hinterlegen und Keys mit minimalen Rechten und Ausgabenlimits verwenden.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: