Fortgeschrittenes WordPress-Hardening 2026

Ein WordPress-Security-Plugin auf einem beschreibbaren Origin ist kein Hardening. Hardening 2026 ist Identität, eine schreibgeschützte Runtime, eine Edge, die eine Payload verwirft, bevor PHP startet, und Logs, die der Origin nicht löschen kann.

WordPress 7.1 auf PHP 8.4 ist eine gepflegte Anwendung. Es ist auch das, was Angreifer zuerst scannen, weil Plugin-Verzeichnis, xmlrpc.php und wp-login.php vorhersagbar sind. Die Vorfälle, die wir noch aufräumen, heißen nicht “WordPress ist unsicher”. Sie heißen öffentliches Admin, Freitags-Update aus dem Dashboard und ein Host, der PHP auf sich selbst schreiben lässt.

Dieser Guide ist die Betriebsfassung. Passkeys, unveränderliche Images, Virtual-Patching an der WAF, CSP-Nonces, Composer-Audits, Logs außerhalb der Box. Das WordPress-Sicherheitsaudit ist die kommerzielle Fläche, wenn dieser Stack geprüft statt nur beschrieben werden soll.

#Identität zuerst: Passkeys und wp-admin nicht öffentlich

Das Loginformular bleibt der billigste Angriff. Credential-Stuffing braucht keine Zero-Day. Es braucht wp-login.php im offenen Netz und einen Administrator, der ein Passwort aus einem Leak wiederverwendet.

Passkeys (WebAuthn) binden die Zeremonie an das Gerät und an den Origin. Eine Lookalike-Domain schließt sie nicht ab. Deshalb erzwingen wir Passkeys für jedes Konto, das Plugins installieren oder PHP im Theme-Editor speichern kann (der Editor gehört sowieso aus). Application-Passwords für die CI liegen im Secret-Store, nicht im Passwortmanager, den das Marketing mitbenutzt.

Lassen Sie Passwort-Login nicht als “falls mal etwas klemmt” auf der öffentlichen URL. Der Fallback ist der Weg, auf dem Phishing weiter funktioniert. Break-Glass ist ein Hardware-Key im Tresor oder Recovery über den Identity-Provider, auf einem Pfad, der nicht wp-login.php heißt.

wp-admin gehört nicht ins öffentliche Internet. Cloudflare-Access, ein Tailscale-Funnel oder der Identity-Aware-Proxy, den die Firma schon für interne Tools nutzt. Anonymes GET der Storefront bleibt Cache-Treffer. /wp-admin und wp-login.php liefern 403 oder eine SSO-Challenge. xmlrpc.php ist aus, außer Jetpack oder eine Mobile-App brauchen es wirklich, und dann nach Methode und IP allow-listen, nicht als Pingback-Kanone stehen lassen.

Wir sehen immer noch Shops, die wp-admin “versteckt” haben, indem sie den Login-Slug umbenannt haben. Das ist keine Identität. Crawler finden den neuen Slug an einem Tag. Die Fläche hinter Identität legen, oder es bleiben lassen.

REST ist nicht von Hause aus “sicherer als xmlrpc”. /wp-json/wp/v2/users enumeriert Logins auf vielen Default-Installationen. Application-Passwords für ein Headless-Front gehören scoped und rotiert. Der Users-Endpoint ist auf öffentlichen Blogs absichtlich GET. Auf einem Shop ist er ein Geschenk. Abschalten oder Auth verlangen. Dasselbe für ?author=1-Redirects, die admin als nicename leaken.

Rate-Limiting des Logins in PHP ist, wie Sie sich selbst in den Denial-of-Service treiben. Die WAF oder Access macht diese Arbeit. Wenn ein öffentlicher Login für Abonnenten bleiben muss (Membership), gehen Administratoren trotzdem über Access auf einem anderen Hostnamen. Ein wp-login.php für alle ist der Weg, auf dem ein Stuffing-Lauf den Redakteur aus der eigenen Seite sperrt.

Im deutschen Mittelstand hängt der SSO oft an Microsoft Entra ID. Das ist in Ordnung, solange die Access-Policy Gerät und Gruppe prüft und nicht nur “irgendein Firmenkonto”. Ein Praktikanten-Account in der globalen Admin-Gruppe ist kein Zero-Trust, das ist ein geteiltes Passwort mit extra Schritten.

