---
title: "Global TYPO3 configuration options"
manual: "TYPO3 Explained"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3coreapi:security-global-typo3-options@main"
source: "Security/GuidelinesIntegrators/GlobalTypo3Options.rst"
rendered: "2026-09-23T17:05:17+00:00"
---

# Global TYPO3 configuration options {#security-global-typo3-options}

The following configuration options are accessible and changeable via
the [Install Tool](https://docs.typo3.org/permalink/t3coreapi:security-install-tool@main) (recommended way) or directly
in the file `config/system/settings.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).

-   [displayErrors](https://docs.typo3.org/permalink/t3coreapi:displayerrors@main)
-   [devIPmask](https://docs.typo3.org/permalink/t3coreapi:devipmask@main)
-   [fileDenyPattern](https://docs.typo3.org/permalink/t3coreapi:filedenypattern@main)
-   [IPmaskList](https://docs.typo3.org/permalink/t3coreapi:ipmasklist@main)
-   [lockIP / lockIPv6](https://docs.typo3.org/permalink/t3coreapi:lockip-lockipv6@main)
-   [lockSSL](https://docs.typo3.org/permalink/t3coreapi:lockssl@main)
-   [trustedHostsPattern](https://docs.typo3.org/permalink/t3coreapi:trustedhostspattern@main)
-   [warning_email_addr](https://docs.typo3.org/permalink/t3coreapi:warning-email-addr@main)
-   [warning_mode](https://docs.typo3.org/permalink/t3coreapi:warning-mode@main)

## `displayErrors` {#security-global-typo3-options-displayerrors}

This [configuration option](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-sys-displayerrors@main) 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](https://docs.typo3.org/permalink/t3coreapi:security-global-typo3-options-devipmask@main) 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` {#security-global-typo3-options-devipmask}

The [option devIPmask](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-sys-devipmask@main) 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']`

## `fileDenyPattern` {#security-global-typo3-options-filedenypattern}

The [fileDenyPattern](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-be-filedenypattern@main) 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-8]?|phpsh|phtml|pht|phar|shtml|cgi)(\\..*)?$|\\.pl$|^\\.htaccess$`,
initially defined in constant
`\TYPO3\CMS\Core\Resource\Security\FileNameValidator::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']`

## `IPmaskList` {#security-global-typo3-options-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 the 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](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-be-ipmasklist@main) 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`:

**config/system/additional.php | typo3conf/system/additional.php**

```php
$GLOBALS['TYPO3_CONF_VARS']['BE']['IPmaskList'] = 123.45.67.89,192.168.*.*
```

The default value is an empty string.

## `lockIP` / `lockIPv6` {#security-global-typo3-options-lockip}

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.

> [!WARNING]
> **Attention**
>
> IP locking breaks modern IPv6 setups because of the
> [Fast Fallback aka. Happy Eyeballs](https://en.wikipedia.org/wiki/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](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-fe-lockip@main) (`['FE']['lockIP']` and
`['FE']['lockIPv6']`) and [backend](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-be-lockip@main)
(`['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` {#security-global-typo3-options-lockssl}

As described in [encrypted client/server communication](https://docs.typo3.org/permalink/t3coreapi:security-encrypted-client-server-connection@main), the use of `https://` scheme
for the backend and frontend of TYPO3 drastically improves the security.
The [lockSSL](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-be-lockssl@main) configuration controls if the
backend can only be operated from an 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']`

## `trustedHostsPattern` {#security-global-typo3-options-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](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-sys-trustedhostspattern@main)
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](https://typo3.org/security/advisory/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` {#security-global-typo3-options-warning-email-addr}

The email address defined in [warning_email_addr](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-be-warning-email-addr@main) 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` {#security-global-typo3-options-warning-mode}

This [setting](https://docs.typo3.org/permalink/t3coreapi:typo3confvars-be-warning-mode@main) specifies if emails should
be send to [warning_email_addr](https://docs.typo3.org/permalink/t3coreapi:security-global-typo3-options-warning-email-addr@main) 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']`