Securing TYPO3: 10 measures to prevent security vulnerabilities

This is the most important single measure. Supported versions (v13, v14 and v12 with ELTS) receive security patches; unsupported versions do not. Running an unsupported version means that any new, publicly disclosed vulnerability remains unpatched indefinitely. If you are on v12, please note that community support ends on 31 October 2026 — plan your migration to v14 well in advance. 

The vast majority of vulnerabilities in the TYPO3 ecosystem relate to extensions, not the core. Update all extensions regularly and keep an eye on security advisories from the TYPO3 Security Team. A publicly disclosed vulnerability with a patch available is a race against time — attackers’ scanners spring into action within days.

Every extension is a potential attack vector. The fewer you have, the lower the risk. Before installing, ask yourself: is this extension really necessary, is it actively maintained, and when was it last updated? Abandoned, unmaintained extensions are one of the biggest hidden risks. Remove any that you don’t use.

The principle of least privilege: every user should only have the rights they actually need. Many vulnerabilities (such as the Form Framework vulnerabilities in June) can only be exploited by a logged-in user with file write permissions — so restricting these permissions effectively reduces the risk. Regularly review the list of accounts, delete unused ones, and enforce strong passwords. 

Passwords are the weakest link — they can be stolen, cracked or phished. It is worth implementing multi-factor authentication, and increasingly also passwordless login (Passkeys, WebAuthn/FIDO2 — via TouchID, FaceID or a hardware key). For NIS2 entities, strong authentication is, in fact, expected. 

An application firewall (WAF) filters out malicious requests before they reach the TYPO3 logic — IP blocking, request limiting, fail2ban, and protection against scanners. The TYPO3 Firewall extension provides these capabilities at the application level, complementing hosting or CDN security measures (e.g. Cloudflare). We have described them in a separate article. 

If you collect personal data via forms, consider encrypting it in the database (encryption at rest at application level). That way, even in the event of a database breach, the data remains unreadable. This directly supports compliance with the GDPR (Article 32 – technical measures). Encrypting the hosting server’s hard drive is not sufficient, as the active database is unencrypted. 

Backups are your safety net — in the event of a breach, a system failure or a failed update. It’s important that they’re regular, automatic, tested (a backup that can’t be restored is worthless) and stored off the production server. You should also keep backups from several points in time — so you can revert to the state prior to the incident. 

You cannot respond to what you cannot see. It is worth monitoring server and TYPO3 logs, unusual requests, login attempts and file integrity. Automatic alerts for suspicious events reduce response times. For NIS2 entities, monitoring and the ability to detect incidents are mandatory. 

Security is not a one-off project, but an ongoing process. It is worth documenting: what measures have been implemented, when patches were applied, and who has access. This documentation is invaluable during an audit — NIS2 explicitly requires vulnerability management and an audit trail, whilst the forthcoming Cyber Resilience Act extends these requirements to the entire software lifecycle. A standing maintenance contract ensures the continuity of this process.