---
title: "Server- and environment-level security"
manual: "TYPO3 Explained"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3coreapi:security-administrators-furtheractions@main"
source: "Security/GuidelinesAdministrators/FurtherActions.rst"
rendered: "2026-09-21T11:24:09+00:00"
---

# Server- and environment-level security {#security-administrators-furtheractions}

In addition to TYPO3-specific hardening, system administrators are also
responsible for maintaining a secure hosting environment, PHP configuration,
and monitoring systems. This section highlights complementary actions to
strengthen the overall security posture.

## Keep the hosting environment minimal and secure {#security-admins-hosting}

Administrators should maintain a minimal, secure server setup. Each service
(web, mail, database, DNS, etc.) is a potential attack vector. A compromise in
one component can endanger the entire environment, including TYPO3.

Best practices:

-   Disable unnecessary services
-   Keep all system software up to date, including PHP, the web server,
    database, and other services
-   Isolate systems where possible

A slim, well-maintained environment improves both performance and security.

If in-house server administration is not feasible, consider using a reputable
managed hosting provider that specializes in TYPO3 or PHP applications.

## Use secure PHP settings {#security-admins-php-settings}

TYPO3 runs on PHP, so secure PHP configuration is critical. Useful options
include:

-   `open_basedir` to restrict accessible directories
-   `disable_functions` to disable risky PHP functions

If you rely on external services and don't have `curl` support, you may need to
enable `allow_url_fopen`.

Be aware that blocking outbound traffic (e.g. via firewall) can prevent TYPO3
from retrieving extension updates or translation files.

## Monitor failed backend logins {#security-admins-failed-logins}

Failed backend logins and other security-related events are logged using the
TYPO3 logging framework.

Admins can configure a dedicated log file for authentication messages and use
external tools like [fail2ban](https://www.fail2ban.org) to respond to
suspicious activity.

Example configuration:

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

```php
<?php

use Psr\Log\LogLevel;
use TYPO3\CMS\Core\Core\Environment;
use TYPO3\CMS\Core\Log\Writer\FileWriter;

// Other settings

$GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['Authentication']['writerConfiguration'] = [
  LogLevel::INFO => [
    FileWriter::class => [
      'logFile' => Environment::getVarPath() . '/log/typo3_auth.log',
    ],
  ],
];

```

## Protect against clickjacking {#security-administrators-furtheractions-clickjacking}

Clickjacking tricks users into clicking hidden UI elements via transparent
layers or iframes. TYPO3 protects its backend by sending the HTTP header
`X-Frame-Options`, which blocks embedding backend pages in external domains
(see [RFC 7034](https://datatracker.ietf.org/doc/html/rfc7034)).

To extend protection to the frontend, configure the web server:

**.htaccess (excerpt)**

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

```

Explanation of header values:

-   `SAMEORIGIN`: Allow frames from the same origin only
-   `DENY`: Block all framing
-   `ALLOW-FROM [uri]`: Allow framing from a specific origin (less supported)