Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Guidelines for System Administrators

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Role definition

In this chapter, we define a system administrator as the person who is responsible for the system/server where the TYPO3 instance is installed. System administrators usually have full access on a server level (operating system) and install, configure and maintain the base system and hosting environment, including the database server, web server, PHP, TYPO3, as well as components such as ImageMagick, etc.

System administrators are also responsible for the security of the infrastructure in general, e.g. the network, the appropriate access to the system (e.g. SSH, FTP, etc.) as well as correct permissions on a file system level.

The role of a system administrator often overlaps with a TYPO3 integrator and it happens that one person has both roles.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

General rules

1. Subscribe to the "TYPO3 Announce" mailing list at https://lists.typo3.org, so that you are informed about TYPO3 security bulletins and TYPO3 updates.

2. React as soon as possible and update the relevant components of the site(s) when new vulnerabilities become public (e.g. security issues published in the mailing list).

3. Use different passwords for the Install Tool and the backend login. Follow the guidelines for secure passwords in this document.

4. If you are administrating several TYPO3 installations, use different passwords for all logins and components for every installation.

5. Never use the same password for a TYPO3 installation and any other service such as FTP, SSH, etc.

6. Change the username and password of the "admin" account after the installation of TYPO3 immediately.

7. If you are also responsible for the setup and configuration of TYPO3, follow the steps for TYPO3 integrators carefully, documented in the next chapter.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Integrity of TYPO3 packages

In order to ensure that the downloaded TYPO3 package is an official package released by the TYPO3 developers, compare the SHA2-256 checksum of the downloaded package with the checksum stated on the TYPO3 website, before you extract/install TYPO3. You find the SHA2-256 checksums on get.typo3.org.

Be careful when using pre-installed or pre-configured packages by other vendors: due to the nature and complexity of TYPO3 the system requires configuration. Some vendors offer download-able packages, sometimes including components such as Apache, MySQL, PHP and TYPO3, easy to extract and ready to launch. This is a comfortable way to set up a test or development environment very quickly but it is difficult to verify the integrity of the components – for example the integrity of TYPO3.

A similar thing applies to web environments offered by hosting companies: system images sometimes include a bunch of software packages, including a CMS. It depends on the specific project and if you can trust the provider of these pre-installed images, systems, packages – but if you are in doubt, use the official TYPO3 packages only. For a production site in particular, you should trust the source code published at get.typo3.org only.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

File/directory permissions

The correct and secure setup of the underlying server is an essential prerequisite for a secure web application. Well-considered access permissions on files and directories are an important part of this strategy. However, too strict permissions may stop TYPO3 from working properly and/or restrict integrators or editors from using all features of the CMS. The official TYPO3 Installation and Upgrade Guide provides further information about the install procedure.

We do not need to mention that only privileged system users should have read/write access to files and directories inside the web root. In most cases these are only users such as "root" and the user, that the web server runs as (e.g. www-data). On some systems (e.g. shared hosting environments), the web server user can be a specific user, depending on the system configuration.

An important security measure for systems on which multiple users run their websites (e.g. various clients on a shared server) is to ensure that one user cannot access files in another client's web root. This server misconfiguration of file/directory permissions may occur if all virtual hosts run as the same user, for example the default web server user. The risk with this setup is, that a script on another virtual host includes files from the TYPO3 instance or writes or manipulates files. The TYPO3 configuration file LocalConfiguration.php, which contains sensitive data, would be a typical example.

Besides the strict separation between multiple virtual hosts, it is possible to revoke any write permissions for the web server user (e.g. www-data) to the TYPO3 source directory in general. In other words: only allow write access to resources, the web server user requires to have write access for, such as fileadmin/, typo3conf/, typo3temp/.

On UNIX/Linux based systems, a secure configuration can be achieved by setting the owner and group of directories and files correctly, as well as their specific access rights (read/write/execute). Even if users need write access to the fileadmin/ directory (besides the web server user), this can be technically achieved.

