Moodle Roles and Permissions: A Practical Security Audit Guide

Moodle permissions should give each person the minimum access needed for a defined responsibility, at the narrowest sensible context, for only as long as that responsibility exists. An audit must therefore examine effective access, not merely the names of roles on the site.

The short answer is: inventory custom roles and assignments, map sensitive capabilities to accountable owners, inspect overrides in context, test representative users, remove unexplained access and record every accepted exception. A tidy role-definition screen is not proof that a learner, tutor, manager or integration account can only do what policy permits.

What a Moodle Permissions Audit Must Prove

A useful audit answers four questions:

• Who can perform each sensitive action?
• Why do they need that access?
• Where does the permission apply?
• How do we know the effective result matches the approved design?

This is both a security and an operating-model exercise. Excess access can expose personal information, enable destructive changes or blur responsibility for grades and course content. Access that is too restrictive creates support work and encourages administrators to grant broad roles as a quick fix.

Swift Learn's judgement is that a role is defensible only when its purpose fits in one sentence, its scope has a named reason, and a test user can demonstrate the intended boundary. If a team cannot explain why a capability is allowed, the audit should treat it as unresolved rather than assuming it is harmless.

Moodle's official Access API documentation and Roles API documentation, reviewed on 7 October 2026, describe the role-based access model, context hierarchy and capability permissions used in this guide. Labels and available capabilities can vary by supported release and installed plugins, so audit the configuration on your own site rather than copying a generic capability list.

Understand Effective Access Before Changing It

Moodle access control combines four concepts:

• A role is a collection of permission definitions, such as Teacher or a custom Reviewer role.
• A capability represents an action, such as managing activities or viewing particular reports.
• A context is the area where access applies: the system, user, course category, course, activity or block.
• A permission for a capability can inherit, allow, prevent or prohibit.

Contexts form a hierarchy. A role assigned at category level can affect the courses below it; a role assigned inside one course has a much narrower reach. Permissions may also be overridden further down the hierarchy. Moodle's developer guidance is explicit that access decisions concern whether a user has a capability in a particular context, not simply whether the user has a role somewhere.

That distinction explains many failed audits. A list of users called “Manager” says little without assignment context, additional roles and overrides. Equally, a custom role that looks restrained in its definition may become powerful when assigned at system level.

Treat Prohibit as an Exceptional Control

Prevent and prohibit are not interchangeable. A prevent can be countered by an allow in a more specific context. A prohibit cannot: Moodle's documented conflict rules state that prohibit wins.

That strength can be useful for a firm organisational boundary, but it also makes later delegation difficult. Use prohibit only when the policy genuinely requires an access route to remain closed throughout lower contexts. Use prevent for a default that authorised local administrators may need to vary. Record the reason either way; otherwise a future administrator will be forced to reverse-engineer intent from behaviour.

Define the Access Model Outside Moodle

Begin with responsibilities, not existing role names. List the real operating personas: learner, assessor, course editor, programme lead, support analyst, auditor, integration account and platform administrator. For each persona, define the actions required and the information it may handle.

Build a compact access matrix around business actions such as:

• create or delete course content;
• enrol, suspend or impersonate users;
• view identifiable learner reports;
• enter, override or export grades;
• manage completion and certification rules;
• restore courses or download backups;
• install plugins or change site configuration; and
• assign roles to somebody else.

Separate must have, must not have and exception only. This is more useful than debating hundreds of capabilities one by one without a reference model. It also reveals duties that should not sit with the same person. Someone who can change assessment rules, alter grades and approve the final report may need procedural review even if Moodle technically supports the combination.

The trade-off is deliberate. Fewer, broader roles are easier to administer but grant more access than some holders need. Many narrow roles improve precision but increase assignment errors, documentation effort and testing. Choose the smallest set that represents stable responsibilities, then handle genuine exceptions explicitly rather than creating a new role for every individual.

Audit in a Controlled Sequence

1. Inventory Roles, Assignments and Overrides

Export or record standard and custom role definitions, permitted assignment contexts, role-assignment permissions and current holders. Identify system- and category-level assignments first because their reach is greatest. Then inspect course and activity overrides, including temporary arrangements that may have outlived their purpose.

Include service and integration accounts. An account used by enrolment, reporting or automation may not appear in an ordinary staff list, yet its token or role can carry broad access. Record its owner, purpose, authentication method, assignment context and review date.

Do not edit while discovering. Preserve a before-state so that the team can distinguish an existing issue from a change introduced by the audit.

2. Prioritise Risky Capabilities

Moodle associates capabilities with risk types including spam, personal data, cross-site scripting, configuration change and data loss. These indicators help triage an audit, but they do not replace organisational judgement. A reporting capability may be highly sensitive in a healthcare training site even when it does not look like an administrative action.

Review capabilities that allow a user to:

• assign roles or switch into another role;
• access all groups or hidden user information;
• download backups containing user data;
• override grades or completion records;
• upload unsanitised content;
• delete courses, activities or substantial records; or
• alter authentication, plugins, scheduled tasks or global settings.

