General recommendations

Recommendations outlined in this chapter, although not directly focused on setting permissions in TYPO3, are closely related due to the various security aspects described. It is advisable to thoroughly review these recommendations before proceeding to the next chapter, where guidance on establishing top-level backend groups corresponding to different roles, such as editors, proofreaders, and others, is explained.

Create user-specific accounts

When creating backend users, avoid usage of generic usernames like editor, webmaster, proofreader, etc. Instead use their real names, such as johndoe, john.doe, or even their email address, john.doe@mail.com. This approach guarantees that the identity of the user logging into the TYPO3 backend is always known, as well as who is responsible for specific changes in content or configuration.

In the context of GDPR, it is recommended to use properly named accounts to easily distinguish individuals. Assigning top-level groups to these accounts makes identifying user roles straightforward.

Bad username setup

Good username setup

Note

Avoid generic names for a backend username, instead use their real names.

How to ensure safety

When configuring TYPO3 permissions, begin by granting users only necessary access, adding more as needed for security. Avoid giving admin rights unless absolutely necessary, and use specialized accounts for routine tasks like content management.

For temporary TYPO3 backend access, like for a temp worker or student, use the feature to set an expiration date on accounts. This prevents security risks from inactive accounts. Regularly review and remove unnecessary accounts.

Secure each user account with a strong password and follow secure password guidelines for new or updated accounts. Promote cybersecurity by informing users about security policies. Additionally, enable Multi-factor authentication (MFA) for an extra security layer.

Note

• Grant users only the access they truly need

• Instead of using administrative accounts, create groups for specific roles, such as editor, and assign these roles to users

• Regularly maintain backend user accounts, removing any that are no longer needed

• Always establish secure passwords for users

Set permissions via groups, not user records

Permissions, like module visibility, language options, and database or file access, can be configured via backend user records. While direct configuration on user records may seem convenient, especially for small projects, it can lead to long-term issues, such as difficulty tracking permission origins when spread across users and groups. Centralizing permissions in backend groups simplifies their management and maintenance.

Avoid setting permissions directly through the backend user record

When permissions are assigned to individual users and groups, updating them requires editing each account. Setting permissions at the group level simplifies updates, as changes automatically apply to all group members.

Note

Configure permissions only through the backend user groups. Don’t set them on the user record.

File mounts and files management

When planning for permissions and file access, consider how many separate entry points (File Mounts) within file storage you will need. At a minimum, you should create separate folders for each site you manage and then configure them as distinct file mounts, which equate to separate backend groups. These groups can later be assigned to users, granting them access to such folders.

There are cases where some folders and the files within them have to be shared across multiple sites. For this purpose, create separate file mounts and dedicated groups for them. Then, combine these groups within a role group, ensuring that each user associated with such a role group will have access to the specified folders and files in the storage.

Sample backend groups hierarchy

This diagram demonstrates the potential structure of folders within storage. Create dedicated file mounts for folders, and then use those file mounts within backend user groups. This arrangement enables two users with editor roles to access distinct sets of folders: one can access files from Website A and Shared folders, while the other accesses Website B and Shared folders.

Often more complex configuration will be required, with a more nested folder structure for each site. However, the setup remains similar - create separate file mounts where needed and a backend group that will utilize this file mount. Then, assign such groups to role groups.

Note

For each File Mount create a separate backend user group.