Skip to Content
SécuritéPartie 11 — Sécurité Moodle & LMSVue d'ensemble

Partie 11 — Sécurité Moodle & LMS

⏱️ TL;DRMoodle est un LMS PHP massivement déployé qui manipule des données sensibles d’apprenants — une cible et un enjeu RGPD majeurs. Bonne nouvelle : Moodle fournit des API sécurisées qu’il faut utiliser (et ne pas contourner). L’autorisation passe par les rôles & capabilities (require_login(), require_capability(), has_capability()) — l’équivalent Moodle des voters (Partie 9). Le CSRF est géré par le jeton sesskey. Les requêtes passent par l’API $DB (paramétrée → pas de SQLi), l’affichage par format_string()/s() (anti-XSS), la validation par clean_param(). Les risques majeurs : plugins tiers mal codés, mises à jour en retard, et un config.php/hébergement mal durcis. Les principes des Parties 5-9 s’appliquent, avec les API Moodle.

Le problème qu’on résout

Beaucoup de développeurs web croisent Moodle sans le connaître en profondeur : on installe des plugins, on personnalise un thème, parfois on développe un module. Or Moodle a ses propres API de sécurité, et la plupart des failles viennent de code (souvent de plugins tiers) qui les ignore : une requête SQL concaténée au lieu de $DB, un affichage non échappé, une action sans require_capability() ni sesskey. Ajoute une instance non mise à jour ou un config.php exposé, et une plateforme entière d’apprenants est en danger.

Cette partie applique tout le cours à Moodle (et, plus largement, aux LMS/CMS PHP comme WordPress, cf. le cours WordPress) : utiliser les bonnes API, gérer les plugins, durcir l’instance.

Ce que tu sauras faire à la fin de cette partie

  • Utiliser le système de rôles & capabilities de Moodle pour l’autorisation (require_login, require_capability).
  • Protéger les actions avec le jeton sesskey (CSRF) et requêter via l’API $DB paramétrée.
  • Afficher sans XSS (format_string, s(), clean_param) et valider les entrées.
  • Gérer le risque des plugins tiers et l’importance des mises à jour.
  • Durcir config.php, les permissions de fichiers et l’hébergement d’un Moodle.

Les chapitres

#ChapitreEn un mot
11.1Rôles & capabilitiesL’autorisation Moodle : contextes, capabilities, require_capability.
11.2sesskey, $DB & formulairesCSRF (sesskey), requêtes paramétrées, échappement de sortie.
11.3Plugins tiers & mises à jourLa surface d’attaque n°1 : plugins, MAJ, hygiène.
11.4Durcir config.php & donnéesConfig, permissions, données élèves, lien RGPD.

Après les stacks applicatifs, on industrialise la sécurité : la Partie 12 — Dépendances & supply chain.


On commence par l’autorisation Moodle : Rôles & capabilities.

Last updated on