Security Pilot

Security Pilot ist ein umfassendes Sicherheits-Plugin für WordPress, das Ihre Site gegen gängige Angriffe und Schwachstellen härtet. Es setzt HTTP-Sicherheitsheader nach Industriestandard, schützt die Login-Seite vor Brute-Force-Angriffen, blockiert bösartige Requests über eine eingebaute Firewall, beschränkt sensible REST-API-Endpunkte und liefert ein Ein-Klick-Audit, das die Installation von A bis F benotet.

Anders als überladene Security-Suiten ist Security Pilot schlank und modular: Aktivieren Sie nur die Schutzmaßnahmen, die Sie tatsächlich brauchen. Jedes Modul lässt sich unabhängig schalten und sämtliche Einstellungen werden über den Hauptmenüpunkt Security Pilot in der WordPress-Admin-Seitenleiste verwaltet.

Highlights

• HTTP-Sicherheitsheader — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection und Entfernen des Headers X-Powered-By.
• Login-Schutz — konfigurierbare Ratenbegrenzung, temporäre Sperren und permanente Bans für Wiederholungstäter, mit optionalen E-Mail-Alerts.
• Request-Firewall — musterbasierte Erkennung von SQL-Injection, Cross-Site-Scripting (XSS), Path Traversal, Remote File Inclusion (RFI) und Command Injection.
• REST-API-Schutz — sperrt den unautorisierten Zugriff auf sensible Endpunkt-Gruppen wie /wp/v2/users, WooCommerce, Jetpack, wp-site-health, Divi Builder und Elementor.
• WordPress-Hardening — Datei-Editor und XML-RPC abschalten, Pingbacks und Trackbacks unterdrücken, WordPress-Version verbergen, RSD-Link sowie Windows-Live-Writer-Manifest entfernen.
• Rate Limiter — IP-basierte Drosselung von 404-Fluten und anderen hochfrequenten Request-Mustern, mit konfigurierbarer maximaler Trefferzahl und Rolling Time Window.
• Form-Schutz — drosselt Frontend-Submissions, blockiert Wegwerf-E-Mail-Domains und fängt Bots über versteckte Honeypot-Felder sowie eine konfigurierbare Mindest-Ausfüllzeit ab.
• Security Check — Ein-Klick-Audit, das die Installation von A bis F bewertet und den Status pro Prüfung (PASS / WARNING / FAIL) zu Hardening, REST-API-Exposition, veralteten Plugins/Themes, Debug-Einstellungen, Datei-Editor und vielem mehr ausweist.
• Zugriffsregeln & Attack-Log — Blocked IPs, Whitelisted IPs und Whitelisted URLs aus einem dreistufigen Tab heraus verwalten, jeden blockierten Request im Attack-Log nachvollziehen.

Voraussetzungen

Security Pilot ist auf moderne, selbst gehostete WordPress-Sites ausgelegt.

• Eine funktionierende WordPress-Installation mit Administrator-Zugriff.
• Eine PHP-Version, die von Ihrer aktuellen WordPress-Version unterstützt wird.
• HTTPS wird dringend empfohlen. Den HSTS-Header sollten Sie nur aktivieren, wenn Ihre Site über jede URL per TLS erreichbar ist — inklusive der Subdomains, die mit abgedeckt werden sollen.
• Ausreichende Rechte zum Anpassen von HTTP-Response-Headern. Bei den meisten Managed-Hostern klappt das out of the box; vor manchen Reverse-Proxies oder CDNs müssen die Header an der Edge durchgelassen werden.

Es sind keine externen Dienste zu konfigurieren und keine API-Keys erforderlich. Einstellungen, Logs und Blocklisten liegen in Ihrer eigenen WordPress-Datenbank.

Installation

1. Laden Sie das Plugin-ZIP von Security Pilot herunter.
2. Öffnen Sie in WordPress Plugins → Installieren → Plugin hochladen.
3. Wählen Sie die ZIP-Datei und klicken Sie auf Jetzt installieren.
4. Klicken Sie nach Abschluss des Uploads auf Plugin aktivieren.
5. Öffnen Sie Security Pilot → Einstellungen, um die Module durchzugehen. Die vier Untermenüpunkte heißen in dieser Reihenfolge Security Check, Zugriffsregeln, Attack-Log und Einstellungen.

Nach der Aktivierung ist kein Schutz zwingend eingeschaltet — jedes Modul startet in einem definierten Zustand und lässt sich einzeln umschalten. So lässt es sich gefahrlos auf einer produktiven Site installieren und das Hardening in kleinen, reversiblen Schritten einführen.

