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

Letzten Herbst kam ein Foodblog zu uns rein — nennen wir die Bloggerin Lisa, ihren Blog Lecker mit Lisa. Die Startseite brauchte über acht Sekunden zum Laden, im Backend lagen Wordfence, iThemes Security und Sucuri parallel — drei Sicherheits-Suites auf einem einzigen Blog. Sie war stolz, dass sie „so gut abgesichert" sei. Wir haben uns einen halben Tag durchgewühlt, und das Ergebnis war ernüchternd: Ihr Login-Name war lisa (steht auch öffentlich in /author/lisa/), das Passwort war Sommer2022!, und die einzige echte Sicherheitslücke war ein Kontaktformular-Plugin, das seit zwei Jahren keinen Update mehr bekommen hatte. Keiner der drei Sicherheits-Schichten hatte irgendwas davon gemeldet. Aber alle drei arbeiteten brav bei jedem einzelnen Lasagne-Rezept im Hintergrund mit — und lieferten die Seite zwei Sekunden später aus.

Diese Konstellation begegnet uns regelmäßig. Sicherheits-Plugins sind selbst Code mit Angriffsfläche, sie kosten Tempo, und sie schützen oft genau dort, wo nichts angegriffen wird, während die echten Lücken woanders sitzen. Dieser Post ist die lange Antwort auf eine Frage, die wir oft gestellt bekommen: Brauche ich Wordfence auf meinem Foodblog? Kurzfassung — fast nie. Was Wordfence, Ninja Firewall, Sucuri und iThemes/Solid pro Aufruf wirklich tun, was davon ein Foodblog nicht braucht und welchen Mittelweg wir gebaut haben, kommt jetzt.

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 klinkt sich ganz vorne ein — noch bevor WordPress selbst gestartet ist. Eine Konfigurationsdatei sorgt dafür, dass bei jedem einzelnen Aufruf zuerst die Wordfence-Firewall startet, ihr Regelwerk mit hunderten Mustern lädt, die Anfrage prüft, IP-Reputation abfragt und meist noch einen Datenbank-Eintrag schreibt (der berühmte „Live Traffic"-Logger). Dazu der Malware-Scanner, der über die interne WordPress-Zeitplan-Mechanik läuft — heißt: Irgendein Zufalls-Aufruf eines Lesers wartet, während im Hintergrund gescannt 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 und iThemes lösen das nicht. Sie limitieren Versuche, verraten dem Angreifer aber, gegen welchen Login er es überhaupt versuchen soll.

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. Wordfence läuft sogar vor dem Page-Caching: Selbst eine gecachte Seite kostet noch den Wordfence-Boot.

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

Ein paar Funktionen, die in jeder großen Sicherheits-Suite drinstecken, ergeben für einen typischen Foodblog ehrlicherweise keinen Sinn.

Malware-Scanner auf Dateiebene. Sinnvoll bei Multi-User-Setups oder wenn du eigenen Custom-Code laufen lässt. Auf einem Foodblog mit Theme + fünf Plugins + Markdown-Inhalten? Es gibt schlicht nichts zu scannen, was nicht der Hoster auch mitbekäme. IONOS, Raidboxes und die meisten anderen ernsthaften 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 die Bots kommen längst über Wohn-Proxies aus Frankfurt. Dafür sperrst du echte Leser im Urlaub aus. Wir haben das auf einem Kunden-Blog drei Monate mitgemessen: 0,3 % geblockte Angriffe, 2,4 % geblockte echte Leser. Das Verhältnis spricht für sich.

Live Traffic Logging. Wordfence schreibt jeden Pageview in die Datenbank — bei 50.000 Pageviews im Monat sind das 50.000 zusätzliche Schreibzugriffe. DSGVO-Aufwand inklusive. Wir protokollieren nur, was sicherheitsrelevant ist (gescheiterter Login, geblockter Kommentar) — und hashen IP-Adressen vor dem Speichern mit täglich rotierendem Salt.

Real-time IP-Blocklists. Externe Reputationsdienste, pro Aufruf befragt. Latenz real, Schutzgewinn marginal — lohnt sich für eine Single-Site nicht.

Ein 2FA-Plugin zusätzlich zum Sicherheits-Plugin. Wenn 2FA, dann integriert in einer Lösung. Nicht zwei Plugins parallel mit derselben Aufgabe.

Was ein Foodblog wirklich braucht

Wenn du den Blick darauf richtest, wo auf einem Foodblog tatsächlich angegriffen wird, fällt die Liste deutlich kürzer aus, als die Plugin-Hersteller dir weismachen wollen. 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 — DSGVO-konform out of the box.
• 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. Bewusste Entscheidung gegen Captcha, weil das deine Leser nervt.
• 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 kein generisches Plugin schließt

Die wenigsten Foodblogger wissen, dass WordPress in der Standard-Konfiguration den Login-Namen jedes Autors über mehrere Wege nach außen verrät. Das ist der Punkt, an dem sich das BAP Security Plugin am stärksten von jedem generischen Sicherheits-Plugin unterscheidet — Wordfence, Ninja Firewall und iThemes adressieren das gar nicht oder nur teilweise. 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/ und denkt: legitimer Lesezugriff. Das BAP Security Plugin sieht den Aufruf und denkt: WordPress-Lücke, dichtmachen.

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. Den macht der Hoster auf Server-Ebene.
• 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. Bei einem Single-Author-Blog mit funktionierender Brute-Force-Bremse plus Honeypot ist 2FA Overkill, und Captchas verschlechtern die Conversion auf Kommentaren messbar.
• Kein PHP-Boot vor WordPress. Anders als Wordfence und Ninja Firewall klinkt sich das Plugin erst nach plugins_loaded ein. Heißt: Eine gecachte Rezeptseite wird durch das Plugin nicht verlangsamt.

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 pro Aufruf mechanisch tun muss: PHP-Prozess vor WordPress starten, Regelwerk aus der Datenbank laden, Anfrage gegen Hunderte Muster prüfen, Eintrag in die Live-Traffic-Tabelle schreiben, IP gegen Reputations-Liste prüfen. Das passiert jedes Mal — auch beim Aufruf einer voll gecachten Rezeptseite, weil Wordfence vor dem Cache läuft. Auf gutem Managed-Hosting ist die Last kleiner, aber nie null.

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". Die Wahrheit ist unbequem für die Plugin-Hersteller: Ein generisches Sicherheits-Paket kann ein spezifisches Bedrohungsmodell nicht so präzise abdecken wie eine Lösung, die für genau diese Art Blog gebaut wurde — ohne den Aufruf einer Rezeptseite mit einer Prüfschleife zu verlangsamen, die ohnehin nichts zu prüfen hat.

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, und sie kostet dich genau drei Klicks pro Quartal.

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.