#NIS2 und BSI: was ein deutscher Shop an Logging schuldet

Hier trennt sich der deutsche Betreiber vom Plugin-Mythos. Die NIS-2-Richtlinie (EU 2022/2555) und das deutsche Umsetzungsgesetz NIS2UmsuCG verlangen von Einrichtungen in den genannten Sektoren und Größenklassen Nachweise, Uhren und einen benannten Operator. Sie verlangen kein Wordfence-Badge im Footer.

Zuerst die Reichweite, ohne Überclaim. Ein WooCommerce-Shop mit acht Leuten, der Möbel nach Baden-Württemberg schickt, ist fast nie eine NIS2-Einrichtung und schon gar nicht KRITIS. KRITIS bleibt die engere Verordnung mit Schwellen und Sektoren. Klarna im Checkout macht niemanden zum KRITIS-Betreiber. Ein Energieversorger oder ein Klinikverbund, der denselben WordPress-Stack nur für die Marketingseite nutzt, kann in der Pflicht stehen, obwohl die Seite selbst kein KRITIS-Asset ist. Die Pflicht hängt am Betreiber, nicht am CMS.

Was die Richtlinie konkret schuldet, ist eine Zeitlinie, die ein Dritter lesen kann, plus Meldeuhren: Frühwarnung in 24 Stunden, Vorfallsmeldung in 72 Stunden, Abschlussbericht binnen eines Monats. Das sind Betreiberpflichten gegenüber dem BSI. WPPoland schreibt diese Meldung nicht, betreibt keine SOC-Schicht und sitzt nicht 24 Stunden am Ticker. Wir bauen die technische Fläche, aus der ein benannter Operator die Uhr überhaupt starten kann: Auth-Ereignisse, Deploy-Trail, WAF-Aktion, Rollenwechsel, und das außerhalb der Box, die gerade kompromittiert sein könnte.

BSI IT-Grundschutz ist der Stand der Technik, auch wenn NIS2 für Ihren Shop nicht greift. Die Bausteine sind Checklisten, keine Zertifikate, die eine Agentur ausstellt. Für diesen Stack zählen in der Praxis:

• OPS.1.1.5 Protokollierung. Quellen, Aufbewahrung, Schutz gegen Löschen durch denselben Host. “error_log auf dem Hetzner-CX” erfüllt den Baustein nicht.
• APP.3.2 Webanwendungen. Authentisierung, Session, Input, Header. wp-admin öffentlich und DISALLOW_FILE_EDIT aus ist der Gegenteil dieses Bausteins.
• ORP.4 Identitäts- und Berechtigungsmanagement. Passkeys, getrennte Rollen, kein Freelancer mit administrator, weil “PDF muss hochladen”.
• DER.2.1 Behandlung von Sicherheitsvorfällen. Ein Runbook mit Namen, nicht ein Slack-Kanal namens #irgendwas. Die Uhr aus NIS2 nützt nichts, wenn niemand weiß, wer anruft.

DORA sitzt daneben und trifft Finanzunternehmen unter Aufsicht, nicht den Möbelshop mit PayPal. Wenn Sie wirklich in einer dieser Pflichten stehen, ist die Fläche NIS2- und DORA-Readiness, nicht eine weitere Plugin-Seite. Wir sind keine KRITIS-Prüfstelle. Wer das als Paket verkauft, verkauft eine Rolle, die ihm nicht zusteht.

Was ein deutscher Shop trotzdem loggen muss, auch ohne NIS2-Schwelle: genug, um montags zu sagen, wer Freitagnacht ein Plugin gezogen hat, und genug, um einen Zahlungs-Webhook von Sparkasse, PayPal oder Klarna nachzuvollziehen, ohne IBAN oder PAN in nginx-Query-Strings zu schreiben. Wir sehen Installationen, in denen das Access-Log die Recovery-URL mit Token speichert, weil jemand log_format mit $request vollgemacht hat. Das ist kein Nachweis, das ist eine zweite Kopie der Geheimnisse.

