The security of a TYPO3 installation is the result of a shared responsibility among all involved parties – system administrators, integrators, developers, and editors. This guide is based on the official TYPO3 Security Guide and summarises all relevant security measures.
Table of Contents
Security Team
Responsibilities, reporting vulnerabilities
Threats
SQLi, XSS, CSRF, RCE
Quick Checklist
Sorted by priority – critical measures first.
Critical – Implement Immediately
.* in productionError output disabled – displayErrors = 0, devIPmask = ''Current LTS version – TYPO3 12 or 13 LTS with the latest patchesExtensions up to date – All extensions updated, unused ones removedHigh – Authentication & Access
loginRateLimit configured (v13+: native, v12: fail2ban)Minimum privileges – Users have only necessary permissions (PoLP)Medium – Infrastructure
composer auditSensitive files blocked – .sql, .yaml, composer.* not accessibleSecurity headers set – HSTS, X-Frame-Options, CSP configuredMaintenance & Recovery
TYPO3 Security Team
The TYPO3 Security Team is responsible for coordinating and communicating security vulnerabilities across the entire TYPO3 ecosystem.
Responsibilities
- Receiving and verifying security reports
- Coordination with core and extension developers
- Publishing security bulletins and patches
- Maintaining the Security Advisories database
Reporting Vulnerabilities
- E-mail: security@typo3.org (encryption possible)
- Never public: No GitHub issues, no Forge tickets
- Responsible Disclosure: Coordinated publication after a patch
- Recognition: Credits in security bulletins
Security vulnerabilities must never be discussed publicly before a patch is available. This gives attackers an advantage and endangers all TYPO3 installations worldwide.
Versions & Updates
Choosing the right TYPO3 version and maintaining a consistent update strategy are fundamental security decisions.
Support Cycles
| Version | Type | Regular Support | ELTS available | PHP Version |
|---|---|---|---|---|
| TYPO3 14 | Sprint → LTS (April 2026) | Until ~April 2029 | Yes (afterwards) | PHP 8.2+ |
| TYPO3 13 | LTS | Until October 2027 | Yes (afterwards) | PHP 8.2+ |
| TYPO3 12 | LTS | Until April 2026 | Yes (afterwards) | PHP 8.1+ |
| TYPO3 11 | LTS | Ended | Yes (subject to a fee) | PHP 7.4–8.2 |
| Sprint Releases | Development | No support | No | varies |
TYPO3 v14.0 was released on 25 November 2025. The LTS version (v14.4) is scheduled for April 2026. Until then, features and settings may still change. PHP 8.2+ is required.
After regular support ends, critical security updates can be obtained via the paid ELTS programme . This is relevant for legacy systems that cannot be migrated promptly.
Update Categories
Maintenance Releases
- Bug fixes and minor improvements
- Can be planned in the regular sprint rhythm
- Example: 12.4.10 → 12.4.11
Security Releases
- Fix critical security vulnerabilities
- Immediate installation required (24h target)
- Published on Tuesdays (coordinated)
Since TYPO3 is open-source, attackers can analyse the code changes and develop exploits once a patch is released. Act within 24 hours for security releases.
Threat Types
To effectively protect TYPO3 systems, the most common attack vectors must be understood.
General Guidelines
These fundamental principles apply to all roles and form the foundation of any security strategy.
Password Hygiene
Requirements
- At least 12 characters (better: 16+)
- Uppercase/lowercase letters, numbers, special characters
- No personal data or dictionary words
- Use a password manager
Organisational
- A unique password for each service
- No "Stay logged in" on shared devices
- Never share passwords via e-mail or chat
- Regular rotation according to security policy
Staying Informed
- Security Bulletins: typo3.org/security
- Newsletter: Subscribe to TYPO3 Security Announcements
- RSS Feed: Automatic notification of new advisories
Client Security
All devices accessing the TYPO3 backend must be secured:
- Keep operating system and browser up to date
- Activate antivirus software and firewall
- No installation of software from unknown sources
- VPN for access from public networks
System Administration
System administrators are responsible for the server infrastructure and thus the basis of all security measures.
HTTPS Encryption
Without HTTPS, login credentials, session cookies, and sensitive content can be intercepted. No production system may be operated without TLS.
- TLS 1.2 as a minimum, TLS 1.3 preferred
- Let's Encrypt for free certificates
- Set HSTS header (forces HTTPS)
[BE][lockSSL] = truein TYPO3 configuration
File Permissions
Correct permissions prevent unauthorised access:
| File type | Permission | Reason |
|---|---|---|
| Directories | 755 | Read/execute for all, write only for owner |
| PHP files | 644 | No direct execution, only via web server |
| Configuration files | 640 | No access for "others" |
| Upload directories | 775 | Web server must be able to write |
HTTP Access Restriction
Block access to sensitive files and directories:
Disable Directory Indexing
Disable automatic directory listing to avoid information leaks:
Security Headers
HTTP security headers are an important layer of defence against various attacks. The web server sends them and instructs the browser on secure behaviour.
Recommended Headers
| Header | Value | Protection against |
|---|---|---|
Strict-Transport-Security | max-age=31536000; includeSubDomains | Downgrade attacks, SSL stripping |
X-Frame-Options | SAMEORIGIN | Clickjacking |
X-Content-Type-Options | nosniff | MIME type sniffing |
Referrer-Policy | strict-origin-when-cross-origin | Information leaks |
Permissions-Policy | geolocation=(), microphone=() | Unwanted API usage |
Content-Security-Policy | Project-specific | XSS, Code injection |
Configuration
CSP can render the website non-functional if configured incorrectly. Start with Content-Security-Policy-Report-Only and check the browser console for violations before enforcing the header.
Verification
Test your security headers with these tools:
- securityheaders.com – Quick analysis
- Mozilla Observatory – Comprehensive security check
- Browser DevTools → Network → Response Headers
Database Security
phpMyAdmin, Adminer, and similar tools must not be installed on production systems. They significantly increase the attack surface.
Backup Strategy
The official TYPO3 documentation recommends a tiered backup strategy:
| Frequency | Composer Installation (v12+) | Classic (Legacy) | Retention |
|---|---|---|---|
| Daily | Database + fileadmin/ | Database + fileadmin/ | 7 days |
| Weekly | DB + fileadmin/ + config/ + var/log/ | DB + fileadmin/ + typo3conf/ + uploads/ | 4 weeks |
| Monthly | Complete (+ composer.lock) | Complete (incl. typo3/ Core) | 6 months |
| Annually | Complete archive | Complete archive | Several years |
Composer Installation (recommended):
config/– System configuration (settings.php,sites/)fileadmin/– User uploads (FAL)var/log/– Logs for forensics (cache can be regenerated)composer.json+composer.lock– Code is reproducible!
Classic Installation (Legacy):
typo3conf/– Configuration + Extensionsfileadmin/+uploads/– User filestypo3/– Core files
- Never store in Document Root – Backups must not be publicly accessible
- Encryption – Backups contain sensitive data (password hashes, customer data)
- Offsite Copy – Store at least one copy externally (ransomware protection)
A backup is only as good as its last successful restore test. Regularly test the restoration in a separate environment and check for missing data.
Integration & Configuration
Integrators configure TYPO3 and are responsible for secure system settings.
Install Tool Security
The Install Tool allows deep system changes and requires special protection:
- ENABLE_INSTALL_TOOL file in
var/transient/(Composer) ortypo3temp/var/transient/(classic) - Separate password (not the admin password!)
- Auto-deletion after 60 minutes of inactivity
The content KEEP_FILE in the enable file prevents automatic deletion and is strictly forbidden in production environments.
Application Context (TYPO3_CONTEXT)
The Application Context allows different configurations for different environments. This is critical for security, as debugging options should only be active in development environments.
Recommended Contexts
| Context | Purpose | Debugging | Caching |
|---|---|---|---|
Production | Live system | Disabled | Active |
Production/Staging | Staging server | Disabled | Active |
Development | Development | Activated | Reduced |
Development/Local | Local development | Activated | Minimal |
Testing | Automated tests | Activated | Disabled |
Configuration
Context-Specific Configuration
TYPO3 automatically loads additional configuration files based on the context:
Without a set TYPO3_CONTEXT, TYPO3 uses the Production context by default. However, set the variable explicitly to avoid configuration errors.
Official documentation: Application Context
Local Development with DDEV
DDEV is the recommended development environment for TYPO3 projects. The container-based solution offers significant security advantages over classic LAMP setups.
Security Advantages
- Isolated environment – Projects run in separate containers
- Automatic HTTPS – Local SSL certificates out-of-the-box
- Consistent environment – Identical PHP version to Production
- No local installation – No PHP/MySQL needed on the host
Developer Productivity
- Fast setup –
ddev config && ddev start - Switch PHP version – Simply in
.ddev/config.yaml - Integrated services – Redis, Solr, MailHog, Elasticsearch
- Fully integrated – Composer & Node
Commit .ddev/config.yaml to the repository. This ensures every team member automatically has the identical development environment – no "Works on my machine" problems.
Global Configuration
All security-relevant settings in config/system/settings.php or config/system/additional.php:
These three settings must be configured correctly in every production environment:
trustedHostsPattern– Regex for permitted domains (not.*!)displayErrors = 0– No error outputdevIPmask = ''– No debug IPs
Users & Permissions
Principle of Least Privilege (PoLP)
Every user receives only the minimum necessary privileges:
- Editors: Access only to relevant page trees and file areas
- Administrators: No System Maintainer status unless required
- System Maintainers: Restrict to the absolute minimum (1-2 people)
Multi-Factor Authentication (MFA)
MFA must be mandatorily activated for all accounts with administrative privileges. TYPO3 natively supports TOTP and recovery codes.
Extension Management
- Only extensions from trusted sources (TER, Packagist)
- Regular updates of all extensions
- Remove unused extensions – every extension expands the attack surface
- Monitor security bulletins for extensions too
The TYPO3 Security Team works reactively:
- No automatic checks – Only a small percentage of TER extensions have been audited by the Security Team (Source)
- Only when reported – The team only takes action when someone reports a vulnerability to security@typo3.org
- TER extensions only – Security bulletins are published exclusively for extensions in the TER (Source)
Extensions from private repositories, GitHub, or non-TER Packagist packages will never receive Security Bulletins from the TYPO3 Security Team. (Source)
This means: Your development team bears full responsibility for security audits, vulnerability monitoring, and patch management of these extensions.
The process after a report
When a security vulnerability in a TER extension is reported, the Security Team follows the Extension Security Policy:
- Notification – Security Team confidentially informs the extension developer
- Reaction required – Developer must demonstrate that the extension is actively maintained
- Provide fix – Patch is developed and tested in a private repository
- Coordinated release – Security bulletin + new extension version simultaneously
If there is no reaction: The Security Team publishes a Removal Bulletin and the extension is removed from the TER. (Source)
Security Warnings after Login
TYPO3 displays security warnings after backend login. Take these seriously and resolve them promptly:
- Outdated core version
- Insecure extensions
- Missing configuration
Extension Development
Developers bear a special responsibility, as insecure code endangers the entire installation.
"Never trust user input" – All external data (GET, POST, cookies, headers) is potentially malicious and must be validated.
Input Validation
Validate all input server-side:
- Type check: Integer, String, Boolean
- Length limits: Maximum number of characters
- Whitelist: Accept only permitted values
- Encoding: Force UTF-8
Preventing SQL Injection
Preventing XSS
Fluid escapes output by default. Note the exceptions:
| Context | Protection |
|---|---|
| Fluid variables in HTML | Automatically escaped |
<f:format.raw> | No escaping – never for user data! |
| ViewHelper arguments | Not escaped – escape manually! |
| JavaScript context | JSON.stringify() or htmlspecialchars() |
Extbase Security
- Property Mapping: Accept only explicitly permitted properties
- __trustedProperties: Prevents mass assignment through cryptographic validation
- Validation: Use Extbase Validators for domain objects
Editor Security
Editors can also expose security vulnerabilities through unsafe behaviour.
Secure Content Entry
- Use the Rich Text Editor instead of raw HTML
- No unknown embeds (YouTube, Twitter, etc.) from insecure sources
- Check links before inserting – no redirects to unknown domains
- No scripts in the RTE (they are often blocked, but not always)
Upload Guidelines
Permitted
- Images: jpg, png, gif, svg, webp
- Documents: pdf, docx, xlsx, pptx
- Archives: zip (after checking)
Forbidden
- Executables: php, exe, sh, bat
- Web files: html, htm, js
- Server files: htaccess, conf
- Check file names: No special characters that enable injection
- Observe file sizes: Report suspiciously large files
- Verify origin: Do not upload files from unknown sources
Phishing Awareness
- Never share login credentials via e-mail
- Check the URL before entering passwords
- Report suspicious e-mails to IT
- If unsure: Ask instead of clicking
After an Attack
Despite all precautions, a compromise can never be entirely ruled out. A clear emergency plan is essential.
Recognising Signs
Obvious
- Website displays foreign content (defacement)
- Redirects to unknown domains
- Search engine warnings ("This site may be hacked")
- Unknown backend users
Subtle
- Unusually high traffic/server load
- Spam e-mails from the server
- New files in upload directories
- Changed timestamps on core files
Immediate Actions
Take the website offline
Securing evidence
Change credentials
Conducting Analysis
Recovery
Manually 'cleaning' a compromised system is extremely prone to error. Backdoors are often overlooked and allow renewed access.
Recommended procedure:
- Identify a clean backup (created before the attack)
- Fresh installation on a cleaned server
- Restore the database from backup
- Update TYPO3 and extensions to the latest versions
- Close the security vulnerability that allowed the attack
- Renew all passwords
- Only then go online
Preventive Measures after Recovery
- Document and resolve the vulnerability
- Conduct a security audit
- Intensify monitoring
- Train the team
- Update the incident response plan
Composer & Code Integrity
The Composer installation is the only recommended method for productive TYPO3 systems. Classic mode should only be used for testing purposes.
Security Advantages
| Aspect | Composer | Classic |
|---|---|---|
| Package verification | Checksums checked | Manual (if at all) |
| Update security | Atomic updates | Code remnants possible |
| Dependency Audit | composer audit | Not available |
| Reproducibility | composer.lock | Not guaranteed |
| Document Root | Separated | Everything public |
Secure Update Strategy
Summary
Use Composer
Personal recommendation: The installation path for verified packages and secure updates
Update immediately
Apply security releases within 24 hours
Defence in Depth
Multiple security layers: server, application, users, processes
Resources
- TYPO3 Security Guide – Official documentation
- TYPO3 Security Team – Report vulnerabilities
- Security Advisories – Current warnings
- ELTS programme – Extended Long Term Support