Wordfence, Ninja Firewall & Co., warum Sicherheitsplugins deinen Foodblog ausbremsen (und was wir stattdessen tun)

Wir haben das selbst lange anders gemacht. Auf den ersten Foodblog-Projekten der Agentur lag standardmäßig Wordfence drauf, weil es das tut, was alle tun, und weil niemand sagen können sollte, "die haben nichts installiert". Bis uns auf einer Kundinnen-Seite aufgefallen ist, dass die Rezeptseite spürbar schneller wurde, sobald wir Wordfence nur abschalteten. Nicht deinstallierten, abschalteten. Daraus ist über zwei Jahre hinweg eine Beobachtung geworden, die diesen Post trägt: Generische Sicherheits-Plugins prüfen auf jedem Aufruf einer Lasagne-Rezeptseite Hunderte Muster, die für eine Lasagne-Rezeptseite mechanisch gar nicht greifen können. Sie schützen breit, aber an der falschen Stelle.

Was an einem Foodblog tatsächlich angegriffen wird, Login, Kommentare, Bewertungen, REST, XML-RPC, ist eine kurze, klar umrissene Liste. Der Aufruf einer Rezeptseite gehört nicht dazu. In diesem Post vergleichen wir, was Wordfence, Ninja Firewall, Sucuri und iThemes pro Aufruf mechanisch tun, und welche Mitte zwischen "nichts" und "Wordfence" für einen Foodblog passt. Sicherheits-Plugins sind selbst Code mit Angriffsfläche, sie kosten Tempo, und sie prüfen oft auf Mustern, die im Foodblog-Kontext gar nicht entstehen können, die Frage ist nicht, ob WordPress geschützt gehört, sondern wo der Schutz greift.

Wenn du parallel die zwölf praktischen Sofort-Maßnahmen lesen willst: 12 Sicherheitsmaßnahmen, die jeder Foodblogger selbst umsetzen kann. Hier geht es um die Frage dahinter.

Was machen Wordfence, Ninja Firewall & Co. technisch?

Damit klar ist, worüber wir reden: Die vier großen Sicherheits-Lösungen für WordPress arbeiten alle auf unterschiedlichen Ebenen, und diese Ebene entscheidet, wie viel sie pro Seitenaufruf kostet.

Wordfence läuft je nach Schutzstufe entweder als normales Plugin nach dem WordPress-Start oder im optimierten "Extended Protection"-Modus schon davor. In diesem optimierten Modus startet bei PHP-Anfragen zuerst die Wordfence-Firewall, lädt ihr Regelwerk, prüft die Anfrage gegen viele Muster und wertet bei Premium-Setups auch Reputationsdaten aus. Dazu kommen Live-Traffic-Logging und Malware-Scans über die interne WordPress-Zeitplan-Mechanik. Das ist technisch sinnvoll, wenn du eine breite WordPress-WAF willst, aber es ist eine breite Prüfung auf einer Rezeptseite, die meistens nur gelesen wird.

Ninja Firewall macht das Gleiche an derselben Stelle (vor WordPress), ist aber deutlich schlanker. Kein Datenbank-Logging in der Free-Variante, kleineres Regelwerk. Wer eine vor-WP-WAF will, fährt damit besser als mit Wordfence, kostet aber jeden Aufruf trotzdem einen zusätzlichen PHP-Boot.

Sucuri ist architektonisch komplett anders: Die eigentliche Firewall sitzt nicht auf deinem Server, sondern als Cloud-Schicht davor. Du leitest deinen DNS auf Sucuri um, Sucuri filtert, leitet weiter. Auf deinem Server läuft kein zusätzlicher PHP-Code, deine Pageloads werden also nicht verlangsamt. Dafür kostet das ab 199 $/Jahr.

iThemes Security (heute Solid Security) greift als klassisches WordPress-Plugin nach dem normalen WordPress-Start. Performance-Last geringer als Wordfence, dafür sitzt der Schutz erst hinter WordPress. Das Plugin hatte 2024 mehrere bekannt gewordene Sicherheitslücken, was die Grundsatzfrage aufwirft: Wer schützt das Schutz-Plugin?