Aufbewahrung: 90 Tage heiß, durchsuchbar, reicht für die meisten Shops. Länger nur, weil Anwalt oder Aufsicht es gesagt hat, nicht weil ein Plugin “Log-Retention” als Feature anbietet. Der Origin-Role darf den Bucket nicht löschen. Wenn der einzige Copy von auth.log auf dem Host liegt, der gerade eine Shell bekommen hat, haben Sie nach dem Rebuild eine Vermutung, keine Zeitlinie.

Consent-Banner, Cookie-Texte, Usercentrics und eRecht24 gehören in ein anderes Dokument. Hier geht es um Operator-Logging, nicht um Einwilligung.

#Schreibgeschützte Runtime: die Platte, die keine Shell akzeptiert

Dashboard-Updates sind eine Sicherheitsentscheidung. Sie sehen aus wie Komfort. Sie sind ein Write auf Produktion durch jeden, der ein Admin-Cookie hat.

Behandeln Sie den PHP-Baum als schreibgeschützt. WordPress läuft aus einem Image (Container oder rsync eines Build-Artefakts). wp-content/plugins und wp-content/themes liegen in diesem Image. Das einzige beschreibbare Volume sind Uploads, und dieses Volume führt kein PHP aus. Wenn eine Plugin-RCE wp-content/uploads/cache.php ablegen will, schlägt der Write fehl oder die Datei liegt nicht im ausführbaren Pfad.

Updates laufen dann in Git:

1. Dependabot oder ein geplanter Composer-Bump öffnet einen PR.
2. CI läuft phpstan, ein Smoke-Test und ein Lockfile-CVE-Scan.
3. Das Image wird gebaut und deployed. Das vorherige Image bleibt zum Rollback.

Der Live-Server wird nie “editiert”. Das tötet auch die Malware-Klasse, die sich hält, indem sie wp-config.php oder ein Must-Use-Plugin schreibt, das das Dashboard nie listet.

Datenbankuser: SELECT, INSERT, UPDATE, DELETE auf dem Site-Schema. Kein DROP, kein FILE, kein GRANT. TLS zu MySQL. Der Tabellenpräfix ist keine Kontrolle. Er ist Trivia, die deutsche How-tos immer noch als “Härten” verkaufen.

Object-Cache (Redis) hält Sessions und Transients. Behandeln Sie ihn als Speicher für Geheimnisse. Netzisolation, AUTH, kein öffentlicher Port. Ein “flush all” aus einem kompromittierten Admin ist ein Verfügbarkeitsvorfall. Trennen Sie den Cache für Sessions vom Cache für HTML-Fragmente, wenn Sie können. Wir haben ein Plugin gesehen, das ein Reset-Passwort-Token in ein geteiltes Redis schrieb, und eine zweite Site auf demselben Hetzner-Host hat es gelesen. Das ist ein Hosting-Layout-Fehler, kein WordPress-Fehler, und er landet trotzdem in Ihrem Vorfallskanal.

wp-config.php-Keys (AUTH_KEY und Freunde) rotieren, wenn Cookie-Diebstahl im Raum steht, und die alten Sessions sterben. Keys in die Umgebung legen, nicht ins Image, heißt: ein geleaktes Repo ist kein geleakter Login. Das Image braucht trotzdem einen Weg zum Boot. Den Secret-Store der Plattform nutzen. Kein .env in dasselbe Git committen, das die Frontend-Agentur klonen kann.

Auf typischem deutschem Hosting (Hetzner CX, ein Managed-Tarif bei Mittwald, ein IONOS-VPS) ist der Weg oft rsync des Artefakts plus ein Uploads-Volume mit php_admin_flag engine off oder einem nginx-location, das .php in Uploads mit 403 beantwortet. Docker ist nicht Pflicht. Schreibschutz ist Pflicht. Ein “wir machen Updates im Panel, der Hoster patched den Core” ist genau das Write-Recht, das eine RCE sucht.

#WAF und virtuelles Patchen

Die WAF sitzt vor dem Origin. Sie sieht den HTTP-Request, bevor PHP bootet. Das ist der einzige Grund, warum sie das Geld wert ist.

Wofür sie da ist:

• Bekannte Exploit-Pfade: Fluten auf /wp-login.php, xmlrpc-Multicall, REST-Routen, die nicht anonym sein dürfen.
• Ein Virtual-Patch am Tag, an dem ein WooCommerce- oder Elementor-CVE öffentlich wird, während Sie das Image neu bauen. Stunden, nicht das Wochenende.
• Rate-Limits, die die Anwendung sonst schlecht in PHP bauen würde.

Wofür sie nicht da ist: Input-Validierung ersetzen, oder die einzige Kopie Ihres Access-Logs sein.

Managed-WordPress-Hoster verkaufen oft “wir haben eine WAF”. Fragen Sie, ob Sie am selben Tag eine Regel setzen können und ob die Regel vor PHP greift. Wenn die Antwort ein Ticket-Queue ist, ist das kein Virtual-Patching.

Sparkasse-, PayPal- und Klarna-Webhooks müssen durch. Eine Managed-Ruleset, die /?wc-ajax= oder /wp-json/ pauschal würgt, legt den Checkout lahm und wird dann mit einer Skip-Liste “repariert”, die halb Origin wieder öffnet. Jede Ausnahme ist ein Satz mit Begründung, kein Bauchgefühl am Freitagnachmittag.

#Wordfence am Origin gegen WAF an der Edge

Das ist die Betriebsentscheidung, die wir wiederholen, und die ein billiges “Security-Plugin” von einem Stack trennt, der nach einem CVE-Freitag noch antwortet.

Wordfence, Sucuri-Plugin, iThemes laufen in PHP. Sie können Dateien scannen, wp-login drosseln, eine Mail schicken. Sie starten, nachdem der Request den Origin schon erreicht hat. Eine Payload, die den PHP-Worker vor dem init-Hook des Plugins ausnutzt, sehen sie nicht rechtzeitig. Sie brauchen außerdem ein beschreibbares Dateisystem für ihre eigenen Daten, und das kämpft gegen die schreibgeschützte Runtime.

Cloudflare-WAF (oder Fastly, oder die WAF vor Ihrem VPS) läuft auf dem Cache-Node. Anonymes GET kann Cache-Treffer bleiben. Ein POST, der auf eine CVE-Signatur passt, erreicht PHP nicht. Virtual-Patching ist ein Regel-Push, kein Plugin-Update. Das Origin-Image bleibt schreibgeschützt.

Regeln, die wir nutzen:

• Login und xmlrpc nur aus Access, oder blockiert. Storefront-POST (Checkout, Konto) geht durch die WAF mit einem verwalteten WordPress-Ruleset plus einem gezielten Skip für die Zahlungs-Webhook-Pfade, die Sie wirklich besitzen (PayPal, Klarna, Sparkasse). /wp-admin/admin-ajax.php pauschal zu skippen ist der Weg, auf dem Leute ihre eigene WAF zerlegen.
• Wordfence, wenn es überhaupt bleibt, ist ein Scanner in der CI oder auf einem Staging-Klon, keine Runtime-Firewall auf Produktion. Zwei Firewalls, die beide glauben, sie besitzen die Rate-Limits, sperren echte Kunden aus und verpassen das CVE trotzdem.
• Dateiintegrität: das deployed Image mit Git vergleichen, nicht ein Plugin, das bei jedem Cron durch wp-content läuft. Cron am Origin ist noch ein PHP-Prozess, den Sie nicht brauchten.

Ein Shop in NRW, den wir 2025 neu aufgesetzt haben, hatte Wordfence “high sensitivity”, Cloudflare “I’m under attack” auf derselben URL und ein Sparkasse-Widget, das nach admin-ajax POSTete. Der Checkout lag einen Tag. Das CVE, vor dem sie Angst hatten, war an der Edge in einer Regel gepatcht. Der Plugin-Kampf war der Ausfall.

Virtual-Patching hat ein Haltbarkeitsdatum. Die WAF-Regel ist das Wochenende. Das Image-Rebuild ist die Woche. Wenn die Regel sechs Monate später immer noch der einzige Fix ist, haben Sie keine Pipeline, Sie haben einen Klebezettel. Ein offenes Virtual-Patch behandeln wir als Ticket mit Owner, nicht als Abzeichen.

