TYPO3 Security Hardening: Production Best Practices

A practical guide to hardening TYPO3 in production: server config, application context, extension management and incident response, with ready-to-use examples.

Auf einen Blick

  • Critical measures: HTTPS (TLS 1.2+), a correct trustedHostsPattern, error output disabled and the LTS kept up to date.
  • MFA on every admin account, a secured Install Tool, rate limiting (native in v13+) and least-privilege permissions following the PoLP principle.
  • Security is a shared responsibility among system admins, integrators, developers, and editors.
  • The guide covers SQLi, XSS, CSRF, RCE and Incident Response.

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.

Last updated: 3rd December 2025 – incl. TYPO3 v14.0 (upcoming LTS release)

Table of Contents  


Quick Checklist  

Sorted by priority – critical measures first.

Critical – Implement Immediately  

High – Authentication & Access  

Medium – Infrastructure  

Maintenance & 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
Important: No public discussion

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  

VersionTypeRegular SupportELTS AvailablePHP Version
TYPO3 14Upcoming LTS (April 2026)Until ~April 2029Yes (afterwards)PHP 8.2+
TYPO3 13LTSUntil December 2027Yes (afterwards)PHP 8.2+
TYPO3 12LTSUntil April 2026Yes (afterwards)PHP 8.1+
TYPO3 11LTSEndedYes (paid)PHP 7.4–8.3
Sprint ReleasesDevelopmentNo supportNovaries
TYPO3 v14 – upcoming LTS release

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.

ELTS – Extended Long Term Support

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)
Security Releases: Time-critical!

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  

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  

Mandatory for all production systems

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] = true in TYPO3 configuration

File Permissions  

Correct permissions prevent unauthorised access:

File TypePermissionReason
Directories755Read/execute for all, write only for owner
PHP files644No direct execution, only via web server
Configuration files640No access for "others"
Upload directories775Web 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.

HeaderValueProtection against
Strict-Transport-Securitymax-age=31536000; includeSubDomainsDowngrade attacks, SSL stripping
X-Frame-OptionsSAMEORIGINClickjacking
X-Content-Type-OptionsnosniffMIME-type sniffing
Referrer-Policystrict-origin-when-cross-originInformation leaks
Permissions-Policygeolocation=(), microphone=()Unwanted API usage
Content-Security-PolicyProject-specificXSS, Code injection

Configuration  

Test Content-Security-Policy!

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:

Database Security  

No web tools in production

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:

FrequencyComposer Installation (v12+)Classic (Legacy)Retention
DailyDatabase + fileadmin/Database + fileadmin/7 days
WeeklyDB + fileadmin/ + config/ + var/log/DB + fileadmin/ + typo3conf/ + uploads/4 weeks
MonthlyFull (+ composer.lock)Full (incl. typo3/ Core)6 months
YearlyFull archiveFull archiveSeveral years
Composer vs. Classic – What to back up?

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 + extensions
  • fileadmin/ + uploads/ – User files
  • typo3/ – Core files
Critical security rules for backups
  • 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)
Test restores regularly!

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:

  1. ENABLE_INSTALL_TOOL file in var/transient/ (Composer) or typo3temp/var/transient/ (Classic)
  2. Separate password (not the admin password!)
  3. Auto-deletion after 60 minutes of inactivity
Forbidden: KEEP_FILE

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.

ContextPurposeDebuggingCaching
ProductionLive systemDisabledActive
Production/StagingStaging serverDisabledActive
DevelopmentDevelopmentEnabledReduced
Development/LocalLocal developmentEnabledMinimal
TestingAutomated testsEnabledDisabled

Configuration  

Context-specific Configuration  

TYPO3 automatically loads additional configuration files based on the Context:

Never forget the Production 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 setupddev config && ddev start
  • Switch PHP version – Easily in .ddev/config.yaml
  • Integrated services – Redis, Solr, MailHog, Elasticsearch
  • Composer & Node – Fully integrated
DDEV for Teams

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:

Critical settings for production

These three settings must be configured correctly in every production environment:

  • trustedHostsPattern – Regex for allowed domains (not .*!)
  • displayErrors = 0 – No error output
  • devIPmask = '' – 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)  

Mandatory for admin accounts

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
Important: Security Bulletins only for TER extensions

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)
Consequence for non-TER extensions

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:

  1. Notification – the Security Team confidentially informs the extension developer
  2. Response required – the developer must show that the extension is actively maintained
  3. Provide a fix – a patch is developed and tested in a private repository
  4. 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.

Golden Rule

"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:

ContextProtection
Fluid variables in HTMLAutomatically escaped
<f:format.raw>No escaping – never for user data!
ViewHelper argumentsNot escaped – escape manually!
JavaScript contextJSON.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

Immediately block access (maintenance page or IP block). This stops further damage and protects visitors.

Secure the evidence

Preserve the current state: file system, database and logs. You will need these for forensic analysis.

Change credentials

Immediately change all passwords: TYPO3 backend, database, FTP/SSH, hosting panel, e-mail.

Conduct Analysis  

Recovery  

No manual cleaning!

Manually "cleaning" a compromised system is extremely error-prone. Backdoors are easily missed and let attackers back in.

Recommended approach:

  1. Identify a clean backup (created before the attack)
  2. Fresh installation on a cleaned server
  3. Restore database from backup
  4. Update TYPO3 and extensions to the latest versions
  5. Close the security hole that allowed the attack
  6. Reset all passwords
  7. 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 

Only recommended installation path

The Composer installation is the only recommended path for production TYPO3 systems. Classic mode should be reserved for testing.

Security Advantages  

AspectComposerClassic
Package VerificationChecksums verifiedManual (if at all)
Update SecurityAtomic updatesDead code possible
Dependency Auditcomposer auditNot available
Reproducibilitycomposer.lockNot guaranteed
Document RootSeparatedEverything 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  

Let's talk about your project

Locations

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Vienna
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Parts of this content were created with the assistance of AI.