Was alle vier gemeinsam haben: Sie sind generisch. Geschrieben für irgendeinen WordPress-Blog, Foodblog, Anwaltskanzlei, Vereinsseite, Affiliate-Schleuder, alles dieselbe Engine. Niemand davon weiß, dass deine Sterne-Bewertungen unter bap_submit_rating laufen oder dass ein Favoriten-Toggle eine Post-ID erwartet. Diese Universalität ist der Grund, warum die Pakete so groß sind, und damit auch der Grund, warum sie so viel Tempo kosten.

Warum das speziell Foodblogs trifft

Es gibt drei Gründe, warum ein Foodblog von einem generischen Sicherheits-Plugin überproportional ausgebremst wird.

Rezeptseiten haben fast keine interaktive Fläche. Wenn ein Leser dein Lasagne-Rezept aufruft, lädt der Browser Text und Bilder. Die einzigen Schreib-Endpunkte sind Sterne-Rating und Favoriten-Klick, schmale Endpunkte mit klar umrissenem Inhalt (eine Zahl 1-5, eine Post-ID). Eine WAF mit Hunderten Mustern auf SQL-Injection und Cross-Site-Scripting bringt hier wenig: Was diese Endpunkte brauchen, ist ein hartes Tempo-Limit und eine Plausibilitätsprüfung, keine Mustererkennung auf einem Body, der die Zahl 4 enthält.

Foodblogs sind meistens Single-Author-Blogs. Du bist die Autorin, du postest. WordPress legt für jeden User intern den Login-Namen als URL-Slug an, wenn du dich kati2024 nennst, ist /author/kati2024/ öffentlich erreichbar, und jeder Bot kennt deinen Login nach 30 Sekunden. Wordfence kann mehrere Standardwege zur Username-Enumeration blocken (?author=1, oEmbed, REST, User-Sitemaps). Was generische Plugins aber nicht zuverlässig wissen können: welche Theme-, Autorenbox- oder Rezept-Komponenten auf deinem konkreten Blog zusätzlich Namen nach außen geben.

Rezeptseiten sind dein SEO-Asset. Google gewichtet Core Web Vitals als Rankingfaktor genau auf den URLs, mit denen du Geld verdienst. Eine WAF, die LCP um 200 ms verschlechtert, verschlechtert dein Ranking exakt da, wo du gefunden werden willst. Im Extended-Protection-Modus läuft Wordfence früh im PHP-Stack, also vor vielen WordPress-Cache-Schichten. Je nachdem, wie dein Cache technisch ausliefert, kann selbst eine gecachte Rezeptseite noch Firewall-Overhead mitbekommen.

Was tatsächlich an einem Foodblog passiert, sind drei Dinge: Bot-Sweeps gegen den Login, Spam-Floods in Kommentaren, gelegentlich Manipulation an den Sterne-Bewertungen. Alle drei brauchen kein generisches WAF-Regelwerk, endpunktspezifisches Tempo-Limit und ein paar gezielte Filter reichen.

Was an Sicherheits-Plugins zu viel ist

Mehrere Funktionen, die in jeder großen Sicherheits-Suite serienmäßig drin sind, lösen Probleme, die auf einem typischen Foodblog mechanisch gar nicht entstehen, und kosten dafür Tempo an Stellen, an denen Tempo zählt.

Malware-Scanner auf Dateiebene. Sinnvoll bei Multi-User-Setups, eigenem Custom-Code oder wenn viele wechselnde Plugins installiert sind. Auf einem betreuten Foodblog mit überschaubarem Theme- und Plugin-Set ist ein dauernder PHP-basierter Zusatzscanner oft nicht die erste Schutzschicht. Viele ernsthafte WordPress-Hoster machen Filesystem-Scans auf Server-Ebene, ohne deinen Pageload zu blockieren.

GeoIP-Country-Blocking. Klingt mächtig, wir blocken einfach China und Russland. In der Praxis kostet es Tempo (GeoIP-Datenbank im RAM oder API-Call pro Aufruf), und Bots kommen längst über Wohn-Proxies aus Frankfurt, Berlin oder Köln; Country-Blocking sieht sie nicht. Was Country-Blocking schon sieht, ist deine Stamm-Leserin, die im Urlaub auf den Kanaren oder über ein Hotel-WLAN in Bangkok dein neues Sommer-Rezept lesen will. Auf einem Kunden-Blog, den wir drei Monate mitgemessen haben, standen 0,3 % geblockte Angriffe gegen 2,4 % geblockte echte Leser. Wer GeoIP einsetzt, hat dafür Gründe, auf einem Foodblog tragen die selten.