Skip-Listen sind der Ort, an dem WAFs sterben. /wp-admin/admin-ajax.php, /?wc-ajax=, PayPal-IPN, Klarna-Push, Apple-Pay-Domain-Verify. Jeder Skip ist eine geschriebene Ausnahme mit Grund. Ein Skip, weil “das Cookie-Banner kaputt ging”, der gleichzeitig admin-ajax der Welt öffnet, macht aus einem billigen Plugin wieder eine Origin-RCE.

Zwei Produkte, die denselben Request rate-limiten, erzeugen die Sorte Störung, die der Händler als “die Seite ist tot” sieht und der Entwickler als “die WAF spinnt”. Eine Schicht besitzt den Limit. Die andere scannt offline.

#CSP-Nonces, nicht ein Kommentar in der .htaccess

Content-Security-Policy ist der Browser, der ein Skript verweigert, das Sie nicht geschickt haben. XSS in einem Plugin passiert weiter. CSP ist, was dieses Skript am Rausrufen hindert.

Eine Policy, die auf einem WordPress-Theme in der Praxis hält:

• default-src 'self'
• script-src 'self' 'nonce-…' plus die zwei oder drei Zahlungs-Origins, die Sie nennen können (PayPal, Klarna, Sparkasse-Widget)
• style-src 'self' 'unsafe-inline' bis das Theme gehasht ist (unsafe-inline auf style ist ein Kompromiss; nicht auf script kopieren)
• frame-ancestors 'none', außer Sie betten die Seite wirklich ein
• object-src 'none'
• base-uri 'self'

Der Nonce muss pro Response wechseln. Ein statischer Nonce in wp_head ist Theater. HTMLRewriter an der Edge oder ein PHP-Must-Use-Plugin, das Header und passende Attribute schreibt, beides funktioniert. Das Plugin-Verzeichnis ist voll mit “CSP hinzufügen”-Plugins, die 'unsafe-inline' auf script setzen. Diese Policy stoppt kein XSS. Sie dokumentiert, dass jemand es versucht hat.

Zuerst Report-Only. Eine Woche Reports lesen. Dann erzwingen. Stripe bleibt in manchen Stacks, Tag-Manager fast immer, das Consent-Tool ebenfalls. Jedes davon ist eine Entscheidung: per Origin erlauben oder von der First-Party-Seite runter. Consent selbst ist nicht dieses Kapitel. Die Origins, die das Banner lädt, stehen trotzdem in der Report-Liste und müssen benannt werden.

CSP ersetzt weder esc_html noch Nonces auf Formularen. Es ist der letzte Zaun.

Wir haben Themes gesehen, die Google Fonts, drei Tag-Manager-Container und das Sparkasse-Widget gleichzeitig laden und dann CSP “auf strict” stellen. Der Report läuft voll, jemand schaltet 'unsafe-inline' wieder an, und der Zaun ist weg. Weniger Third-Party auf der Checkout-Seite ist die eigentliche Härte. Die Policy beschreibt nur, was übrig ist.

#Lieferkette: Composer, Plugin-Verzeichnis und Freitags-Updates

Die meisten WordPress-Kompromisse, die wir noch sehen, starten als Plugin, nicht als Core. Core hat einen Release-Prozess. Ein Plugin mit 200.000 Installationen kann in einem Minor ein Phone-Home ausliefern.

Was wir tun:

• Plugins, von denen Sie abhängen, liegen in Composer (wpackagist oder ein privater Mirror), damit das Lockfile die Stückliste ist. “Installieren aus wp-admin” ist auf Produktion aus.
• CI lässt den PR scheitern, wenn composer audit oder der npm-Audit der Theme-Toolchain ein bekanntes CVE über der von Ihnen gesetzten Schwelle meldet. Die Schwelle ist nicht “nur critical”. Ein vergessenes XSS in einem Formular-Plugin reicht.
• Neue Plugins bekommen ein Lesen auf eval, file_get_contents entfernter URLs und admin-post-Handler, bevor sie in den Mirror dürfen. Das ist eine Stunde, kein Theater-Zertifikat.
• Auto-Updates auf Produktion sind aus. Auto-Updates auf einem Staging-Klon, der durch dieselbe Pipeline promoviert, sind in Ordnung.