Konfiguration

Die gesamte Konfiguration läuft über Security Pilot → Einstellungen. Die Seite gruppiert die Optionen modulweise — jedes Modul ist eine einklappbare Karte mit eigenem Aktivierungs-Schalter und einer überschaubaren Anzahl Optionen.

Eine Karte Lizenz oben akzeptiert einen Schlüssel PILOT-XXXX-XXXX-XXXX-XXXX (aus Ihrer Bestellbestätigung) und schaltet nach erfolgreicher Prüfung automatische Plugin-Updates über den GitHub-Release-Feed frei. Das Plugin funktioniert auch ohne Schlüssel vollständig; gesperrt ist nur der Auto-Update-Kanal.

HTTP-Sicherheitsheader

Das Header-Modul fügt jeder durch WordPress ausgelieferten Antwort standardkonforme HTTP-Response-Header hinzu. Schalten Sie einzelne Header je nach Bedarf ein oder aus.

Ein paar Hinweise zur Konfiguration der Header:

• HSTS ist in Browsern dauerhaft, sobald es einmal empfangen wurde. Stellen Sie sicher, dass HTTPS überall funktioniert — auch unter www und allen Subdomains, die Sie abdecken wollen — bevor Sie HSTS aktivieren.
• Die Content-Security-Policy ist der mächtigste und zugleich am weitesten ins Verhalten eingreifende Header. Starten Sie mit den reporting-freundlichen Defaults und ziehen Sie die Policy enger, nachdem Sie über die Browser-Konsole geprüft haben, welche Ressourcen auf realen Seiten blockiert werden.
• Sitzt vor Ihrer Site ein CDN oder Reverse-Proxy, der Header umschreibt, sorgen Sie dafür, dass die von Security Pilot gesetzten Werte an der Edge unverändert durchgereicht werden.

Login-Schutz

Der Login-Schutz zählt fehlgeschlagene Authentifizierungs-Versuche pro IP und löst bei Erreichen eines Schwellwerts eine Sperre aus. Nach einer konfigurierbaren Anzahl Sperren kann die IP permanent gebannt werden.

Verfügbare Einstellungen:

• Maximale Fehlversuche — Anzahl der Login-Fehlversuche einer IP, bevor eine Sperre ausgelöst wird. Erlaubt sind 1 bis 20. Der Standardwert 5 ist ein guter Ausgangspunkt.
• Versuchsfenster — das rollende Zeitfenster in Minuten, innerhalb dessen die Fehlversuche gezählt werden. Erlaubt sind 1 bis 120.
• Sperrdauer — wie lange eine gesperrte IP blockiert bleibt, in Minuten. Erlaubt sind 1 bis 1440 (24 Stunden).
• Schwellwert für permanenten Bann — Anzahl der einzelnen Sperren einer IP, bevor sie dauerhaft gebannt wird. Erlaubt sind 1 bis 20.
• E-Mail-Alerts — wenn aktiv, erhält der Site-Administrator eine E-Mail, sobald ein Angriff erkannt oder eine IP der Blocklist hinzugefügt wird.
• Detaillierte Fehlermeldungen ausblenden — generische Texte („Anmeldedaten ungültig”) ersetzen die Standardmeldungen von WordPress, sodass Angreifer nicht erkennen können, ob ein Benutzername existiert.

Der Schutz gilt sowohl für wp-login.php als auch für den XML-RPC-Authentifizierungs-Endpunkt, sofern XML-RPC aktiv bleibt.

Request-Firewall

Die Request-Firewall prüft eingehende Anfragen auf bösartige Muster und antwortet bei einem Treffer mit 403 Forbidden. Die Erkennungsmuster sind eingebaut und decken folgende Klassen ab:

• SQL-Injection — gängige Payloads gegen Query-Parameter, POST-Bodies und Cookies.
• Cross-Site-Scripting (XSS) — Signaturen für reflektierte und persistente Angriffe.
• Path Traversal — ../-Versuche, das Document-Root zu verlassen.
• Remote File Inclusion (RFI) — Verweise auf externe URLs in Kontexten, in denen lokale Pfade erwartet werden.
• Command Injection — Shell-Metazeichen in Parametern, die wahrscheinlich in system-artigen Funktionen landen.

