[TASK] Update more admin Security Guidelines

Documentation/Security/GuidelinesAdministrators/ContentSecurityPolicy.rst

@@ -53,7 +53,7 @@ accessed via :samp:`https://example.org/fileadmin/...`:
 For nginx webservers, the following configuration example can be used to send
 a CSP_ header for any file accessed via :samp:`https://example.org/fileadmin/...`:
 
-..   code-block:: nginx
+..  code-block:: nginx
 
     map $request_uri $csp_header {
         ~^/fileadmin/ "default-src 'self'; script-src 'none'; style-src 'none'; object-src 'none';";

Documentation/Security/GuidelinesAdministrators/FileExtensionHandling.rst

@@ -1,6 +1,6 @@
-.. include:: /Includes.rst.txt
-.. index:: pair: Security guidelines; File extensions
-.. _security-file-extension-handling:
+..  include:: /Includes.rst.txt
+..  index:: pair: Security guidelines; File extensions
+..  _security-file-extension-handling:
 
 =======================
 File extension handling
@@ -12,40 +12,40 @@ to corresponding mime-types like `text/html` or `text/plain`.
 The focus in this section is on handling multiple extensions like `.html.txt` -
 in general the last extension part (`.txt` in `.html.txt`) defines the mime-type:
 
-* `file.html` shall use mime-type `text/html`
-* `file.html.txt` shall use mime-type `text/plain`
-* `file.html.wrong` shall use mime-type `text/plain` (but especially not `text/html`)
+*   `file.html` shall use mime-type `text/html`
+*   `file.html.txt` shall use mime-type `text/plain`
+*   `file.html.wrong` shall use mime-type `text/plain` (but especially not `text/html`)
 
 Apache's `mod_mime`_ documentation explains their handling of files having multiple extensions.
 Directive `TypesConfig` and using a `mime.types`_ map probably
 leads to unexpected handling of extension `.html.wrong` as mime-type `text/html`:
 
-.. code-block:: apacheconf
+..  code-block:: apacheconf
 
-   AddType text/html     html htm
-   AddType image/svg+xml svg svgz
+    AddType text/html     html htm
+    AddType image/svg+xml svg svgz
 
 Global settings like shown in the example above
 are matching `.html` and `.html.wrong` file extension
 and have to be limited with `<FilesMatch>`:
 
-.. code-block:: apacheconf
+..  code-block:: apacheconf
 
-   <FilesMatch ".+\.html?$">
-       AddType text/html     .html .htm
-   </FilesMatch>
-   <FilesMatch ".+\.svgz?$">
-       AddType image/svg+xml .svg .svgz
-   </FilesMatch>
+    <FilesMatch ".+\.html?$">
+        AddType text/html     .html .htm
+    </FilesMatch>
+    <FilesMatch ".+\.svgz?$">
+        AddType image/svg+xml .svg .svgz
+    </FilesMatch>
 
 In case these settings cannot be applied to the global server configuration,
 but only to :file:`.htaccess` it is recommended to remove the default behavior:
 
-.. code-block:: apacheconf
-   :caption: .htaccess
+..  code-block:: apacheconf
+    :caption: .htaccess
 
-   RemoveType .html .htm
-   RemoveType .svg .svgz
+    RemoveType .html .htm
+    RemoveType .svg .svgz
 
 The scenario is similar when it comes to evaluate PHP files -
 it is totally expected and fine for files like `test.php` (ending with `.php`) -
@@ -55,13 +55,13 @@ but it is definitively unexpected for files like `test.php.html`
 The expected `default configuration`_ should look like the following
 (adjusted to the actual PHP script dispatching via CGI, FPM or any other type):
 
-.. code-block:: apacheconf
-   :caption: .htaccess
+..  code-block:: apacheconf
+    :caption: .htaccess
 
-   <FilesMatch ".+\.php$">
-       SetHandler application/x-httpd-php
-   </FilesMatch>
+    <FilesMatch ".+\.php$">
+        SetHandler application/x-httpd-php
+    </FilesMatch>
 
-.. _mod_mime: https://httpd.apache.org/docs/2.4/mod/mod_mime.html#multipleext
-.. _mime.types: https://github.com/apache/httpd/blob/5f32ea94af5f1e7ea68d6fca58f0ac2478cc18c5/docs/conf/mime.types#L1688
-.. _default configuration: https://salsa.debian.org/php-team/php/-/blob/dc253886b5b2e9bc8d9e36db787abb083a667fd8/debian/php-cgi.conf#L5-7
+..  _mod_mime: https://httpd.apache.org/docs/2.4/mod/mod_mime.html#multipleext
+..  _mime.types: https://github.com/apache/httpd/blob/5f32ea94af5f1e7ea68d6fca58f0ac2478cc18c5/docs/conf/mime.types#L1688
+..  _default configuration: https://salsa.debian.org/php-team/php/-/blob/dc253886b5b2e9bc8d9e36db787abb083a667fd8/debian/php-cgi.conf#L5-7

Documentation/Security/GuidelinesAdministrators/FurtherActions.rst

@@ -1,111 +1,96 @@
-.. include:: /Includes.rst.txt
-.. _security-administrators-furtheractions:
+:navigation-title: Server environment
 
-===============
-Further Actions
-===============
+..  include:: /Includes.rst.txt
+..  _security-administrators-furtheractions:
 
+======================================
+Server- and environment-level security
+======================================
 
-.. index:: pair: Security guidelines; Hosting environment
+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.
 
-Hosting environment
-===================
+..  index:: pair: Security guidelines; Hosting environment
+..  _security-admins-hosting:
 
-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.
+Keep the hosting environment minimal and secure
+===============================================
 
-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.
+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:
 
-.. index:: pair: Security guidelines; PHP settings
+-   Disable unnecessary services
+-   Keep all system software up to date, including PHP, the web server,
+    database, and other services
+-   Isolate systems where possible
 
-Security-related PHP settings
-=============================
+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.
 
-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.
+..  index:: pair: Security guidelines; PHP settings
+..  _security-admins-php-settings:
 
-In use cases where you rely on outbound connections and your PHP comes without support
-for curl it might be required to set `allow_url_fopen` to true.
+Use secure PHP settings
+=======================
 
-Note that disallowing remote connections (e.g. 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, or on retrival of translation files.
+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
 
-Events in TYPO3 Log Files
-=========================
+If you rely on external services and don't have `curl` support, you may need to
+enable `allow_url_fopen`.
 
-Login attempts to the TYPO3 backend, which are unsuccessful, are logged
-using the TYPO3 logging API. It is possible to create a dedicated
-logfile for messages from TYPO3 authentication classes which can be
-handled by external tools, such as `fail2ban <https://www.fail2ban.org>`_.
+Be aware that blocking outbound traffic (e.g. via firewall) can prevent TYPO3
+from retrieving extension updates or translation files.
 
-Example logging configuration:
+..  index:: pair: Security guidelines; Log files
+..  _security-admins-failed-logins:
 
-.. code-block:: php
-  :caption: config/system/additional.php | typo3conf/system/additional.php
+Monitor failed backend logins
+=============================
 
-   $GLOBALS['TYPO3_CONF_VARS']['LOG']['TYPO3']['CMS']['Core']['Authentication']['writerConfiguration'] = [
-       \Psr\Log\LogLevel::INFO => [
-           \TYPO3\CMS\Core\Log\Writer\FileWriter::class => [
-               'logFile' => \TYPO3\CMS\Core\Core\Environment::getVarPath() . '/log/typo3_auth.log',
-           ]
-       ]
-   ];
+Failed backend logins and other security-related events are logged using the
+TYPO3 logging framework.
 
-.. index::
-   pair: Security guidelines; Clickjacking
-   pair: Security guidelines; X-Frame-Options
-.. _security-administrators-furtheractions-clickjacking:
+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:
 
-Defending Against Clickjacking
-==============================
+..  literalinclude:: _codesnippets/_additional.php
+    :caption: config/system/additional.php | typo3conf/system/additional.php
 
-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.
+..  index::
+    pair: Security guidelines; Clickjacking
+    pair: Security guidelines; X-Frame-Options
+..  _security-administrators-furtheractions-clickjacking:
 
-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 <https://datatracker.ietf.org/doc/html/rfc7034>`_.
+Protect against clickjacking
+============================
 
-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:
+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>`_).
 
-.. code-block:: apacheconf
-   :caption: .htaccess
+To extend protection to the frontend, configure the web server:
 
-   <IfModule mod_headers.c>
-     Header always append X-Frame-Options SAMEORIGIN
-   </IfModule>
+..  literalinclude:: _codesnippets/_sameorigin.htaccess
+    :language: apacheconf
+    :caption: .htaccess (excerpt)
 
-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).
+Explanation of header values:
 
-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.
+-   `SAMEORIGIN`: Allow frames from the same origin only
+-   `DENY`: Block all framing
+-   `ALLOW-FROM [uri]`: Allow framing from a specific origin (less supported)

Documentation/Security/GuidelinesAdministrators/_codesnippets/_additional.php

@@ -0,0 +1,15 @@
+<?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',
+        ],
+    ],
+];

Documentation/Security/GuidelinesAdministrators/_codesnippets/_sameorigin.htaccess

@@ -0,0 +1,3 @@
+<IfModule mod_headers.c>
+    Header always append X-Frame-Options SAMEORIGIN
+</IfModule>