INFO: Version en.xModule type:

Security Center: Server security check

The server security check lists the status of the most important security checks relating to the server and the installation. This makes it easy to see whether, for example, security-relevant modules are missing or incorrectly configured.

Please note that this is no guarantee of a secure environment. The check is merely an aid to securing the application and server environment in the best possible way.

Security Center: Server security check
Security Center: Server security check

Operation

'There are file archives in the root directory / There are no file archives in the root directory':

At this point, the system checks whether archives (tgz, zip) are stored in the root directory (DOCUMENT_ROOT of the domain). Depending on their content,
file archives can pose a potential risk (malicious code, etc.) or may contain confidential data.
If archives (e.g. zip files) are located directly in the DOCUMENT_ROOT (DocRoot) of the domain, this information is provided.
Archives may contain files with malicious code, confidential information, etc., which is why this is pointed out for security reasons.

'Content can be protected by .htaccess / Content cannot be protected by .htaccess ':

At this point it is checked whether the web server allows the use of .htaccess files with Apache 2.4 syntax. For this purpose, the tmp directory in which an .htaccess file is stored by default is called up as a test.

If no error status 403 is returned, the check assumes that the use of .htaccess files is not permitted (message: "Failed").
If there is directory protection (e.g. authentication via .htaccess), it is not possible to check whether the classic htaccess protection (403) is effective, which is why a 401 error is displayed.
In the negative case, please clarify with your provider whether the use of .htaccess files can be enabled.
Further information on this can be found in the further links (see below).

'Content can be protected by .htaccess with old syntax / Content cannot be protected by .htaccess with old syntax ':

At this point it is checked whether the web server allows the use of .htaccess files with old Apache 2.2 syntax. For this purpose, the tmp directory in which an .htaccess file is stored by default is called up as a test.

If no error status 403 is returned, the check assumes that the use of .htaccess files is not permitted (message: "Failed").
If there is directory protection (e.g. authentication via .htaccess), it is not possible to check whether the classic htaccess protection (403) is effective, which is why a 401 error is displayed.
In the negative case, please clarify with your provider whether the use of .htaccess files can be enabled.

Further information on this can be found in the further links (see below).

'PHP errors are suppressed / PHP errors are not suppressed':

At this point it is checked whether the output of PHP errors is suppressed via the web server or the PHP settings.
For this purpose, a temporary file is written that simulates errors.
If no PHP error or error 500 is returned, the check assumes that PHP is configured so that PHP errors are not output (message: "OK"). Otherwise, the check assumes that PHP errors are not suppressed (message: "Failed").
In the negative case, please clarify with your provider whether your hosting package can be set so that PHP errors are suppressed. However, it should be possible to output PHP errors if required, e.g. via a separate php.ini or an ini_set. Further information on this can be found in the further links (see below).

'PHP warnings are suppressed / PHP warnings are not suppressed':

At this point it is checked whether the output of PHP warnings is suppressed via the web server or the PHP settings.
For this purpose, a file is temporarily written that simulates warnings.
If no PHP warning or error 500 is returned, the check assumes that PHP is configured so that PHP warnings are not output (message: "OK"). Otherwise, the check assumes that PHP warnings are not suppressed (message: "Failed").
If this is not the case, please check with your provider whether your hosting package can be configured to suppress PHP warnings. However, it should be possible to issue PHP warnings if required, e.g. via a separate php.ini or an ini_set.
Further information on this can be found in the further links (see below).

'Directory exclusion is active / Directory exclusion is deactivated':

This checks whether the web server displays the content of directories if the directory is called without specifying an index file (e.g.: /en/).
A directory without index.php is temporarily called for this purpose.
If files and subdirectories are not displayed directly and no error status 403 is returned, the check assumes that the listing of content is not permitted (message: "OK"). Otherwise, the check assumes that content can be displayed (message: "Failed").
In the negative case, please clarify with your provider whether your hosting package can be set to prevent the listing of directory content.
Further information on this can be found in the further links (see below).

'MOD_REWRITE available':

This is used to check whether the web server provides an activated and usable mod_rewrite module.

'Autoupdates activated / Autoupdates deactivated':

At this point, we check whether the option "Allow autoupdates" is activated or deactivated in the system settings (General).

'User with name admin exists':

At this point, the system checks whether the user with the user name admin exists among the users delivered as standard.
You should not use this user name if possible, as this lowers the hurdle for potential attackers.

'Passwords are not salted':

At this point, the system checks whether the setting for salting passwords for users is activated in the system settings.

Please note

  • The security check can be deactivated via the system settings (General). This is recommended if it is ensured that the security criteria are met and a check is therefore superfluous each time the backend is started.