Die Firewall hat keine Konfiguration pro Regel — sie ist entweder aktiv oder nicht. Blockierte Anfragen werden im unten beschriebenen Attack-Log mitsamt verletzendem Parameter und auslösender Regel festgehalten.

Rate Limiter (Schutz vor 404-Fluten)

Sites unter Brute-Force-Beschuss produzieren hunderte 404-Antworten pro IP und Minute, weil nach versteckten Plugin-Assets oder wp-config-Backups gesucht wird. Der Rate Limiter deckelt diesen Traffic pro Quell-IP, indem er 404-Treffer in einem rollenden Fenster zählt:

Der Block läuft über denselben Mechanismus wie der Login-Schutz und taucht im Tab Zugriffsregeln → Blocked IPs mit dem Grund 404_flood auf.

REST-API-Schutz

WordPress legt standardmäßig eine breite REST-API offen — darunter Endpunkte, die für Site-Builder nützlich, auf einer produktiven Site aber oft überflüssig sind. Security Pilot kann unauthentifizierten Zugriff auf ganze Endpunkt-Gruppen sperren, während der Rest der API unangetastet bleibt.

Geschützte Gruppen:

• /wp/v2/users — Nutzer-Enumeration über den Core-Users-Endpunkt.
• WooCommerce — Shop-, Bestell- und Kunden-Endpunkte, sobald WooCommerce installiert ist.
• Jetpack — der eigene REST-Namespace von Jetpack.
• wp-site-health — Health-Check-Endpunkte, die Informationen über die Umgebung preisgeben können.
• Divi Builder — REST-Endpunkte von Divi.
• Elementor — REST-Endpunkte von Elementor.

Aktivieren Sie den Schutz nur für die Gruppen, die Sie nicht benötigen. Eine Site ohne WooCommerce kann etwa die WooCommerce-Endpunkte gefahrlos sperren. Das Plugin prüft bei jeder Anfrage die Authentifizierung und gibt einen Autorisierungsfehler zurück, wenn ein nicht authentifizierter Aufrufer auf eine geschützte Gruppe zugreifen will.

Form-Schutz

Schützt Kontakt-, Kommentar- und Login-Formulare site-weit vor Spam, Wegwerf-E-Mail-Anmeldungen und hochvolumigen Bot-Einsendungen:

Honeypot-Fallen (versteckte Felder, die nur Bots ausfüllen) und eine Mindest-Ausfüllzeit-Prüfung laufen parallel zu den Rate-Gates. Blockierte Versuche werden im Attack-Log festgehalten.

WordPress-Hardening

Das Hardening-Modul schaltet WordPress-Funktionen aus, die häufig missbraucht werden oder Informationen preisgeben, die Angreifer zur Planung eines Exploits nutzen können. Jede Option ist unabhängig.

• Datei-Editor deaktivieren — schaltet den Theme- und Plugin- Editor im Dashboard ab (DISALLOW_FILE_EDIT). Wer Admin-Zugangsdaten erbeutet, kann den Code nicht mehr direkt aus der WordPress-Oberfläche heraus verändern.
• XML-RPC deaktivieren — blockiert den xmlrpc.php-Endpunkt, ein häufiges Ziel für Brute-Force- und Amplification-Angriffe. XML-RPC nur deaktivieren, wenn keine Integration auf der Site darauf angewiesen ist.
• Pingbacks und Trackbacks deaktivieren — schließt einen altbekannten Amplification-Vektor, der in DDoS-Kampagnen eingesetzt wurde.
• WordPress-Version verbergen — entfernt das generator-Meta-Tag und die Versions-Query-Parameter aus eingebundenen Assets, sodass die installierte WordPress-Version nicht im Seiten-Quelltext steht.
• RSD-Link entfernen — entfernt den Really-Simple-Discovery-Link, der für externe Publishing-Clients gedacht war.
• WLW-Manifest entfernen — entfernt den Link auf das Windows-Live-Writer-Manifest, der heute kaum mehr eine Rolle spielt.

Für die meisten produktiven Sites ist es sicher, alle Hardening-Optionen zu aktivieren. Insbesondere das Deaktivieren des Datei-Editors und von XML-RPC gilt in der WordPress-Sicherheits- Community als Mindeststandard.

Security Check

Die Security-Check-Seite — Security Pilot → Security Check — führt ein Ein-Klick-Audit durch und liefert eine Schulnote von A („hervorragend, Ihre Sicherheit ist stark”) bis F, ergänzt um KPI-Zähler für bestanden, fehlgeschlagen, Warnung und Prüfungen insgesamt.