The OWASP Authorization Cheat Sheet, reviewed on 7 October 2026, recommends least privilege, deny by default, checking permissions on every request, logging and authorization tests. In Moodle administration, least privilege means constraining both the actions a role permits and the context in which the role is assigned.

3. Compare Definitions With Effective Users

Select representative users for every role and exception pattern. Trace all relevant assignments through the context hierarchy and note conflicting roles. Pay particular attention to users who have both a local teaching role and a broader support or manager role.

Moodle's permission-checking tools can help explain a capability in context, but the audit should still test the resulting journey. Check what the user can view, edit, export and delete. Confirm that hidden courses, separate groups and restricted reports behave as intended. Testing a role definition alone can miss access delivered by another assignment.

Avoid relying on “log in as” as the only test. It is useful for diagnosis, but a dedicated test account provides cleaner evidence for authentication, navigation and integrations. Never use a real learner's account merely to make the audit convenient.

4. Resolve Each Difference Deliberately

Classify every mismatch as:

• an unauthorised grant to remove;
• missing access to add at a narrower context;
• a justified exception to document and time-limit;
• an obsolete role or assignment to retire; or
• a policy question requiring an accountable decision.

Test changes on a safe copy where practical, especially for widely assigned roles. Removing a capability may protect data but also interrupt marking, support or scheduled integration work. Conversely, granting a system-level role to solve one course problem usually creates a larger risk than the original ticket.

Prefer a narrow course or category assignment when the responsibility is local. Reserve site administrator access for the small number of people who genuinely operate the platform. A Manager role is not a harmless substitute for Administrator; its capabilities and assignment still require design and review.

Test the Boundaries That Matter

Create a result matrix for each persona. Include one permitted action, one nearby action that must be denied and one sensitive record outside the user's scope. For a course assessor, for example, test the intended grade entry, an unauthorised course, a learner in another group and a grade override if that is meant to be restricted.

Test these situations as well:

1. a user with two roles in the same course;
2. a category role inherited by a child course;
3. an activity-level override;
4. a suspended or ended assignment;
5. a new capability introduced by a plugin or upgrade;
6. a backup, export or report containing personal data; and
7. a delegated user attempting to assign roles to somebody else.

Record expected and actual results with the Moodle version, plugins, role, context and test account. Evidence should be reproducible without retaining unnecessary learner data.

Permissions also affect usability. A learner who cannot reach required content, or an assessor who encounters controls they cannot operate with a keyboard, has an access problem even when the security calculation is technically correct. Include representative journeys from your approach to accessible Moodle courses, and confirm that role-specific navigation does not hide essential instructions.

Govern Roles After the Audit

An audit is a baseline, not a permanent guarantee. Assign an owner to every custom role and every system-level assignment. Require a reason, approver and end date for temporary access. Review departures and role changes promptly, and reconcile accounts against the authoritative staff or enrolment source.

Repeat focused checks after:

• a Moodle or plugin upgrade;
• a new authentication or enrolment integration;
• a reorganisation of categories or programmes;
• a change to grading, completion or reporting; or
• an incident, unexplained export or unexpected support escalation.

New plugins can introduce capabilities, and role archetypes can influence their defaults. Make permission regression testing part of the acceptance plan described in our Moodle upgrade services guide. Do not assume an unchanged role name means an unchanged effective permission set.

Where access affects course completion or learner records, connect the review to the Moodle completion tracking audit. A person who can alter completion criteria, override evidence or export reports sits inside the control chain even if their role is described as course support.

A Practical Audit Checklist

Before changes:

• agree the personas, sensitive actions and accountable decision-makers;
• preserve role definitions, assignments and overrides;
• identify system, category, service and integration accounts; and
• define the test matrix and expected boundaries.

During the audit:

• trace effective capabilities in their actual contexts;
• prioritise risky actions and personal data;
• test permitted and denied journeys with representative accounts;
• investigate conflicting roles, prevent and prohibit; and
• document the reason, owner and expiry of every exception.

At closeout:

• remove obsolete assignments and narrowly replace over-broad ones;
• retest affected workflows and integrations;
• store approved role specifications and evidence;
• assign a review trigger and date; and
• place unresolved policy decisions on an owned risk register.

The Swift Learn Verdict

The safest Moodle permission model is not the one with the fewest allowed capabilities. It is the one that gives people enough access to perform defined work, contains that access to the right context and makes exceptions visible.

Start with responsibilities, then map capabilities. Prefer narrow assignments over powerful global fixes. Use prohibit only for a boundary that must survive every lower context. Test effective users, not labels. Finally, govern access as a changing system: staff, plugins, integrations and course structures will all move after the audit ends.

If historic custom roles, inherited assignments and local overrides make that evidence difficult to produce, a structured review within a managed Moodle support arrangement can separate urgent exposure from longer-term role redesign.

Need a Moodle Permissions Review?

Bring us your role list, key user groups, integrations and one representative course structure. Swift Learn will map effective access, test the highest-risk boundaries and provide a prioritised remediation and governance plan.