TYPO3 Firewall a new layer of security for your system
The flowd/typo3-firewall extension integrates the Phirewall package and adds a true application-level WAF to the TYPO3 CMS — IP blocking, rate limiting, fail2ban and pattern management via the backend
In a nutshell
What is it:
TYPO3 Firewall (flowd/typo3-firewall) is a new extension by Sascha Egerer that integrates the open-source Phirewall package with TYPO3. It provides Web Application Firewall functionality at the PHP application level — without a dedicated server, without Cloudflare, and without a hosting provider’s WAF.
Key features:
Blocking by IP, CIDR, URL path, headers and regex. Fail2ban (temporary blocking following abuse). Rate limiting via headers. Pattern management via the TYPO3 backend without deployment. Custom responses for blocked requests.
Who it’s for:
Websites subject to NIS2 (hospitals, local authorities, government offices), online shops subject to PAD/EAA, NGO websites processing sensitive data, any TYPO3 website without access to a server-level WAF.
Requirements:
TYPO3 13+, PHP 8.2+. For rate limiting and fail2ban: persistent cache (APCu or Redis — Redis recommended in production).
Version:
0.3 (last updated: 19 May 2026). Status: actively under development, source code available on GitHub.
Website security in TYPO3 has traditionally been handled at the server or CDN level — Cloudflare, ModSecurity, the system-level fail2ban, and nginx rules. These are effective solutions, but they require access to infrastructure that we often do not have: on shared hosting, managed hosting, or in environments where IT operations are handled by a team other than the editorial team.
The new flowd/typo3-firewall extension changes this approach. It provides TYPO3 administrators with Web Application Firewall tools at the PHP application level — operating within the same environment as the CMS itself. No need to liaise with the server administrator, no additional services, and no monthly fees. This is a significant change, particularly in the context of the amendments to the KSC Act (NIS2) and the Polish Accessibility Act, which come into force in 2025–2026 and require the implementation of specific security measures.
What TYPO3 Firewall can do
The extension has two main layers: integration with the Phirewall package (the execution engine) and the Backend module (rule management). Together, they provide the following functions.
Blocklists static blocklists
You can block requests based on several criteria: IP address (single or CIDR range), URL path (e.g. /wp-admin — a common target for scanners looking for WordPress), query string parameters (e.g. xdebug, option=com_), HTTP headers, and any regular expressions. The rules take effect immediately upon being added, without the need to restart the server.
Fail2ban temporary block following misuse
It works in the same way as the classic system-level fail2ban, but at the application level. You define a threshold, a time window and the duration of the ban. Example: if an IP address makes more than 5 requests to /search within 10 seconds, it is blocked for 60 seconds. This prevents bots from scanning the search engine and stops brute-force attacks on login forms.
Rate limiting (throttles) (throttles)
A global limit on the number of requests from a single key (IP, user, session) within a given time window. Example: 10 requests every 10 seconds per IP. Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After) — in which case the client can see when it can retry the request. This is important for API integration.
Allow2ban following in the footsteps of success
A lesser-known but useful feature — banning keys that trigger specific ‘traps’. Example: any bot that attempts to access /robots-trap-url (a link hidden from users, visible only in the HTML source) is immediately banned. An application-level honeypot.
Custom responses own replies for blocked users
By default, a blocked request receives a 403 status code with a minimal body. You can define your own response — a different status code, JSON, HTML or a redirect. This is useful in API scenarios (consistent error formats) or when you want to log blocked attempts with additional context.
Back-end module management via the TYPO3 control panel
The most practical feature for editors and administrators without SSH access. The backend module allows you to: create, edit and delete blocking patterns; select the type (IP, path, header, regex); setting an expiry date (expiresAt — important for temporary blocks), viewing active fail2ban bans and the option to lift them manually. Changes take effect immediately, without the need for deployment.
How does it work from a technical point of view?
Architecture Firewall as a foundation
TYPO3 Firewall is an integration layer built on top of the open-source Phirewall package (flowd/phirewall — by the same author). Phirewall is a standalone PHP package that can be used in any PSR-7-based application (Symfony, Laravel, Slim, custom frameworks). TYPO3 Firewall adds the following: integration with the TYPO3 middleware system, a Backend module, a JSON template repository, documentation and examples for the TYPO3 environment.
Configuration files
The configuration is a two-step process:
• config/system/phirewall.php — main Phirewall configuration (rules in PHP, cache backend, fail2ban, throttles, custom responses)
• config/system/phirewall.patterns.json — patterns managed by the Backend module (static IP/path/header blocks with expiry dates)
Cache backend Choices matter
Phirewall stores state (rate limit counters, fail2ban ban lists) in the cache. The choice of cache backend determines which features are available:
✗ InMemoryCache — for testing and CLI use only. Only blocklists work. Rate limiting and fail2ban are pointless, as the cache is not persistent between HTTP requests.
✓ ApcuCache — production-ready for a single server. Fast, in-memory, but not shared across servers. Requires the APCu extension to be enabled in PHP.
✓ RedisCache — recommended for production and multi-server environments. Shared state across servers, persistence, and the ability to manually check the state via the Redis CLI.
In our practice, for larger clients (Universitätsmedizin Mannheim, large portals), we use Redis. For smaller TYPO3 installations on a single server, APCu is sufficient and requires no additional infrastructure.
Practical examples of configurations
Below are three realistic scenarios that you can implement straight away. They are all taken from the official documentation and are suitable for use in the Polish context.
1. Blocking WordPress scanners and known malicious IP addresses
Scanners search for WordPress installations on every domain (requests to /wp-admin, /wp-login.php). TYPO3 does not have these paths, so the block has no side effects — and it removes several dozen per cent of bot traffic from the logs.
<?php
$config->blocklists->add(
name: 'evil-bot-ips',
callback: fn(\$request) => in_array(
\$request->getServerParams()['REMOTE_ADDR'] ?? '',
['176.65.149.61', '45.13.214.201'],
true
)
);
$config->blocklists->add(
name: 'wordpress-scanner-paths',
callback: fn(\$request) => str_starts_with(
strtolower(\$request->getUri()->getPath()),
'/wp-admin'
)
); 2. Fail2ban for the search engine protection against scraping
A classic attack: a bot attempts to retrieve all products/pages via the search function. A single IP address sends hundreds of requests to /search. Configuration: 5 requests in 10 seconds → 60-second ban.
<?php
$config->fail2ban->add(
name: 'search-page-scrapers',
threshold: 5,
period: 10,
ban: 60,
filter: fn(\$request) => str_starts_with(
\$request->getUri()->getPath(),
'/search'
),
key: KeyExtractors::ip()
); 3. Global rate limiting using headers protection against scraping
A limit of 10 requests per 10 seconds per IP address, with clear response headers. This is basic security practice for any public website — it protects against bots exploiting delayed vulnerabilities, aggressive scraping and ‘mistakes’ made by a developer who has made an error in their script.
<?php
$config->throttles->add(
name: 'global-rate-limit',
limit: 10,
period: 10,
key: KeyExtractors::ip()
);
$config->enableRateLimitHeaders(); Why is this important in the context of NIS2 and PAD?
The amendment to the Act on the National Cyber Security Centre (KSC) implementing NIS2 comes into force on 3 April 2026 and applies to 27,000 Polish public sector organisations — including every hospital, local authority and many cultural institutions. NIS2 requires, amongst other things:
• The implementation of specific technical measures to protect against cyber-attacks — an application firewall falls within this definition
• Incident response procedures — fail2ban and rate limiting provide automated first-line defences
• An audit trail — logging who, when and what was changed in the security configuration. The TYPO3 Firewall Backend module offers a natural advantage here over configurations hidden in files on the server
• Change management — rule changes are approved and logged in the Backend, rather than being introduced ad hoc by an SSH administrator
The Polish Accessibility Act (PAD, Act of 26 April 2024) and Article 32 of the GDPR require “technical measures to ensure the security of processing”. An application-level firewall is a specific, verifiable technical measure. A GDPR or NIS2 auditor can view the configuration, logs and list of blocked addresses — this serves as evidence that the measures required by law have been implemented.
When should you implement the TYPO3 Firewall? and when not
It is worth implementing if:
✓ Your TYPO3 website is subject to NIS2 (hospital, local authority, government office, university) or PAD (e-commerce shop exceeding the threshold)
✓ Your hosting provider does not offer a server-level WAF (shared hosting, some VPS plans)
✓ You do not use Cloudflare or another CDN with a WAF
✓ You have a high volume of bot traffic in your logs — WordPress scanners, brute-force attacks on forms, scrapers
✓ You want to give editors the ability to manage simple blocks without the need for server administrator support ✓ You need an audit trail for an NIS2 audit — the Backend module provides a change history
It is not necessary if:
✗ You already have Cloudflare or another CDN with a WAF properly configured (in which case the application firewall operates at a different layer and may duplicate functions)
✗ Your hosting provider has ModSecurity, system-level fail2ban and rate limiting at the nginx/Apache level correctly configured ✗ Your website has minimal traffic and is not subject to any legal requirements — the cost of maintenance may outweigh the benefits
✗ No persistent cache (Redis/APCu) on the server — rate limiting and fail2ban will not work; only static blocklists will be used
The most common practice in our deployments: the TYPO3 Firewall complements a CDN-level WAF; it does not replace it. Cloudflare intercepts cheap, mass bot traffic before it reaches the server. TYPO3 Firewall catches what gets through Cloudflare — advanced attacks, attacks on specific application endpoints, and brute-force attacks on forms, which Cloudflare cannot distinguish from legitimate traffic.
Frequently Asked Questions
No, but it complements it. Cloudflare operates at the network level and intercepts traffic before it reaches the server — this is very effective against DDoS attacks and simple bots. TYPO3 Firewall operates within the application and has access to the context (user session, query parameters, business logic). In an ideal scenario, you have both — Cloudflare as the first line of defence, and the TYPO3 Firewall as the second.
To some extent. Basic restrictions (IP, path) can be managed via the TYPO3 backend without touching the code — this is sufficient for 70% of scenarios. More advanced rules (custom callbacks, fail2ban, throttles) require editing the phirewall.php file — it’s PHP, but simple and well-documented. We configure the rules for our clients once, after which the editor manages the patterns from the Backend.
Phirewall is designed as lightweight middleware. Static blocklists (IP checks) take microseconds. Rate limiting via Redis adds 1–3 ms per request. Fail2ban only runs when a rule is active — it does not impact normal traffic. In our tests, the difference in response time was imperceptible to the end user.
Yes, immediately after saving. The patterns are read from the phirewall.patterns.json file with every request (with caching). There is no deployment, no PHP-FPM restart and no other administrative action required. This is a key advantage when dealing with incidents — you spot an attack in the logs, add the IP to the block list, and the attack stops within 30 seconds.
Phirewall supports ‘dry run’ mode (recommended before implementing rate limits and fail2ban). The rule is evaluated, a block event is triggered (you can capture this with an event listener and log it), but the actual request is not blocked. Standard practice: one week of dry run, analysis of false positives, then production deployment.
The extension requires PHP 8.2 or later. This is the standard for TYPO3 13, but many installations in the public sector are still running on PHP 7.4 or 8.0 (with TYPO3 v10 or v11). This is a further argument in favour of upgrading — modern security tools require modern infrastructure. NIS2 requires an up-to-date version of PHP anyway (vulnerability management).
Yes — and that is one of the strengths of this solution. All rules are stored in version-controlled files (phirewall.php). The patterns from the Backend are stored in phirewall.patterns.json (also in Git). Fail2ban bans are logged and visible in the Backend module. An NIS2 or GDPR auditor is provided with a specific set of documents: rules, logs and a change history. This differs from ModSecurity’s hidden configuration on the server, which an auditor cannot view without the administrator’s assistance.
Project status and ecosystem
TYPO3 Firewall is actively developed by Sascha Egerer (flowd GmbH) — a well-known German TYPO3 developer, author of numerous extensions and a Core contributor. Version 0.3 (last updated: 19 May 2026) is stable, but the version number indicates that the project is still evolving. The source code is on GitHub, the documentation is at docs.typo3.org, and the support channel is on TYPO3 Slack.
Phirewall — the runtime engine — is an independent, mature PHP project. Full documentation: phirewall.de. This boosts confidence in the solution — even if TYPO3 Firewall were to cease development, the foundation remains active.
How can we help?
We specialise in TYPO3, with a focus on security and compliance. In relation to TYPO3 Firewall, we offer:
✓ Analysis of your current digital footprint and requirements under NIS2/PAD/GDPR — does TYPO3 Firewall make sense for your implementation? ✓ Implementation of the extension with configuration tailored to your infrastructure (Redis, APCu, dry run, rule calibration)
✓ Configuration of rules for typical scenarios — blocklists, fail2ban, throttling — along with documentation for the auditor
✓ Training for the editorial team on using the Backend module (managing templates, checking active bans)
✓ Integration with our other security recommendations: Powermail form encryption, accessibility statement, hosting within the EEA
If you run a hospital, local authority or shop subject to the new regulations — we’d be happy to discuss this with you.
Telephone: 12 333 44 01. Email: [email protected].
