Securing a TYPO3 installation is a shared responsibility across everyone involved: system administrators, integrators, developers and editors. This guide draws on the official TYPO3 Security Guide and pulls together all the security measures that matter.
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 latest patchesExtensions up to date – All extensions up to date, unused ones removedHigh – Authentication & Access
loginRateLimit configured (v13+: native, v12: fail2ban)Minimal permissions – Users only have 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 coordinates and communicates 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 publicly: No GitHub issues, no Forge tickets
- Responsible Disclosure: Coordinated publication after patch
- Acknowledgement: Credits in Security Bulletins
Security vulnerabilities must never be discussed publicly before a patch is available. Doing so hands attackers an advantage and puts every TYPO3 installation worldwide at risk.
Versions & Updates
Choosing the right TYPO3 version and sticking to a consistent update strategy are fundamental security decisions.
Support Cycles
| Version | Type | Regular Support | ELTS Available | PHP Version |
|---|---|---|---|---|
| TYPO3 14 | Upcoming LTS (April 2026) | Until ~April 2029 | Yes (afterwards) | PHP 8.2+ |
| TYPO3 13 | LTS | Until December 2027 | Yes (afterwards) | PHP 8.2+ |
| TYPO3 12 | LTS | Until April 2026 | Yes (afterwards) | PHP 8.1+ |
| TYPO3 11 | LTS | Ended | Yes (paid) | PHP 7.4–8.3 |
| Sprint Releases | Development | No support | No | varies |
TYPO3 v14.0 was released on 25th November 2025. The LTS version (v14.4) is planned for April 2026. Until then, features and settings may still change. PHP 8.2+ is required.
Once regular support ends, you can still get critical security updates through the paid ELTS programme . This matters for legacy systems that can't be migrated straight away.
Update Categories
Maintenance Releases
- Bug fixes and minor improvements
- Plannable within 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)
Because TYPO3 is open source, attackers can study the code changes and build exploits the moment a patch ships. Apply Security Releases within 24 hours.
Threat Types
To protect TYPO3 systems effectively, you first need to understand the most common attack vectors.
General Guidelines
These core principles apply to every role and underpin any security strategy.
Password Hygiene
Requirements
- At least 12 characters (better: 16+)
- Upper/lower case letters, numbers, special characters
- No personal data or dictionary words
- Use a password manager
Organisational
- A unique password for every 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
- Enable anti-virus software and firewall
- No installation of software from unknown sources
- VPN for access from public networks
System Admin
System administrators own the server infrastructure, and with it the foundation on which every other security measure rests.
HTTPS Encryption
Without HTTPS, login credentials, session cookies and sensitive content can all be intercepted. No production system should ever run 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 add a crucial layer of defence against a range of attacks. The web server sends them to tell the browser how to behave securely.
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
A misconfigured CSP can break the website entirely. Start with Content-Security-Policy-Report-Only, check the browser console for violations and only then switch the header on.
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 never be installed on production systems. They greatly enlarge 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 | Full (+ composer.lock) | Full (incl. typo3/ Core) | 6 months |
| Yearly | Full archive | Full 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 the 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 your last successful restore test. Rehearse the recovery process regularly in a separate environment and check for any missing data.
Integration & Configuration
Integrators configure TYPO3 and are responsible for getting the system settings right.
Securing the Install Tool
The Install Tool can make far-reaching changes to the system, so it needs particular 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 inside the enable file prevents automatic deletion and is strictly off-limits in production environments.
Application Context (TYPO3_CONTEXT)
The Application Context lets you run different configurations per environment. This is critical for security, since debugging options should only ever be active in development.
Recommended Contexts
| Context | Purpose | Debugging | Caching |
|---|---|---|---|
Production | Live system | Disabled | Active |
Production/Staging | Staging server | Disabled | Active |
Development | Development | Enabled | Reduced |
Development/Local | Local development | Enabled | Minimal |
Testing | Automated tests | Enabled | Disabled |
Configuration
Context-specific Configuration
TYPO3 automatically loads additional configuration files based on the Context:
If TYPO3_CONTEXT is unset, TYPO3 defaults to the Production context. Set the variable explicitly anyway to rule out configuration mistakes.
Official documentation: Application Context
Local Development with DDEV
DDEV is the recommended development environment for TYPO3 projects. This container-based solution offers clear 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 as Production
- No local installation – No PHP/MySQL required on the host
Developer Productivity
- Quick setup –
ddev config && ddev start - Switch PHP version – Easily in
.ddev/config.yaml - Integrated services – Redis, Solr, MailHog, Elasticsearch
- Composer & Node – Fully integrated
Commit .ddev/config.yaml to the repository. That way every team member automatically gets an identical development environment, with no "works on my machine" surprises.
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 allowed domains (not.*!)displayErrors = 0– No error outputdevIPmask = ''– No debug IPs
Users & Permissions
Principle of Least Privilege (PoLP)
Every user receives only the minimally necessary permissions:
- Editors: Access only to relevant page trees and file areas
- Administrators: No System Maintainer status unless required
- System Maintainers: Restrict to an absolute minimum (1-2 people)
Multi-Factor Authentication (MFA)
MFA must be mandatorily enabled for all accounts with administrative rights. TYPO3 supports TOTP and recovery codes natively.
Extension Management
- Only extensions from trusted sources (TER, Packagist)
- Regular updates of all extensions
- Remove unused extensions – every extension widens the attack surface
- Watch the Security Bulletins for extensions too, not just the Core
The TYPO3 Security Team works reactively:
- No automatic testing – Only a small percentage of TER extensions have been audited by the Security Team (Source)
- Only when reported – The team only becomes active 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 repos, GitHub, or non-TER Packagist packages will never receive Security Bulletins from the TYPO3 Security Team. (Source)
In practice: your development team carries full responsibility for security audits, vulnerability monitoring and patch management of these extensions.
The Process after a Report
When a vulnerability in a TER extension is reported, the Security Team follows the Extension Security Policy:
- Notification – the Security Team confidentially informs the extension developer
- Response required – the developer must show that the extension is actively maintained
- Provide a fix – a patch is developed and tested in a private repository
- Coordinated release – the Security Bulletin and the new extension version go out together
If the developer doesn't respond: the Security Team publishes a Removal Bulletin and the extension is removed from the TER. (Source)
Security Warnings after Login
TYPO3 shows security warnings after you log in to the backend. Take them seriously and resolve them promptly:
- Outdated Core version
- Insecure extensions
- Missing configuration
Development
Developers carry a special responsibility, because insecure code puts the entire installation at risk.
"Never trust user input" – treat all external data (GET, POST, cookies, headers) as potentially malicious and always validate it.
Input Validation
Validate all inputs on the server side:
- Type checking: Integer, String, Boolean
- Length limits: Maximum character count
- Whitelist: Only accept 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: Only accept explicitly allowed properties
- __trustedProperties: Prevents mass assignment via cryptographic validation
- Validation: Use Extbase validators for domain objects
Editors
Editors can inadvertently open up security holes through unsafe day-to-day practices.
Secure Content Entry
- Use the Rich Text Editor instead of direct HTML
- No unknown embeds (YouTube, Twitter, etc.) from untrusted sources
- Check links before inserting them – no redirects to unknown domains
- No scripts inside the RTE (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 size: Report suspiciously large files
- Verify origin: Do not upload files from unknown sources
Phishing Awareness
- Never share login credentials via e-mail
- Check URL before entering passwords
- Report suspicious e-mails to IT
- If unsure: Ask instead of clicking
Emergency
No matter how many precautions you take, a compromise can never be ruled out entirely. A clear emergency plan is essential.
Recognising the Signs
Obvious
- Website shows 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 sent from the server
- New files in upload directories
- Changed timestamps on Core files
Immediate Measures
Take the website offline
Secure the evidence
Change credentials
Conduct Analysis
Recovery
Manually "cleaning" a compromised system is extremely error-prone. Backdoors are easily missed and let attackers back in.
Recommended approach:
- Identify a clean backup (created before the attack)
- Fresh installation on a cleaned server
- Restore database from backup
- Update TYPO3 and extensions to the latest versions
- Close the security hole that allowed the attack
- Reset all passwords
- Only then go live
Preventative Measures after Recovery
- Document and fix the vulnerability
- Conduct a security audit
- Intensify monitoring
- Train the team
- Update incident response plan
Composer & Code Integrity
The Composer installation is the only recommended path for production TYPO3 systems. Classic mode should be reserved for testing.
Security Advantages
| Aspect | Composer | Classic |
|---|---|---|
| Package Verification | Checksums verified | Manual (if at all) |
| Update Security | Atomic updates | Dead code possible |
| Dependency Audit | composer audit | Not available |
| Reproducibility | composer.lock | Not guaranteed |
| Document Root | Separated | Everything public |
Secure Update Strategy
Summary
Use Composer
Our recommended installation path, with verified packages and secure updates
Update immediately
Apply Security Releases within 24 hours
Defense in Depth
Multiple security layers: server, application, users, processes
Resources
- TYPO3 Security Guide – Official documentation
- TYPO3 Security Team – Reporting vulnerabilities
- Security Advisories – Current warnings
- ELTS programme – Extended Long Term Support