We will present here a list of recommendations and suggestions to help you improve your security.

Avoid assigning the roles on the system level unless really necessary. Any permission change on the system level affects the entire system and therefore can increase security and maintenance risk. Try to apply roles to the specific part of Moodle where you would like to operate. This is especially important for students and teachers.

Avoid giving more than one role to a user in the same context. A minimalistic approach is the best whenever possible. You should try to fit all your user needs into one role. If you detect a type of user that does not fit completely in any of the existing roles it is most likely time to start creating a new role.

It is better not to change standard roles. In case you wish to introduce a change make a new role based on the standard role and apply your changes to it.

Risky capabilities

All capabilities are marked by risk level value. Moodle defines four risk types—Configuration, XSS, Privacy, and Spam.

• XSS: It is a short name for cross-site scripting vulnerability. This vulnerability (when present) may permit a malicious attacker to "inject" client-side script into a web page viewed by other users. This technique is used to obtain data from a user or to circumvent authentication (stealing session ID).
• Privacy: This risk denotes a possibility of exposing more information about other users than desired, if an unprotected site can be scraped for user information by Internet bots.
• Spam: This level of risk may permit somebody to post unsolicited content either directly within a platform or by sending personal messages to other users.

Here is the list of the several capabilities with highest risk danger. Remember that you can access these (and other) capabilities within a specific role by visiting the Administration | Users | Permissions | Define roles page.

• Create new blog entries: With this capability, users are permitted to create new blog entries. It is marked with spam risk since it can be abused by a malicious user to generate and post spam content. Authenticated user role has this setting enabled; hence all users by default can create blog posts.

  To increase the security we recommend disabling blog feature completely unless it is necessary for your educational process. To disable blog visit Administration | Security | Site policies, locate Blog visibility and set it to Disable blog system completely.

  An alternative to this would be disabling this capability in Authenticated user role and modifying one of the other existing roles to include it in case we just want to limit which users can blog.

• Create users on restore: This capability allows a user to create new users while importing a course/platform backup. By default, it is permitted only for Administrator role. You should not enable this capability within other roles unless you are creating separate administration roles. This capability has been introduced in Moodle 1.9.8 in order to prevent security issues with user data. All users are advised to upgrade as soon as possible.
• Change site configuration and Allowed to do anything: These two are obviously for administrators only. It is extremely risky to give these capabilities to too many users as it gives full access to everything. Keep it within Administrator role.
• Change own password: This is a potentially dangerous capability. If any user account is breached by a malicious user he can modify the password and effectively prevent the real user from using the platform. We recommend disabling this capability at least for the student roles. However, this would put additional burden on the support staff in case any student forgets his credentials.
• View participants (system level): With this capability enabled a user can see all user accounts (Administration | Users | Accounts | Browse list of users). It is not set by default in any role outside the Administrator role. We recommend leaving it as such.
• View participants (course level): With this capability enabled a user can see all participants of a course (<course> | Participants). By default student role has this setting enabled. If you want to isolate users from peeking into profiles of each other you should modify student role and change permission to not set. This would also remove participants block from course view.
• Backup user data: By default this capability is enabled only for Administrator role. We recommend to leave it like that and to protect all such accounts with strong passwords. The reason why this is dangerous is that through course backup a malicious user could easily obtain all user data together with passwords.