Die Fläche NIS2- und DORA-Readiness ist der Ort für die Betreiberpflichten. Dieser Abschnitt ist die Technik, die diese Pflichten überhaupt möglich macht: Sie können benennen, was läuft, und Sie können es neu bauen.

Freitags-Updates aus dem Dashboard sind in deutschen Shops fast ein Ritual (“vor dem Wochenende noch Elementor ziehen”). Genau dieses Fenster ist das, in dem niemand den Diff liest und der Virtual-Patch der WAF noch nicht existiert. Der PR am Montag mit Scan ist langsamer und genau deshalb der Punkt.

Ein privater Mirror lohnt sich, sobald mehr als eine Site denselben Plugin-Satz teilt. wpackagist allein reicht für den Lock. Der Mirror hält Sie am Leben, wenn das Verzeichnis eine Version zurückzieht oder ein Maintainer das Slug an jemanden übergibt, den Sie nicht gewählt haben. Das ist Lieferkette, nicht Paranoia.

#Logs, die den Vorfall überleben

Wenn die einzige Kopie von auth.log und dem PHP-Error-Log auf dem Host liegt, der gerade eine Shell bekommen hat, haben Sie keine Vorfallszeitlinie. Sie haben einen neu gebauten Server und eine Vermutung.

Stream:

• nginx- oder Cloudflare-Request-Logs (WAF-Aktion, Pfad, Land, Ray-ID)
• PHP-FPM-Errors und Slow-Log
• WordPress-authenticate-Fehler und user_register / set_role
• Deploy-Ereignisse aus der CI (wer welches Image geliefert hat)

in einen Bucket oder ein SIEM, das die Origin-Role nicht löschen kann. Retention, die Sie wirklich durchsuchen: 90 Tage heiß reicht für einen Shop. Regulierte Leser gehen länger, weil die Rechtsabteilung es gesagt hat, nicht weil ein Plugin “Log-Retention” angeboten hat.

Alert auf: Spike von 401 auf wp-login (wenn der noch öffentlich ist, ist das schon der Bug), neuer Administrator, Plugin-Datei-Hash driftet gegen Git, WAF-Blockrate steigt auf einer REST-Route.

Kaufen Sie “KI-Anomalieerkennung” nicht als erste Kontrolle. Die erste Kontrolle ist “wir haben die Logs” und “montags liest jemand die Admin-Create-Events”.

Für deutsche Betreiber, die in NIS2 stehen, ist genau dieser Stream die Voraussetzung der Meldeuhren, nicht ein Add-on. Für alle anderen ist es der Unterschied zwischen “wir haben neu aufgesetzt” und “wir können sagen, was passiert ist”. Grundschutz OPS.1.1.5 sagt dasselbe ohne EU-Artikel: Quelle, Schutz, Auswertung. Auswertung heißt ein Mensch mit Kalender, keine SOC-Folie.

Zahlungs-Webhooks gehören ins Log als Ereignis (Status, ID, Zeitpunkt), nicht als Body. Ein nginx, der den kompletten Klarna- oder PayPal-Payload mitschreibt, sammelt Zahlungsdaten in einer Datei, die oft länger lebt als die Shop-Datenbank und schlechter geschützt ist. Das ist der gegenteilige Fehler zu “wir loggen nichts”.

#Was wir in der ersten Woche wirklich ändern

Ein Hardening-Einsatz ist kein 25-Zeilen-Spreadsheet. Es ist eine kurze Folge, die Sie zu Ende bringen können.

1. Screenshot der aktuellen Plugin-Liste und der letzten Dashboard-Updates. Das ist der Tatort, falls schon etwas falsch ist.
2. Access vor wp-admin. Passkeys für Administratoren erzwingen. xmlrpc aus, wenn ungenutzt.
3. Plugin-Installs auf Produktion stoppen. Den Composer-Pfad aufmachen, auch wenn der erste Commit nur pinnt, was schon da ist.
4. Ein WAF-Managed-Ruleset und ein Virtual-Patch, den Sie benennen können (das letzte CVE in Ihrer Plugin-Liste).
5. CSP in Report-Only ausrollen. Den Report lesen.
6. Logs von der Box holen. Prüfen, dass Sie einen fehlgeschlagenen Login von gestern greppen können, ohne SSH auf den Origin.