It is not recommended to allow TYPO3 editors and other unprivileged users FTP, SFTP, SSH, WebDAV, etc. access to the web server's root directory or any sub-directory of it. See other services for further explanations.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Restrict access to files on a server-level

This is a controversial topic: Some experts recommend to restrict the access to specific files on a server-level by using Apache's FilesMatch directive for example. Such files could be files with the endings .bak, .tmp, .sql, .old, etc. in their file names. The purpose of this restriction is, that even if backup files or database dump files are accidentally stored in the DocRoot directory of the web server, they cannot be downloaded.

The downside of this measure is, that this is not the solution of the problem but a workaround only. The right recommendation would be not to store sensitive files (such as backups, etc.) in the DocRoot directory at all – instead of trying to address the issue by restricting the access to certain file names (keep in mind that you cannot predict which file names could occur in the future).

Verification of access restrictions

Administrators should test and verify file access to these files are actually denied. The following list provides some files as an example that should not be retrievable directly by using HTTP requests:

• https://example.org/.git/index

• https://example.org/INSTALL.md

• https://example.org/INSTALL.txt

• https://example.org/ChangeLog

• https://example.org/composer.json

• https://example.org/composer.lock

• https://example.org/vendor/autoload.php

• https://example.org/typo3_src/Build/package.json

• https://example.org/typo3_src/bin/typo3

• https://example.org/typo3_src/INSTALL.md

• https://example.org/typo3_src/INSTALL.txt

• https://example.org/typo3_src/ChangeLog

• https://example.org/typo3_src/vendor/autoload.php

• https://example.org/typo3conf/LocalConfiguration.php

• https://example.org/typo3conf/AdditionalConfiguration.php

• https://example.org/typo3temp/var/log/

• https://example.org/typo3temp/var/session/

• https://example.org/typo3temp/var/tests/

• https://example.org/typo3/sysext/core/composer.json

• https://example.org/typo3/sysext/core/ext_tables.sql

• https://example.org/typo3/sysext/extbase/ext_typoscript_setup.txt

• https://example.org/typo3/sysext/extbase/ext_typoscript_setup.typoscript

• https://example.org/typo3/sysext/felogin/Configuration/FlexForms/Login.xml

• https://example.org/typo3/sysext/backend/Resources/Private/Language/locallang.xlf

• https://example.org/typo3/sysext/backend/Tests/Unit/Utility/Fixtures/clear.gif

• https://example.org/typo3/sysext/belog/Configuration/TypoScript/setup.txt

• https://example.org/typo3/sysext/belog/Configuration/TypoScript/setup.typoscript

The list above is probably not complete. However, if general deny rules are in place links provided above should not be accessible anymore and result in a HTTP 403 error response.

Apache and Microsoft IIS web servers

Hint

TYPO3 provides a recommended .htacess file. See Environment .

To increase protection of TYPO3 instances, the Core Team however decided to install default web server configuration files since TYPO3 core version v9 under certain

To increase protection of TYPO3 instances, the Core Team however decided to install default web server configuration files since TYPO3 Core version v9 under certain circumstances: If an Apache web server is detected by the web based installation procedure, a default .htaccess file is written to the document root, and if a Microsoft IIS web server is detected, a default web.config file is written to the document root. These files contain web server configurations to deny direct web access to a series of common file types and directories, for instance version control system directories like .git/, all private template directories like Resources/Private/ and common package files like composer.json.

This "black list" approach needs maintenance: The core team tries to keep the template files .htaccess and web.config updated. If running Apache or IIS, administrators should compare their specific version with the reference files found at root-htaccess and root-web-config and adapt or update local versions if needed.

NGINX web servers

Administrators running the popular web server NGINX need to take additional measures: NGINX does not support an approach like Apache or IIS to configure access by putting files into the web document directories - the TYPO3 install procedure can not install good default files and administrators must merge deny patterns into the web servers virtual host configuration. A typical example looks like this:

