Auf die Frage nach Sicherheit im Web gibt es eine Standardantwort: Eine Web Application Firewall, kurz WAF, gehört der Anwendung vorgelagert, zwischen Internet und Server. Sie prüft jede Anfrage, bevor sie den eigentlichen Code erreicht. Soweit die Theorie. In der Praxis steht diese Komponente in vielen Projekten gar nicht zur Verfügung. Genau hier setzt Phirewall an: eine WAF, die nicht vor der Anwendung sitzt, sondern in ihr.
Was ist das Problem?
Wer Internetseiten betreut, kennt die Symptome, auch ohne sie “Angriff” zu nennen. Die Logs laufen über: Tausende Fehlermeldungen pro Tag, 404er, 500er, auffällige URL-Parameter, und die echten Fehler gehen darin unter. Gleichzeitig steigt die Last, weil Crawler und immer aktivere AI-Bots eine Seite überrollen, das Caching ignorieren und Ressourcen verbrauchen, die den echten Nutzern gehören.
Dazu der klassische Angriff, meist vollautomatisiert: Scans nach bekannten Schwachstellen, die immer gleichen Muster aus SQL Injection, Cross-Site-Scripting und Path Traversal. Und die Formulare, mit denen sich jede Anwendung nach außen öffnet: Spam, Fake-Registrierungen, Brute-Force und Passwort-Spray auf Logins. Vier unterschiedliche Probleme mit einer Gemeinsamkeit: Sie kosten Performance, Nerven und Geld, lange bevor jemand von einem “Sicherheitsvorfall” spricht.
Die ideale Architektur und die Projektrealität
Die Lehrbuchantwort ist eine vorgelagerte Schutzschicht: spezialisierte, meist teure Software, teils sogar hardwarebasierte Lösungen. Hinzu kommen externe Dienste wie Cloudflare, Azure WAF oder AWS WAF. Auf dem Papier ideal, in der Praxis oft nicht machbar.
Die Gründe wiederholen sich von Projekt zu Projekt: Managed- oder Shared-Hosting ohne tiefen Zugriff, wo eigene Server-Regeln nicht möglich sind. Abhängigkeit von der internen IT, die jede Änderung zur Terminfrage macht. Externe Dienste mit monatlichen Kosten und aufwändiger Integration. Fragen rund um die TLS-Terminierung. Und der Datenschutz, sobald der Traffic über einen Cloud-Anbieter im Drittland läuft. Jeder Punkt für sich kann Grund genug sein, das Thema gar nicht erst anzufassen.
Die ehrlichste Antwort: Die ideale Architektur scheitert oft schon am Hosting.
Phirewall: die WAF, die in der Anwendung lebt
Phirewall dreht die Perspektive um: Statt eine Schutzschicht vor die Anwendung zu zwingen, wird sie Teil davon. Technisch ist Phirewall eine einzige PSR-15-Middleware, die sich früh in den Request-Lifecycle einklinkt, dort, wo jede Anfrage ohnehin durchläuft. Einsetzen lässt es sich in jeder PHP-Anwendung, am einfachsten dort, wo der PSR-15-Standard verwendet wird. Frameworks ohne PSR-15, etwa Symfony, binden es über einen zusätzlichen Adapter ein.
Der Ablauf ist simpel: Jede Anfrage trifft zuerst die Middleware und wird dort gegen die Regeln geprüft. Erlaubte Anfragen laufen normal weiter, als gäbe es Phirewall nicht. Blockierte erhalten sofort eine Antwort, etwa 403 oder 429, und die teure Verarbeitung dahinter findet gar nicht erst statt. Unerwünschte Requests sind damit abgewiesen, bevor sie Ressourcen kosten.
Phirewall braucht keine Server-Rechte und läuft deshalb auch im Managed- und Shared-Hosting. Es arbeitet lokal, keine Daten verlassen den Server, und der ganze Datenschutz-Komplex externer Dienste entfällt. Konfiguriert wird in PHP, im selben Code, in dem das Team ohnehin arbeitet.
Weil Phirewall in der Anwendung läuft, sieht es, was ein vorgelagerter Proxy nie mitbekommt: wiederholte Login-Fehlschläge oder eine Flut an Anfragen auf ein Kontaktformular. Die Anwendung kann den fail2ban-Zähler für eine IP aus dem eigenen Code hochsetzen und entscheidet so selbst, ab wann ein Zugriff verdächtig ist, auch dort, wo auf Infrastruktur-Ebene nichts greifen würde.
Eine WAF schließt allerdings keine Sicherheitslücken. Eine Lücke im Code gehört im Code behoben, nicht hinter einer Firewall versteckt. Phirewall ist eine zusätzliche Schutzschicht, die potenziell gefährliche Anfragen früh erkennt und blockt. Die eigentliche Absicherung bleibt Aufgabe der Anwendung.
Phirewall: Schütze deine PHP-Anwendung mit einer einzigen Middleware.
Ein Blick in die Konfiguration
Am schnellsten zeigt das ein Beispiel. Ein Basis-Setup besteht aus drei Regeltypen: eine Safelist, die bestimmte Pfade immer durchlässt, eine Blocklist, die schädliche Anfragen sofort abweist, und ein Throttle, das die Frequenz pro Client begrenzt.
$config->safelists->add(
'health',
fn(ServerRequestInterface $request) => $request->getUri()->getPath() === '/health'
);
$config->blocklists->add(
'wordpress-attack',
fn(ServerRequestInterface $request) => $request->getUri()->getPath() === '/wp-admin/admin.php'
);
$config->throttles->add('throttle-api', 5, 60, function (ServerRequestInterface $request) {
if (str_starts_with(KeyExtractors::path()($request), '/api/users')) {
return KeyExtractors::ip()($request);
}
return null;
});
$config->enableResponseHeaders();Mehr braucht ein erstes Setup nicht. Auffällig ist, was fehlt: kein YAML, keine eigene Regel-Sprache, kein externer Config-Server. Jede Regel ist eine normale PHP-Closure, versioniert im selben Repository wie der Rest der Anwendung und testbar mit den gewohnten Werkzeugen.
Passend dazu starten wir die Blog-Serie mit der frisch veröffentlichten Version 0.5. Sie bringt unter anderem Presets und eine signierbare Portable Config, also Regel-Bundles, die sich über Projekte hinweg teilen und kombinieren lassen, dazu eine erweiterte RequestContext-API, über die sich Allow2Ban-Treffer jetzt direkt aus dem eigenen Anwendungscode melden lassen. Dieser erste Teil bleibt aber beim Wesentlichen: dem Problem, dem Ansatz und einem ersten Blick in die Konfiguration.
Was Phirewall sonst kann
Das Basis-Setup zeigt nur den Anfang. Phirewall kann noch einiges mehr, das wir uns in den nächsten Teilen genauer ansehen:
- Rate Limiting mit Fixed-, Sliding- und Multi-Window sowie dynamischen Limits pro Request.
- Bot Detection für bekannte Scanner, inklusive Verifikation echter Suchmaschinen-Bots per rDNS.
- IP-Blocking und Safelisting mit CIDR-Ranges und automatischer Expiration.
- OWASP-Regeln gegen SQL Injection, XSS und PHP Injection, bis hin zum OWASP ModSecurity Core Rule Set (CRS).
- Fail2Ban und Allow2Ban für schwellenwert-basiertes Sperren auffälliger Clients.
- Presets und Portable Config: serialisierbare, kombinierbare Regel-Bundles.
- Flexibler Storage über PSR-16-Caches (In-Memory, APCu, Redis, PDO), dazu PSR-14-Events für eigene Hooks.
Aus der Community, für die Community
Phirewall ist kein kommerzielles Nebenprodukt, sondern in der TYPO3-Community entstanden. Das Projekt wurde im vierten Quartal 2025 aus dem TYPO3 Community Budget gefördert und kommt damit aus der Community zurück in die Community.
Entstanden sind zwei Bausteine. Zum einen Phirewall (GitHub) selbst, das framework-agnostische Paket flowd/phirewall, das in jeder PSR-15-Anwendung läuft. Zum anderen die Extension “Firewall für TYPO3” (EXT:firewall über TER, Packagist und GitHub), die Phirewall tief in TYPO3 integriert: PHP-Konfigurationsdateien, Backend-Werkzeuge zur Verwaltung und Diagnose-Funktionen.
Hinter dem Projekt steht unser Sascha Egerer, der auch saschaegerer/phpstan-typo3 pflegt, in der TYPO3-Welt längst ein De-facto-Standard mit über 3,8 Millionen Downloads auf Packagist. An diese Reichweite soll Phirewall anknüpfen. Lizenziert ist es dual, unter LGPL-3.0-or-later und einer proprietären Lizenz, wenn das Projekt in kommerziell vertriebenen Produkten eingesetzt wird.
Was in dieser Serie noch kommt
Dieser Teil war die Einführung. In den nächsten Teilen gehen wir in die Tiefe, mit echten Konfigurationen aus der Praxis:
- Rate Limiting im Detail: Fixed-, Sliding- und Multi-Window-Throttling und dynamische Limits.
- Brute-Force stoppen: Fail2Ban, Allow2Ban und der Zähler aus dem eigenen Code.
- OWASP-Regeln und das ModSecurity Core Rule Set.
- Bots, Crawler und AI-Scraper bändigen.
- Presets und Portable Config, dazu Storage-Backends und Events.
- Firewall für TYPO3: die Extension im praktischen Einsatz.
Wer nicht warten möchte: Phirewall lässt sich schon heute ausprobieren. Ein Blick auf phirewall.de lohnt sich, und über EXT:firewall ist der Einstieg in bestehende Projekte schnell gemacht. Über Feedback freuen wir uns, und ein Stern auf GitHub hilft mehr, als man denkt. Wie ein Abend mit Phirewall in der Praxis aussieht, haben wir schon einmal beim Meetup der Frankfurt TYPO3 User Group festgehalten.