5 Moodle Security Settings Most Admins Get Wrong

Moodle ships with a security checklist built right into it that most admins have never opened. It is under Site administration > Reports > Security checks. Every time you load that page, Moodle runs a series of tests against your live configuration and tells you, in plain language, what is safe and what is not. Most sites have at least two or three settings wrong. This guide walks through the five that come up most often, what each one exposes, and exactly where to fix it. Paths and labels are for Moodle 4.5.

1. Displaying of PHP errors

When this is on and something breaks, Moodle prints the raw technical error straight onto the page. That error can reveal your file paths, database details, even fragments of code, to anyone who happens to trigger it: a roadmap for an attacker. On any live site this should be off. Fix it under Site administration > Development > Debugging: set Debug messages to NONE for production, and make sure Display debug messages is unticked.

2. Allow EMBED and OBJECT

Moodle’s own description calls this “very dangerous”, and it means it. With <embed> and <object> tags allowed, any user who can add content can paste in markup that runs code inside other people’s browsers, a cross-site scripting attack. Unless you have a very specific reason and you trust every single account on your site, leave this off. (This is the same RISK_XSS family that the “XSS trusted users” check counts.)

3. Open to search engines

This setting lets Google and other crawlers walk into your courses as a guest. On its own that might be harmless, but combined with guest access switched on, it can quietly publish course content you assumed was private to the entire internet. If you do not specifically need public, crawlable courses, turn it off. The security report links straight to the setting.

4. Default role for all users, and Site home role

This is the subtle one. The security report has two related checks, “Default role for all users” and “Site home role”. Every logged-in person on your site inherits the capabilities of these roles. So if a risky capability ever creeps in here, you have not handed it to one user, you have handed it to everyone with an account. Open each of these roles (under Define roles) and confirm nothing dangerous is allowed; they should be kept to the bare minimum.

5. Secure cookies

If your site runs on HTTPS, and it absolutely should, the Secure cookies setting tells the browser never to send the session cookie over an unencrypted connection. That closes a real session-hijacking gap. Turn it on once your site is fully HTTPS. (Enabling it on a site still partly served over HTTP can lock users out, so make the HTTPS move first, then set this.)

Make this a habit

These five are the common offenders, but the Security checks report covers more: writable config, the guest role, password policy, antivirus, and others. It re-runs every time you open it, so make a habit of checking it after any upgrade or configuration change. A couple of minutes on this page leaves your site meaningfully harder to attack.

Solin hardens and audits Moodle installations for organizations that take security seriously. Contact us for a security review.