server {

    ...

    # Prevent clients from accessing hidden files (starting with a dot)
    # This is particularly important if you store .htpasswd files in the site hierarchy
    # Access to `/.well-known/` is allowed.
    # https://www.mnot.net/blog/2010/04/07/well-known
    # https://tools.ietf.org/html/rfc5785
    location ~* /\.(?!well-known\/) {
        deny all;
    }

    # Prevent clients from accessing to backup/config/source files
        location ~* (?:\.(?:bak|conf|dist|fla|in[ci]|log|psd|sh|sql|sw[op])|~)$ {
        deny all;
    }

    # TYPO3 - Block access to composer files
    location ~* composer\.(?:json|lock) {
        deny all;
    }

    # TYPO3 - Block access to flexform files
    location ~* flexform[^.]*\.xml {
        deny all;
    }

    # TYPO3 - Block access to language files
    location ~* locallang[^.]*\.(?:xml|xlf)$ {
        deny all;
    }

    # TYPO3 - Block access to static typoscript files
    location ~* ext_conf_template\.txt|ext_typoscript_constants\.(?:txt|typoscript)|ext_typoscript_setup\.(?:txt|typoscript) {
        deny all;
    }

    # TYPO3 - Block access to miscellaneous protected files
    location ~* /.*\.(?:bak|co?nf|cfg|ya?ml|ts|typoscript|dist|fla|in[ci]|log|sh|sql)$ {
        deny all;
    }

    # TYPO3 - Block access to recycler and temporary directories
    location ~ _(?:recycler|temp)_/ {
        deny all;
    }

    # TYPO3 - Block access to configuration files stored in fileadmin
    location ~ fileadmin/(?:templates)/.*\.(?:txt|ts|typoscript)$ {
        deny all;
    }

    # TYPO3 - Block access to libaries, source and temporary compiled data
    location ~ ^(?:vendor|typo3_src|typo3temp/var) {
        deny all;
    }

    # TYPO3 - Block access to protected extension directories
    location ~ (?:typo3conf/ext|typo3/sysext|typo3/ext)/[^/]+/(?:Configuration|Resources/Private|Tests?|Documentation|docs?)/ {
        deny all;
    }

    ...

}

The config example above has been taken from ddev.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Directory indexing

Depending on the operating system and distribution, the default configuration of Apache allows the indexing of directories. This enables search engines to index your file structure and possibly reveals sensitive data. The screenshot below shows an example of such data that can be retrieved with a simple HTTP request.

In this case only the list of extensions is revealed, but more sensitive data can be found easily. The Apache configuration allows you to enable or disable the indexing of directories by the Options directive as shown in the following example:

<Directory /path/to/your/webroot/>
  Options Indexes FollowSymLinks
</Directory>

By removing the Indexes option, Apache does not show the list of files and directories. Please note that the Options directive can be used in several containers (e.g. <VirtualHost>, <Directory>, <Location>, etc.). The correct configuration could look like the following example:

<Directory /path/to/your/webroot/>
  Options FollowSymLinks
</Directory>

If your specific website requires directory indexing at other places outside TYPO3, you should consider to deactivate this option in general but explicitly allow indexing for the required directories only.

Other web servers such as Microsoft Internet Services (IIS) allow similar configurations. See your web server's manual for further details on how to disable directory indexing.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Database access

The TYPO3 database contains all data of backend and frontend users and therefore special care must be taken not to grant unauthorized access.

Secure passwords and minimum access privileges with MySQL

If using MySQL, the privilege system authenticates a (database-)user who connects from the TYPO3 host (which is possibly on the same machine) and associates that user with privileges on a database. These privileges are for example: SELECT, INSERT, UPDATE, DELETE, etc.

When creating this user, follow the guidelines for secure passwords. The name of the user should definitely not be root, admin, typo3, etc. You should create a database specific user with limited privileges for accessing this database from TYPO3. Usually this user does not require access to any other databases and the database of your TYPO3 instance should usually only have one associated database user.

MySQL and other database systems provide privileges that apply at different levels of operation. It depends on your individual system and setup which privileges the database user needs (SELECT, INSERT, UPDATE and some more are essential of course) but privileges like LOCK TABLES, FILE, PROCESS, CREATE USER, RELOAD, SHUTDOWN, etc. are in the context of administrative privileges and not required in most cases.