Live Traffic Logging. Wordfences Live Traffic kann jeden Pageview in eine eigene Tabelle schreiben, wenn der Logging-Modus auf "All Traffic" steht. Bei 50.000 Pageviews im Monat wären das 50.000 zusätzliche Schreibzugriffe und viele IP-Datensätze, für die du in der Datenschutzerklärung eine eigene Klausel und ein Lösch-Konzept brauchst. Wordfence empfiehlt inzwischen selbst für viele Setups "Security Only", also nur sicherheitsrelevante Ereignisse. Genau diesen Weg gehen wir konsequent: gescheiterter Login, geblockter Kommentar, gehashte IP mit täglich rotierendem Salt.

Real-time IP-Blocklists. Reputationslisten können bekannte Angreifer früh blockieren. Für große oder stark angegriffene Sites ist das sinnvoll. Für eine einzelne Foodblog-Seite ist der Zusatznutzen oft kleiner als die zusätzliche Komplexität, zumal Wohn-Proxies und rotierende Bot-Netze die Trefferquote begrenzen.

Ein 2FA-Plugin zusätzlich zum Sicherheits-Plugin. 2FA kann für Administratoren sinnvoll sein, gerade wenn mehrere Personen Zugriff haben. Was auf einem Single-Author-Foodblog selten hilft: noch ein zweites Plugin parallel, das dieselbe Login-Fläche absichert und zusätzliche Komplexität in den Stack bringt.

Was ein Foodblog wirklich braucht

Was uns bei Plugin-Audits regelmäßig auffällt: drei parallel installierte Sicherheits-Suiten, deren tatsächliche Lücke in einem ungepflegten Formular- oder Slider-Plugin sitzt, eine Stelle, die keine der drei Suiten adressiert, weil keine von ihnen weiß, welche zusätzlichen Plugins auf dem Blog laufen. Wenn man die Frage andersherum stellt, was wird auf einem Foodblog wirklich angegriffen?, fällt die Liste deutlich kürzer aus, als die Plugin-Hersteller einem nahelegen. Wir haben diese Liste systematisch durchgearbeitet und für jeden Punkt entschieden: Gehört das ins Theme, oder gehört das ins Sicherheits-Plugin?

Im Foodblogliebe-Theme lebt der Schutz für die zwei rezept-eigenen Schreib-Endpunkte:

• Sterne-Bewertung. Token zur Form-Absicherung Pflicht, Wert muss eine ganze Zahl von 1 bis 5 sein (sonst abgelehnt), Cookie-basierte Sperre verhindert Mehrfach-Bewertungen pro Rezept, hartes Tempo-Limit von zehn Stimmen pro fünf Minuten pro Quelle. Speicherung der Quelle als gehashter Wert mit täglichem Salt, keine Klartext-IP. Schutz vor Bewertungs-Manipulation, ohne dass der reine Aufruf einer Rezeptseite eine einzige Sicherheitsprüfung kostet.
• Favoriten. Token zur Form-Absicherung Pflicht. Gäste speichern ihre Favoriten im Browser (kein Datenbank-Schreibzugriff durch Anonyme), Newsletter-Abonnenten in einer eigenen Tabelle. Der Anmelde-Endpunkt für Favoriten-Newsletter hat ein Tempo-Limit von fünf Versuchen pro Stunde pro IP.

Das gehört ins Theme, weil nur das Theme weiß, was ein gültiger Bewertungs- oder Favoriten-Aufruf überhaupt ist. Eine externe WAF kann nicht prüfen, ob die übergebene Post-ID zu einem echten Rezept gehört, das Theme schon.

Im BAP Security Plugin (das Foodblogliebe-Sicherheitspaket, das bei jedem Theme kostenlos dabei ist) liegt alles, was über den Rezeptbereich hinausgeht:

