TYPO3 Security Hardening Guide – Best Practices for Production

A practical guide to securing TYPO3 instances: server configuration, application context, extension management, and incident response. Includes configuration examples and official sources.

Overview

  • Critical measures: HTTPS (TLS 1.2+), setting trustedHostsPattern correctly, disabling error output, keeping LTS up to date.
  • MFA for all admin accounts, securing the Install Tool, rate limiting (native in v13+), minimum privileges based on 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.

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.

Last updated: 3 December 2025 – incl. TYPO3 v14.0 (Sprint 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 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
Important: No Public Discussion

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  

VersionTypeRegular SupportELTS availablePHP Version
TYPO3 14Sprint → LTS (April 2026)Until ~April 2029Yes (afterwards)PHP 8.2+
TYPO3 13LTSUntil October 2027Yes (afterwards)PHP 8.2+
TYPO3 12LTSUntil April 2026Yes (afterwards)PHP 8.1+
TYPO3 11LTSEndedYes (subject to a fee)PHP 7.4–8.2
Sprint ReleasesDevelopmentNo supportNovaries
TYPO3 v14 – Sprint Release available

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.

ELTS – Extended Long Term Support

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

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  

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  

Mandatory for all production systems

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] = 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 are an important layer of defence against various attacks. The web server sends them and instructs the browser on secure behaviour.

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!

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:

Database Security  

No web tools in production

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:

FrequencyComposer Installation (v12+)Classic (Legacy)Retention
DailyDatabase + fileadmin/Database + fileadmin/7 days
WeeklyDB + fileadmin/ + config/ + var/log/DB + fileadmin/ + typo3conf/ + uploads/4 weeks
MonthlyComplete (+ composer.lock)Complete (incl. typo3/ Core)6 months
AnnuallyComplete archiveComplete 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 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 your restore regularly!

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:

  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 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.

ContextPurposeDebuggingCaching
ProductionLive systemDisabledActive
Production/StagingStaging serverDisabledActive
DevelopmentDevelopmentActivatedReduced
Development/LocalLocal developmentActivatedMinimal
TestingAutomated testsActivatedDisabled

Configuration  

Context-Specific Configuration  

TYPO3 automatically loads additional configuration files based on the context:

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

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:

Critical Settings for Production

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

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

Mandatory for admin accounts

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

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

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:

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

Golden Rule

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

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

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

Securing evidence

Save the current state: file system, database, logs. These are required for forensic analysis.

Change credentials

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

Conducting Analysis  

Recovery  

No manual cleaning!

Manually 'cleaning' a compromised system is extremely prone to error. Backdoors are often overlooked and allow renewed access.

Recommended procedure:

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

Only recommended installation method

The Composer installation is the only recommended method for productive TYPO3 systems. Classic mode should only be used for testing purposes.

Security Advantages  

AspectComposerClassic
Package verificationChecksums checkedManual (if at all)
Update securityAtomic updatesCode remnants possible
Dependency Auditcomposer auditNot available
Reproducibilitycomposer.lockNot guaranteed
Document RootSeparatedEverything 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  

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.