Partie 11 — Sécurité Moodle & LMS
⏱️ TL;DR — Moodle 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 jetonsesskey. Les requêtes passent par l’API$DB(paramétrée → pas de SQLi), l’affichage parformat_string()/s()(anti-XSS), la validation parclean_param(). Les risques majeurs : plugins tiers mal codés, mises à jour en retard, et unconfig.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$DBparamé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
| # | Chapitre | En un mot |
|---|---|---|
| 11.1 | Rôles & capabilities | L’autorisation Moodle : contextes, capabilities, require_capability. |
| 11.2 | sesskey, $DB & formulaires | CSRF (sesskey), requêtes paramétrées, échappement de sortie. |
| 11.3 | Plugins tiers & mises à jour | La surface d’attaque n°1 : plugins, MAJ, hygiène. |
| 11.4 | Durcir config.php & données | Config, 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.