If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Security:Unauthorised access

From MoodleDocs

This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date.

Why not view this page on the new site and help us to migrate more content to the new site!

This page forms part of the Moodle security guidelines.

What is the danger?

Assuming you have dealt with the issue of Authentication, so you know who is accessing your Moodle script, the next issue is that different users should only be allowed to do certain things. For example, as student should be allowed to post to a forum, but they should not be allowed to grade their own assignment as 100%.

However, in a system as complex as Moodle, different situations require different users to have different permissions to do, or not do, various things. Therefore, permissions need to be configurable and flexible.

How Moodle avoids this problem

Roles and capabilities

Moodle has a flexible roles system, build around the concepts of

  • contexts - "different situations", e.g. within a course (CONTEXT_COURSE), within a particular activity (CONTEXT_MODULE).
  • capabilities - "various things" a user might do, e.g. mod/forum:replypost, mod/assignment:grade.
  • roles - Roles let administrators and teachers control which users get which capabilities in which contexts. For example, Sam might be a student in course Security 101, and Students are allowed to mod/forum:replypost, so Sam can reply to any post in any forum in the Security 101 course. Different role assignments and role definitions give administrators a lot of flexibility.

This is not the place for a full description of the roles and capabilities. Follow the link above for more.


Moodle also allows users to be put in groups. Different groups may have access to different activities, and may or may not be able to see the actions of people in other groups.

What you need to do in your code

  • Before allowing the user to see anything or do anything, make a call to has_capability or require_capability, testing the appropriate capability in the appropriate context.
    • Get the appropriate context using a call to get_context_instance.
  • For this to work in custom code, you may need to define additional capabilities. For example, block/myblock:viewsecretthing. You can define extra capabilities by creating a .../db/access.php file in your plugin. (There should be a page I can link to explaining this in more detail, but I can't find one.)
  • If appropriate, use the groups API to check group membership, and only show users information from groups they should be able to see.
    • Note that require_login checks basic groups access permissions for you.
  • It is very important to check capabilities when printing UI, but also after data submission before it is processed.

What you need to do as an administrator

  • Think carefully before changing the default role definitions.
  • Always review capability risks before giving permissions to users that are not trusted.
  • Use the various reports, especially the Security overview report, to ensure that users do not have more capabilities than they should.

See also