Dann wird das Image schreibgeschützt. Dieser Schritt zuletzt, weil er “in wp-admin editieren”-Workflows zerlegt, die niemand dokumentiert hat. Zuerst dokumentieren, sonst rollen Sie den Read-only-Flag am Samstag zurück.

Die Redakteurin, die in einen wiederverwendbaren Block pastet, der Marketer, der “ein kleines” Popup installiert, der Freelancer, der Admin hat, weil “PDF muss hoch”: diese drei Konten sind der restliche Write-Pfad. Zwei davon gehören auf editor oder eine Custom-Role, die keine Plugins installieren kann. Das PDF geht nach Uploads, und Uploads führen kein PHP aus. Wenn ein neues Plugin nötig ist, ist das ein PR, kein Freitag.

Backups sind kein Hardening, aber sie sind der Weg aus einem Vorfall. Off-Site, versioniert, Restore getestet auf einem Klon, der nicht Produktion ist. Ein Backup, das nur auf derselben VPS liegt, ist eine zweite Kopie derselben Platte. Wir spielen einen Staging-Klon zurück, bevor wir die Arbeit fertig nennen, weil ein Backup, das Sie nie restored haben, eine Datei ist, kein Plan.

Deutsche Shops hängen oft an einem Hoster-Backup “einmal täglich, 7 Tage”. Das reicht, um den Freitagabend-Stand zu verlieren, und es liegt meist im selben Account wie der Origin. Ein zweiter Bucket unter anderem Schlüssel, Restore einmal im Quartal auf einem Klon: das ist die Übung, nicht das Feature in der Hosting-Rechnung.

#Audit und weiterführende Lektüre

Das WordPress-Sicherheitsaudit ist Identität, Runtime, Edge und Logs auf Ihrem echten Host, keine generische Checkliste. Wir öffnen zuerst die wp-admin-Exposition und das Plugin-Lockfile. Lighthouse-Scores sind kein Sicherheitsignal.

Betreiberpflichten (Logging, Vorfallsuhr, benannte Kontakte) sitzen in NIS2- und DORA-Readiness. Architektur, die PHP auf dem öffentlichen Origin verkleinert, steht im Headless-Architektur-Leitfaden. Headless ist für sich kein Sicherheitscontrol. Es ist eine kleinere PHP-Fläche, wenn das Front statisch ist und wp-admin privat.

Wir verkaufen in diesem Audit keine 24-Stunden-Überwachung und keine KRITIS-Testierung. Wer das braucht, braucht einen benannten Operator und oft eine eigene oder eingekaufte SOC-Funktion. Eine Agentur, die WordPress härtet, ist das nicht.

#Fazit

WordPress-Core ist nicht der schwache Teil. Der schwache Teil ist ein öffentlicher Login, eine beschreibbare Platte, ein Security-Plugin, das startet, nachdem PHP gelaufen ist, und Logs, die mit dem Host sterben. Passkeys, ein identitätsgeschütztes wp-admin, ein schreibgeschütztes Image, eine WAF, die virtuell patchen kann, CSP mit echten Nonces, ein Lockfile und Logs außerhalb der Box. Das ist die Liste. Eine Plugin-Seite, die “protected” sagt, steht nicht darauf.

Für deutsche Betreiber kommt die Operator-Schicht dazu: Grundschutz-Logging als Stand der Technik, NIS2-Uhren nur wenn Sie wirklich Einrichtung sind, keine Selbsternennung zur KRITIS-Stelle, weil ein Sparkasse-Widget im Checkout hängt.

Schreiben Sie mit URL, Plugin-Liste und der Angabe, ob wp-admin öffentlich ist, wenn das inspiziert werden soll. Das Sicherheitsaudit ist die kommerzielle Fläche.

PCI und ISO 27001: keines davon ist ein Plugin. PCI heißt, Kartendaten liegen nie in WordPress. ISO ist der Betreiberprozess um das, was dieser Guide schon auflistet.