WordPress-Hardening jenseits von Plugins: 12 Einstellungen am Server und in wp-config

Sicherheits-Plugins helfen, haben aber eine klare Grenze: Sie laufen innerhalb von WordPress, also erst, nachdem die Anfrage bereits bei PHP angekommen ist. Die soliden Maßnahmen liegen darunter — auf Ebene des Webservers und in wp-config.php, dort, wo ein Plugin nicht hinkommt. Das sind Einstellungen, die Sie einmal vornehmen, die still aktiv bleiben und die Website nicht belasten.

Unten finden Sie 12 konkrete Dinge, die Sie überprüfen oder vom Hosting anfordern können. Sie ersetzen nicht den gesunden Menschenverstand (gute Passwörter, aktuelle Updates), heben aber die Messlatte für jemanden, der versucht einzudringen, deutlich an. Und eine ehrliche Warnung: Wenn Ihnen jemand eine „unhackbare" Website verspricht, laufen Sie weg — Sicherheit besteht aus Schichten, nicht aus einem Häkchen.

Dateiberechtigungen, die keine offenen Türen lassen

Falsche Berechtigungen gehören zu den häufigsten Problemen. Die einfache Regel:

• Verzeichnisse: 755
• Dateien: 644
• wp-config.php: 600 (oder 640), nur vom Server-Nutzer lesbar

Niemals 777 auf irgendetwas — das bedeutet „jeder kann schreiben". Prüfen Sie auch den Eigentümer der Dateien: Alles sollte dem Nutzer gehören, unter dem PHP läuft, nicht root. Ein gutes Zeichen ist, dass nicht einmal WordPress selbst die Theme-Dateien direkt bearbeiten können sollte — wenn es das kann, kann es auch ein Angreifer, der ein Konto kompromittiert. wp-config.php verdient eine gesonderte Behandlung, weil es die Datenbankschlüssel enthält.

wp-config.php — hier wird der Ton angegeben

Diese Datei ist das Herzstück der Installation. Ein paar Zeilen, die zählen:

• Einzigartige Schlüssel und Salts (SALT), generiert über den offiziellen WordPress-Dienst — sie machen gestohlene Sitzungen ungültig.
• define('DISALLOW_FILE_EDIT', true); — entfernt den Theme-/Plugin-Editor aus dem Admin-Bereich, damit niemand über ein kompromittiertes Konto Code einschleusen kann.
• define('FORCE_SSL_ADMIN', true); — erzwingt HTTPS im Admin-Bereich.
• define('WP_DEBUG', false); und WP_DEBUG_DISPLAY deaktiviert in der Produktion, damit Fehler keine Serverpfade offenlegen.

Optional können Sie wp-config.php eine Ebene über das öffentliche Root-Verzeichnis verschieben und das Tabellenpräfix von wp_ auf etwas Eigenes ändern. Das sind keine Wundermittel, aber sie reduzieren die Angriffsfläche.

Regeln am Webserver (Apache / Nginx)

Hier blockieren Sie den Zugriff, bevor PHP überhaupt startet.

• Verbieten Sie den direkten Zugriff auf sensible Dateien: wp-config.php, .htaccess, readme.html, xmlrpc.php (wenn Sie XML-RPC nicht nutzen).
• Deaktivieren Sie das Auflisten von Verzeichnissen (Options -Indexes bei Apache), damit niemand Ordner durchsuchen kann.
• Am wichtigsten: Stoppen Sie die PHP-Ausführung in wp-content/uploads. Wenn es einem Angreifer gelingt, eine als Bild getarnte .php-Datei hochzuladen, wird sie ohne Ausführungsrecht dort harmlos.

Bei Nginx sind das Location-Blöcke, bei Apache Regeln in .htaccess oder in der Konfiguration. Wenn Sie auf einem Shared-Hosting sind, bitten Sie den Support, diese Regeln anzuwenden — das ist eine normale Anfrage.

Security Header — Antworten, die dem Browser die Regeln sagen

HTTP-Header stoppen keinen Server-Hack, aber sie schließen viele Angriffe aus dem Browser (Clickjacking, Content-Sniffing, Downgrade auf HTTP). Es lohnt sich, diese zu setzen:

• Strict-Transport-Security (HSTS) — zwingt den Browser, nur HTTPS zu verwenden.
• X-Content-Type-Options: nosniff — stoppt das Erraten des Dateityps.
• X-Frame-Options: SAMEORIGIN (oder CSP frame-ancestors) — Anti-Clickjacking.
• Referrer-Policy und Permissions-Policy — begrenzen, was durchsickert und welche Browser-APIs erlaubt sind.

Sie können sie auf Serverebene oder über die Plattform (Header-Regeln) setzen. Das Ergebnis können Sie mit jedem öffentlichen, kostenlosen Header-Scanner überprüfen.

Datenbank, Konten und Wartung

Die letzte Schicht betrifft Hygiene:

• Der Datenbank-Nutzer sollte nur die auf seiner eigenen Datenbank nötigen Rechte haben — kein globales Root-Konto.
• Kein Benutzername „admin" und lange, eindeutige Passwörter; idealerweise Zwei-Faktor-Authentifizierung für Admin-Konten.
• Halten Sie PHP und WordPress auf einer unterstützten Version — viele Sicherheitslücken kommen von veralteter Software, nicht von raffinierten Angriffen.
• Automatisches, getestetes Backup, gespeichert an einem anderen Ort als dem Server.

So sieht eine ernsthaft behandelte Installation bei MPO Web Studio aus: Wir liefern bereits gehärtete Websites, remote, im ganzen Land, mit diesen Einstellungen von Anfang an. Wenn Sie eine Meinung zu Ihrer aktuellen Website wollen, schreiben Sie uns auf WhatsApp — wir sagen Ihnen ehrlich, was sich zu ändern lohnt.