See the documentation of your database system on how to set up database users and access privileges.

Database not within web document root with SQLite

If using SQLite as underlying database, a database is stored in a single file. In TYPO3, its default location is the var/sqlite path of the instance which is derived from environment variable TYPO3_PATH_APP. If that variable is not set which is often the case in not Composer based instances, the database file will end up in the web server accessible document root directory :file:`typo3conf/`! In such a setup it is important to configure Web servers to not deliver .sqlite files.

Disallow external access

The database server should only be reachable from the server that your TYPO3 installation is running on. Make sure to disable any access from outside of your server or network (settings in firewall rules) and/or do not bind the database server to a network interface.

If you are using MySQL, read the chapter Server Options in the manual and check for the "skip-networking" and "bind-address" options in particular.

Database administration tools

phpMyAdmin and similar tools intend to allow the administration of MySQL database servers over the Web. Under certain circumstances, it might be required to access the database "directly", during a project development phase for example. Tools like phpMyAdmin (also available as a TYPO3 extension by the way) cause extra effort for ongoing maintenance (regular updates of these tools are required to ensure a minimum level of security). If they are not avoidable by any chance, the standalone version with an additional web server's access authentication (e.g. Apache's .htaccess mechanism) should be used at least.

However, due to the fact that a properly configured TYPO3 system does not require direct access to the database for editors or TYPO3 integrators, those applications should not be used on a production site at all.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Encrypted client/server communication

Data classification

It depends on the nature of the data but in general "sensitive" information could be: user logins, passwords, user details (such as names, addresses, contact details, etc.), email addresses and other data which are not public. Medical, financial data (e.g. credit card details, account numbers, access codes, etc.) and others, are confidential by their nature and must not be transmitted unencrypted at all.

In most cases, a data assessment should be undertaken to classify the data according to several traits relating to use, legal requirements, and value. The outcome of this assessment can be a categorization based on a data classification model, which then defines how to protect the data.

	Public	Public Restricted	Organization Confidential	Organization Secret
Type	non-sensitive	externally sensitive	internally sensitive	extremely sensitive
Disclosure impact	none	limited	significant	sever
Access restrictions	none	low (e.g. username/ password)	high (e.g. public/private key + geolocation)	very high
Data transport	unencrypted	unencrypted but protected	encrypted	highly encrypted
Storage requirements	none	unencrypted but protected	encrypted	highly encrypted

The secure and maybe encrypted storage of sensitive data should also be considered.

The most secure first paradigm in most cases is: do neither transmit nor store any sensitive data if not absolutely required.

Frontend

Transport Layer Security (TLS) is an industry standard and the current security technology for establishing an encrypted link between a browser (client) and a web server. This protocol provides encrypted, authenticated communications across the Internet and ensures that all data passed between client and server remains private and integral. It is based on a public/private key technology and uses certificates which typically contain the domain name and details about the website operator (e.g. company name, address, geographical location, etc.). Recent discussions are questioning the organizational concept behind SSL certificates and the "chain of trust", but the fact is that SSL is the de facto standard today and still is considered secure from a technical perspective.

Whenever sensitive data is transferred between a client (the visitor of the website) and the server (TYPO3 website), a TLS encrypted connection should be used. Most often his means the protocol https is used instead of http.

When using payment gateways to process payments for online shops for example, most financial institutions (e.g. credit card vendors) require appropriate security actions. Check the policies of the gateway operator and card issuers before you institute online payment solutions.

Backend

A risk of unencrypted client/server communication is that an attacker could eavesdrop the data transmission and "sniff" sensitive information such as access details. Unauthorized access to the TYPO3 backend, especially with an administrator user account, has a significant impact on the security of your website. It is clear that the use of TLS for the backend of TYPO3 improves the security.

TYPO3 supports a TLS encrypted backend and offers some specific configuration options for this purpose, see configuration option lockSSL.

Drop FTP