Der Check prüft jede Kategorie, die das Plugin aus WordPress heraus verifizieren kann, darunter (ohne Anspruch auf Vollständigkeit):

• HTTPS für die Site-URL eingerichtet.
• Datei-Editor deaktiviert (DISALLOW_FILE_EDIT).
• XML-RPC deaktiviert.
• Debug-Logging und Debug-Anzeige in Produktion aus.
• Zugriff auf wp-config.php auf Webserver-Ebene blockiert.
• WordPress-Core, Plugins und Themes aktuell.
• Inaktive Plugins noch installiert (Angriffsfläche).
• Kein Standard-Benutzername admin vorhanden.
• REST-API-Schutz aktiv.
• HTTP-Sicherheitsheader, Login-Schutz und Request-Firewall aktiv.
• Kräftiges DB-Präfix, PHP-Exposition, Server-Signatur.

Jede Zeile zeigt einen kurzen Titel, eine einzeilige Beschreibung und ein Status-Badge (PASS, WARNING, FAIL, INFO). Das Modul Einstellungen → Security Check bietet drei optionale Schalter, die tiefer gehende Prüfungen ergänzen (veraltete Plugins, veraltete Themes, Plugin-Vulnerability-Lookup gegen einen öffentlichen Feed) — diese laufen beim Anfordern des Reports und verlangsamen ihn um einige Sekunden, weshalb sie standardmäßig aus sind. Aus dem Report heraus sind die Fixes typischerweise einen Klick weit entfernt im WordPress-Admin (Plugin aktualisieren, inaktives Plugin löschen, einen Hardening-Schalter umlegen).

Nutzung

Ein sinnvoller erster Durchlauf durch das Plugin sieht so aus.

1. Security Pilot installieren und aktivieren.
2. Security Pilot → Einstellungen öffnen.
3. HTTP-Sicherheitsheader mit den empfohlenen Defaults aktivieren. Rufen Sie ein paar Seiten Ihrer Site auf und prüfen Sie die Browser-Konsole auf unerwartete Content-Security-Policy-Verstöße.
4. Login-Schutz aktivieren. Lassen Sie Maximale Fehlversuche bei 5, wählen Sie ein Versuchsfenster von 15 Minuten und eine Sperrdauer von 60 Minuten — für eine typische Site sinnvoll. Schalten Sie E-Mail-Alerts ein, damit Sie Bescheid wissen, sobald die Site angegriffen wird.
5. Request-Firewall aktivieren. Es ist keine weitere Konfiguration nötig.
6. Rate Limiter aktivieren, um 404-Fluten abzufangen (Standard: 25 Treffer in 60 Sekunden → IP landet auf der Blocklist).
7. REST-API-Schutz für die Endpunkt-Gruppen einschalten, die die Site nicht öffentlich braucht. Die Gruppe /wp/v2/users lässt sich nahezu immer gefahrlos sperren.
8. Form-Schutz aktivieren auf Sites mit Kontakt-/ Kommentarformularen — wählen Sie einen sinnvollen IP-Cooldown und eine TLD-Blocklist.
9. WordPress-Hardening-Optionen aktivieren. Mindestens den Datei-Editor und XML-RPC auf produktiven Sites deaktivieren.
10. Security Check ausführen und jede WARNING- und FAIL-Zeile abarbeiten (gelistete Plugins/Themes aktualisieren oder löschen, markierte Hardening-Schalter umlegen).

Nach diesem ersten Durchlauf kehren Sie regelmäßig zu Security Pilot → Security Check zurück, um die Note über C zu halten, und werfen einen Blick in Attack-Log und Zugriffsregeln, um zu sehen, was abgefangen wurde.

Zugriffsregeln prüfen

Der Bildschirm Zugriffsregeln (Security Pilot → Zugriffsregeln) ist eine zentrale Steuerzentrale mit drei Tabs für IP- und URL-basierte Block- und Whitelists:

• Blocked IPs — alle Adressen, die aktuell vom Login-Schutz, vom Rate Limiter oder der Firewall blockiert sind. Jede Zeile zeigt die IP, den Block-Grund (z. B. firewall:path_traversal, 404_flood, firewall:sqli), den Zeitpunkt der Aufnahme und einen Unblock-Button. Ein einfaches Formular oben lässt beliebige IPs manuell sperren — optional mit Grund — und ein Suchfeld filtert nach IP oder Grund.
• Whitelisted IPs — Adressen, die von jeder Prüfung ausgenommen sind (Büro, Monitoring-Dienst, Staging-Server, Ihre Heim-IP).
• Whitelisted URLs — Pfade, die vom 404-Rate-Limiter ausgenommen sind (nützlich, wenn ein legitimer Endpunkt schlüssig in Schüben 404 liefert).