• Login-Schutz mit Brute-Force-Bremse. Fünf Versuche in 15 Minuten, dann 30 Minuten Sperre. Audit-Log mit gehashter IP und täglich rotierendem Salt, datensparsam statt Klartext-IP-Sammlung.
• Login-Honeypot plus Zeitprüfung. Verstecktes Eingabefeld mit pro-Site randomisiertem Namen plus signierter Zeitstempel im normalen wp-login.php. Füllt ein Bot das Feld aus oder submittet er in unter zwei Sekunden, schlägt der Login mit derselben Fehlermeldung wie bei falschem Passwort fehl, der Bot merkt nicht, dass er erwischt wurde. Honeypot-Treffer fließen bewusst nicht in die Brute-Force-Sperre ein, sonst sperrten Bots auf einem geteilten Proxy legitime Nutzer aus. Bewusst kein Captcha, eine zeitgeprüfte Honeypot-Logik fängt Login-Bots zuverlässiger als ein Captcha, weil der Bot nicht merkt, dass er erwischt wurde.
• Comment-Schutz. Honeypot plus Zeitprüfung plus E-Mail-Domain-Whitelist plus Mindest-Wortzahl plus optionaler Emoji- und Sprachfilter. Holt in der Praxis 99 % des Spam-Aufkommens, wieder ohne Captcha.
• REST-API-Benutzerliste dicht. Die Standard-Schnittstelle /wp-json/wp/v2/users listet sonst alle postenden User mit Login-Namen. Für nicht eingeloggte Anfragen geblockt.
• Author-Hardening, sechs Schichten gegen die WordPress-Default-Lücke, dass /author/admin/ öffentlich erreichbar ist und damit deinen Login leakt. Mehr dazu unten in der Grafik.
• XML-RPC dreifach abgeklemmt. Eine alte WordPress-Schnittstelle, die heute praktisch nur noch von Angreifern für Brute-Force-Verstärkung benutzt wird. Filter aus, Methodenliste leer, Pfad-Block, plus der X-Pingback-Header raus.
• Standard-Hardening. Versionsnummer aus dem Header (Angreifer wissen nicht, gegen welche Version sie probieren), REST-API-Link aus dem Header, Application Passwords abgeschaltet.
• Statische Pfad-Block-Liste. Eine kleine JSON-Datei mit bekannten Recon-Pfaden, /.env, /wp-config.php, /.git/, /phpinfo.php. Kein generisches WAF-Regelwerk, sondern eine Handvoll Vergleiche, die du in 20 Sekunden auditierst.

Das ist die ehrliche Mitte zwischen "nichts" und "Wordfence". Wenig genug, um auf einer Rezeptseite null spürbare Last zu erzeugen. Viel genug, um genau die Angriffsmuster abzudecken, die auf einem Foodblog in der Praxis vorkommen.

Author-Hardening, die WordPress-Lücke, die generische Plugins nur teilweise schließen

WordPress verrät in der Standard-Konfiguration den Login-Namen jedes Autors über mehrere Wege. Das ist eine WordPress-Eigenheit, an die sich auch erfahrene Admins immer wieder neu erinnern müssen, geschlossen wird sie out of the box nie. Einige Sicherheitsplugins adressieren Teile davon, zum Beispiel Standard-Author-Scans, REST-Ausgaben oder User-Sitemaps. Das BAP Security Plugin geht weiter, weil es zusätzlich die Stellen absichert, an denen das Foodblogliebe-Theme selbst Autorendaten ausgeben kann. Die Grafik macht das anschaulich:

Sechs Schichten greifen dagegen: (1) Pro-Person-Sichtbarkeit als Profil-Häkchen, (2) globaler Schalter für /author/* und Trick-Links wie ?author=1, (3) URL-Maskierung im Beitragsfuß (ID- oder Hash-Form statt Login-Slug), (4) oEmbed-Bereinigung beim Einbetten in andere Blogs, (5) leere User-Sitemap unter /wp-sitemap-users-*.xml, (6) Slug-Erzwingung beim Anlegen neuer User plus optionaler Migrator für Bestand.

Eine generische WAF sieht den Aufruf von /author/admin/ erst einmal als normalen Lesezugriff und braucht eine Zusatzregel, um daraus ein Enumeration-Problem zu machen. Das BAP Security Plugin behandelt diese Wege von Anfang an als WordPress-Hardening-Thema.

Die Architektur-Entscheidung, warum zweigeteilt

Dass wir den Schutz auf zwei Pakete verteilt haben (Theme + Plugin), ist keine Marketing-Spielerei. Es folgt aus zwei Beobachtungen.

Erste Beobachtung: Rezept-spezifische Endpunkte wie das Sterne-Rating brauchen rezept-spezifische Validierung. Eine generische Lösung kann nicht prüfen, ob die übergebene Post-ID zu einem echten Custom-Post-Type rezept gehört. Das muss im Theme liegen.

Zweite Beobachtung: Alles, was nicht rezept-spezifisch ist, gehört nicht ins Theme. Login-Schutz, Comment-Filter, REST-Härtung, XML-RPC, das betrifft jeden WordPress-Blog, egal welches Theme. Diese Logik im Theme zu vergraben würde bedeuten: Wer auf ein anderes Theme umzieht, verliert den Sicherheits-Layer. Deshalb läuft sie in einem standalone-fähigen Plugin, das auch ohne unser Theme funktioniert. Konkreter Beweis, dass das nicht Theorie ist: Wir haben gerade das ganze Author-Hardening-Modul aus dem Theme ins Plugin migriert.

Was das BAP Security Plugin bewusst nicht macht, und das ist der eigentliche Architekturkern:

• Keine generische WAF mit hunderten Mustern. Nur die kleine Pfad-Block-Liste in einer JSON-Datei.
• Kein Malware-Scanner. Diese Prüfung gehört bei betreuten Setups eher auf Hoster- oder Server-Ebene als in den normalen Seitenaufruf.
• Keine GeoIP-Datenbank, keine externen API-Calls, keine Cloud-Abhängigkeit. Alles läuft lokal im PHP-Stack des Blogs.
• Kein Live-Traffic-Logging. Nur Sicherheits-Events landen im Audit-Log, mit gehashter IP.
• Kein Captcha. Kein 2FA-Bundle. Das Sicherheitspaket hält die Login- und Kommentarflächen schlank: Brute-Force-Bremse, Honeypot und Zeitprüfung statt sichtbarer Hürden für Leser. Wer 2FA für den Admin-Account will, kann sie gezielt ergänzen, sie muss aber nicht als weiteres Bundle jede Foodblog-Installation schwerer machen.
• Kein PHP-Boot vor WordPress. Anders als Wordfence und Ninja Firewall klinkt sich das Plugin erst nach plugins_loaded ein. Heißt: Eine sauber aus dem Cache ausgelieferte Rezeptseite sollte nicht durch das Plugin verlangsamt werden.

Pro Endpunkt-Klasse genau die Prüfung, die zum Bedrohungsmodell eines Foodblogs passt, und kein Gramm mehr. Der Aufruf einer Rezeptseite kostet null zusätzliche Sicherheits-Last, abgesehen von der schmalen Pfad-Block-Prüfung (eine String-Vergleichsschleife über weniger als zehn Einträge).

Was kostet Wordfence wirklich pro Aufruf?

Ehrliche Vorbemerkung: Wir haben für diesen Post keine eigenen Vergleichsmessungen auf identischer Hardware gefahren. Saubere Performance-Zahlen kommen in einem eigenen Folge-Post im dritten Quartal 2026, mit Setup, Methodik und reproduzierbaren Werten.

Was sich auch ohne Messung sagen lässt, folgt aus dem, was Wordfence je nach Konfiguration mechanisch tun muss: im optimierten Modus den PHP-Prozess vor WordPress starten, Firewall-Regeln laden, die Anfrage gegen viele Muster prüfen, bei aktivem "All Traffic"-Logging zusätzliche Traffic-Daten schreiben und bei Premium-Features Reputationsdaten auswerten. Das ist auf gutem Managed-Hosting kleiner als auf Billig-Hosting, aber nicht null, auch dann nicht, wenn die Rezeptseite selbst aus dem Cache kommt.

Ninja Firewall macht das schlanker (kein Datenbank-Logging in Free), iThemes/Solid greift erst nach WordPress, Sucuri kostet auf deinem Server gar nichts, weil es davor läuft. Foodblogliebe-Theme plus BAP Security Plugin kostet auf der Rezeptseite null zusätzliche Datenbank-Aufrufe, weil der Schutz nur dort greift, wo wirklich geschrieben wird.

Wer trotzdem ein Sicherheits-Plugin oder eine Cloud-WAF braucht

Wir wollen hier keinen Dogmatismus verkaufen. Es gibt Fälle, in denen ein generisches Sicherheits-Plugin oder eine Cloud-WAF berechtigt sind:

• Multi-Author-Redaktionen mit mehr als fünf aktiven Autoren plus Custom-Code. Hier ist eine Cloud-WAF wie Sucuri sinnvoll, weil sie auf Edge-Ebene filtert, der eigentliche Server bleibt schnell.
• WooCommerce-Shops mit Bezahlfunktion. Eigene Anforderung, eigener Post. Brute-Force auf einen Login ist hier nicht das Hauptproblem, Card-Skimming und Order-Manipulation sind es.
• Eigener VPS oder Root-Server ohne Managed-Hosting. Hier macht Cloudflare als Edge-WAF Sinn, weil dir der Hoster die Server-Ebene nicht abnimmt.
• Wer Wordfence partout behalten will, sollte zumindest die Scanner abschalten (das ist der größte Brocken bei der internen Zeitplan-Mechanik) und das Live-Traffic-Logging deaktivieren, beides ohne nennenswerten Schutzverlust für einen Single-Author-Foodblog.

Für den klassischen Foodblog mit einer Autorin, ein paar hundert Rezepten, Affiliate-Links und vielleicht einem Newsletter ist nichts davon nötig.

Fazit

Sicherheit ist auf einem Foodblog kein Plugin-Problem. Es ist ein Architektur-Problem. Wer Sicherheit dorthin packt, wo geschrieben wird, Login, Kommentare, Bewertungen, REST-Schnittstelle, XML-RPC, kann die Rezeptseiten in Ruhe lassen und wird damit für Google sichtbarer als Konkurrenten, die alles mit Wordfence "schützen". Ein generisches Sicherheitspaket schützt einen Foodblog gleichmäßig auf 100 % seiner Fläche, obwohl 95 % dieser Fläche keine Schreib-Endpunkte sind. Eine foodblog-spezifische Architektur bündelt den Schutz an den fünf Prozent, an denen wirklich etwas passiert, und lässt die Rezeptseiten in Ruhe laufen.

Unser Tipp, falls du gerade einen Foodblog hast: Egal mit welcher Lösung du fährst, schalte nach der initialen Plugin-Installation den Plugin- und Theme-Upload aus dem Backend ab. Wenn du mal ein neues Plugin brauchst, schaltest du den Schalter wieder kurz an, lädst hoch, schaltest aus. Das ist eine der wirksamsten Maßnahmen überhaupt gegen Backdoors, kostet pro Quartal drei Klicks und nimmt eine Backdoor-Klasse aus dem Spiel, gegen die kein Sicherheitsplugin etwas ausrichten kann.

Wenn du jetzt eine Schwester-Liste mit den zwölf praktischen Sofort-Maßnahmen willst, die du heute Abend selbst umsetzen kannst, ohne ein Plugin-Bundle zu kaufen: 12 Sicherheitsmaßnahmen, die jeder Foodblogger selbst umsetzen kann. Wenn dich die technische Umsetzung im Detail interessiert, haben wir die Architektur in drei Kursen aufgeschrieben, WordPress-Sicherheit für Foodblogs (Grundlagen), Sicherheitsfeatures im Foodblogliebe-Paket (Theme- und Plugin-Mechanik) und Kundenbereich, Sicherheit und Updates (laufende Pflege). Wer das Ganze einfach übergeben will, ist mit dem Foodblog-WordPress-Angebot am direktesten, Theme inklusive Sicherheits-Plugin, Pflege inbegriffen. Den Hintergrund, warum es dieses Angebot gibt, haben wir hier ausgeführt: Warum es ein eigenes Foodblog-WordPress-Angebot von Foodblogliebe gibt. Falls dein Hoster Teil des Problems ist: Das ideale WordPress-Hosting für einen Foodblog.