An encrypted communication between client and server for further services than the TYPO3 frontend and backend should be considered, too. For example, it is highly recommended to use encrypted services such as SSH (secure shell), SFTP (SSH file transfer protocol) or FTPS (FTP-Secure) instead of FTP, where data is transferred unencrypted.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Other services

System administrators should keep in mind that every "untrusted" script (e.g. PHP, perl, python script) or executable file inside the web server's document root is a security risk. By a correct and secure configuration, the internal security mechanisms of TYPO3 ensure that the CMS does not allow editors and other unprivileged users to place such code through the system (see chapter Global TYPO3 configuration options).

However, it is often seen that other services like FTP, SFTP, SSH, WebDAV, etc. are enabled to allow users (for example editors) to place files such as images, documents, etc. on the server, typically in the fileadmin/ folder. It is out of question that this might be seen as a convenient way to upload files and file transfers via FTP are simpler and faster to do. The main problem with this is that to enable "other services" with write access to the document root directory, bypasses the security measures mentioned above. A malicious PHP script for example could manipulate or destroy other files – maybe TYPO3 core files. Sometimes access details of editors are stolen, intercepted or accidentally fallen into the wrong hands.

The only recommendation from a security perspective is to abandon any service like FTP, SFTP, etc. which allows to upload files to the server by bypassing TYPO3.

The TYPO3 Security Team and other IT security experts advance the view that FTP is classified as insecure in general. They have experienced that many websites have been hacked by a compromised client and/or unencrypted FTP connections and as a consequence, it strongly is advised that FTP must not be used at all.

Attention

TYPO3 v9 has reached its end-of-life September 30th, 2021 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Further actions

Hosting environment

A system administrator is usually responsible for the entirety of an IT infrastructure. This includes several services (e.g. web server, mail server, database server, SSH, DNS, etc.) on one or on several servers. If one component is compromised, it is likely that this opens holes to attack other services.

As a consequence, it is desired to secure all components of an IT infrastructure and keep them up-to-date and secure with only a little or no dependencies to other system. It is also wise to abandon services which are not necessarily required (e.g. an additional database server, DNS server, IMAP/POP3 server, etc.). In short words: keep your hosting environment as slim as possible for performance and security purposes.

Security-related PHP settings

Due to the fact that TYPO3 is a PHP application, secure PHP settings are also important, of course. PHP settings, such as open_basedir, disable_functions often improve the security of your system and should be considered.

Note that disallowing remote connections (e.g. by deactivating allow_url_fopen or by blocking outgoing traffic on a firewall in front of the TYPO3 server) may have an impact on the retrieval of the TYPO3 extension list, which allows you to check if extension updates are available!

Events in log files

Login attempts to the TYPO3 backend, which are unsuccessful, result in a server response to the client with HTTP code 401 ("Unauthorized"). Due to the fact that this incident is logged in the web server's error log file, it can be handled by external tools, such as fail2ban.

Defending against Clickjacking

Clickjacking, also known as user interface (UI) redress attack or UI redressing, 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. This attack can be typically achieved by a combination of stylesheets and iframes, where multiple transparent or opaque layers manipulate the visual appearance of a HTML page.

To protect the backend of TYPO3 against this attack vector, a HTTP header X-Frame-Options is sent, which prevents embedding backend pages in an iframe on domains different than the one used to access the backend. The X-Frame-Options header has been officially standardized as RFC 7034.

System administrators should consider enabling this feature at the frontend of the TYPO3 website, too. A configuration of the Apache web server would typically look like the following:

<IfModule mod_headers.c>
  Header always append X-Frame-Options SAMEORIGIN
</IfModule>

The option SAMEORIGIN means, that the page can only be displayed in a frame on the same origin as the page itself. Other options are DENY (page cannot be displayed in a frame, regardless of the site attempting to do so) and ALLOW-FROM [uri]` (page can only be displayed in a frame on the specified origin).

Please understand that detailed descriptions of further actions on a server-level and specific PHP security settings are out of scope of this document. The TYPO3 Security Guide focuses on security aspects of TYPO3.