Über diesen Bildschirm können Sie:

• eine Adresse freigeben, die durch einen legitimen Nutzer mit tippselig eingegebenem Passwort gesperrt wurde;
• eine bekannte, vertrauenswürdige IP whitelisten (Ihr Büro, Monitoring-Dienst, Staging-Server), damit sie nicht versehentlich gesperrt wird;
• eine URL whitelisten, die das 404-Rate-Limit bestimmungsgemäß erreicht (etwa ein Probe-Pfad, den externes Monitoring abfragt).

Attack-Log prüfen

Das Attack-Log (Security Pilot → Attack-Log) erfasst jeden blockierten Request — also Brute-Force-Sperren, Firewall-Treffer, Rate-Limiter-Sperren, Form-Spam-Bounces und REST-API-Ablehnungen. Jede Zeile enthält Zeitstempel, Quell-IP, Angriffstyp (z. B. RESTRICTION, REQUEST_URI, PATH_TRAVERSAL, COMMAND_INJECTION, POST_X), den Regel-Listener, der den Block ausgelöst hat, und die auslösende Request-URI. Mit Log leeren lässt sich die Tabelle gesammelt entleeren; die Toolbar bietet eine Volltextsuche sowie Filter nach IP und Listener.

Das Log ist sowohl für die Nachbetrachtung von Vorfällen als auch für die Feinjustierung der Firewall nützlich: Erscheint eine legitime Anfrage Ihrer Site im Log, lässt sich die verantwortliche Regel identifizieren — Sie entscheiden dann, ob Sie die Anfrage oder die IP whitelisten oder die Regel verfeinern.

WordPress-Dashboard-Widget

Security Pilot ergänzt das Standard-Dashboard (die Seite, die WordPress nach dem Login öffnet) um ein Widget, damit die Kernkennzahlen direkt nach dem Einloggen sichtbar sind.

Das Widget zeigt:

• die jüngste Security-Check-Note (A–F) und den numerischen Score (z. B. A 95/100) als farbigen Ring;
• einen Live-Zähler Blocked IPs, gespeist aus der Zugriffsregeln-Tabelle;
• einen laufenden Zähler Angriffe aus dem Attack-Log;
• die Liste Aktuelle Angriffe — die letzten fünf Zeilen des Attack-Logs mit Typ-Badge, Quell-IP und Zeitstempel;
• im Footer Shortcuts zu Attack-Log und Vollständiger Sicherheitsbericht.

FAQ

Ersetzt Security Pilot andere Sicherheits-Plugins?

Für die meisten Sites: ja. Security Pilot deckt HTTP-Header, Login-Schutz, Request-Filterung, REST-API-Restriktionen, Hardening und Auditing ab. Es ist bewusst schlank gehalten und keine „Schweizer-Taschenmesser”-Suite. Es parallel zu einer weiteren Firewall oder einem Login-Schutz-Plugin zu betreiben, ist technisch möglich, aber selten sinnvoll und kann dazu führen, dass überlappende Regeln doppelt feuern.

Werden die Header meine Site zerschießen?

Die Standardwerte sind konservativ. Am häufigsten ist Feinarbeit bei HSTS und Content-Security-Policy nötig.

• HSTS erst dann aktivieren, wenn die Site vollständig über HTTPS erreichbar ist — inklusive aller abzudeckenden Subdomains. Der Header wird im Browser gecached und lässt sich nicht ohne Weiteres widerrufen.
• Die Content-Security-Policy nach einem Blick in die Browser-Konsole auf reale Seiten justieren. Eigene Skripte, Schriftarten und Analytics müssen oft in die Policy aufgenommen werden.

Blockiert die Request-Firewall legitimen Traffic?

Die Erkennungsmuster zielen auf bekannte Angriffssignaturen ab und sind in der Regel spezifisch. Falls eine legitime Anfrage blockiert wird, erscheint sie im Attack-Log mit der auslösenden Regel. Sie können die IP dann freigeben und die Ausnahme — sofern das Muster wirklich unvermeidbar ist — für Ihr Team dokumentieren.

Funktioniert das Plugin hinter einem CDN oder Reverse-Proxy?

Ja. Das Plugin liest die ursprüngliche IP aus den Standard-Request-Headern und erkennt Besucher hinter einem CDN korrekt, sofern Ihre Hosting-Umgebung den passenden Header (X-Forwarded-For oder Äquivalent) durchreicht. Achten Sie darauf, dass keine Edge-Schicht vor WordPress die von Security Pilot gesetzten Response-Header entfernt.

Kann ich Attack-Logs oder Blocked-IP-Listen exportieren?

Attack-Log und Blocked-IP-Tabelle liegen in Ihrer WordPress-Datenbank und lassen sich direkt im Adminbereich einsehen. Für eine langfristige Archivierung oder Off-Site-Analyse nehmen Sie ein Datenbank-Backup wie bei jeder anderen WordPress-Datenhaltung auch.

Bricht das Deaktivieren von XML-RPC irgendetwas?

XML-RPC wird vom alten Windows-Live-Writer-Client, in bestimmten Konfigurationen von den WordPress-Mobile-Apps und einer kleinen Zahl von Drittanbieter-Integrationen genutzt. Wenn Sie nichts davon einsetzen, gehört das Abschalten von XML-RPC zu den effektivsten Ein-Klick-Hardening-Maßnahmen überhaupt.

Bleiben die Einstellungen erhalten, wenn ich das Plugin deaktiviere?

Ja. Beim Deaktivieren bleiben Ihre Konfiguration, das Attack-Log und die Blocklist in der Datenbank — beim erneuten Aktivieren ist der vorherige Zustand sofort wieder da.

Fehlerbehebung

Ein legitimer Nutzer ist gesperrt

Öffnen Sie Blocked IPs, suchen Sie den Eintrag der betroffenen Adresse und entfernen Sie den Block. Wird derselbe Nutzer immer wieder gesperrt, denken Sie über folgende Maßnahmen nach:

• Maximale Fehlversuche für vergessliche Nutzer hochsetzen.
• Die IP des Nutzers (oder die Büro-NAT-IP) in die Allowlist aufnehmen.
• Den Nutzer bitten, sein Passwort zurückzusetzen, statt es zu raten.

Der Browser blockiert Ressourcen nach Aktivierung der CSP

Die Content-Security-Policy ist bewusst streng. Öffnen Sie die Entwicklerwerkzeuge des Browsers und sehen Sie sich den Konsolen-Tab an — der Browser meldet jede blockierte Ressource samt der Direktive, die sie abgelehnt hat. Passen Sie die CSP so an, dass die vertrauenswürdigen Origins (CDN, Analytics-Provider, Schriften-Host) Ihrer Site enthalten sind.

Seiten laden trotz HSTS weiterhin über HTTP

HSTS greift erst, nachdem der Browser den Header mindestens einmal über HTTPS gesehen hat. Rufen Sie die Site direkt über https:// auf, um den Cache zu primen. Ist die Site noch nicht über jede beworbene URL per HTTPS erreichbar, deaktivieren Sie HSTS, bis die Umstellung abgeschlossen ist.

REST-API-Integrationen funktionieren nicht mehr

Falls eine Integration, die eine geschützte Endpunkt-Gruppe nutzt, nicht mehr funktioniert, deaktivieren Sie den Schutz für diese Gruppe unter REST-API-Schutz vorübergehend und prüfen, ob die Integration sich korrekt authentifiziert. Viele Integrationen erwarten, als authentifizierter WordPress-Nutzer aufgerufen zu werden; authentifizierte Anfragen werden von diesem Modul nicht blockiert.

Header sind in der Antwort nicht enthalten

Manche Hoster oder Reverse-Proxies entfernen oder überschreiben Response-Header, die PHP setzt. Prüfen Sie die Header etwa mit curl -I https://example.com/ oder dem Netzwerk-Inspector Ihres Browsers. Fehlt ein Header, lesen Sie in der Hoster-Doku nach, wie benutzerdefinierte Header durchgelassen werden — oder setzen Sie den Header an der Edge, falls der Hoster es voraussetzt.

E-Mail-Alerts kommen nicht an

E-Mail-Alerts laufen über die wp_mail()-Funktion von WordPress. Wenn keine Mail eintrifft, liegt das fast immer an der Mail-Konfiguration der Site, nicht an Security Pilot. Installieren Sie ein Transaktions-Mail-Plugin (etwa eines, das WordPress-Mails über SMTP versendet) und testen Sie erneut, indem Sie aus einem Test-Browser eine Sperre auslösen.