Hoe gaat Moodle om met OWASP top 10 bedreigingen?

  • Moodle blog
  • >
  • Hoe gaat Moodle om met OWASP top 10 bedreigingen?

Toegenomen focus op veiligheid en privacy

De laatste jaren is de focus op veiligheid en privacy sterk toegenomen. Uiteraard heeft de invoering van de AVG in mei 2018 daar flink aan bijgedragen. Ook in offertetrajecten en aanbestedingen wordt steeds vaker de vraag gesteld hoe wij omgaan met veiligheid en privacy. Een terechte vraag want ook wij vinden het een bijzonder belangrijk thema en willen niet dat data van onze klanten op straat komt te liggen. Twee hoofdvragen komen steeds terug: 

  1. Hoe heeft de Moodle dienstverlener de veiligheid en privacy georganiseerd?
  2. Hoe veilig is de applicatie (Moodle) zelf?


In deze blog wil ik ingaan op de veiligheidsmaatregelen die Moodle zelf heeft genomen. Voor ons als Avetica beperk ik mij tot het feit dat wij een ISO 27001 certificaat hebben en een ISAE 3000 type II rapportage. In een eerdere serie blogs lees je nog meer over de privacy en de informatiebeveiliging in Moodle.

Top 10 van OWASP

De stichting Open Web Application Security Project® (OWASP) heeft als missie de verbetering van de veiligheid van software. In 2013 hebben zij een eerste top 10 gepubliceerd van de grootste en meest voorkomende risico’s binnen webapplicaties. Eind 2017 is de lijst geactualiseerd. Deze top 10 is een belangrijk hulpmiddel voor webontwikkelaars om kwetsbaarheden te identificeren en te voorkomen.

De top 10 van bedreigingen

  1. Injectie van commando’s
  2. Authenticatie fouten
  3. Kwetsbaarheid van gevoelige data
  4. Externe XML-entiteiten
  5. Falende controle op rollen en rechten
  6. Configuratiefouten
  7. Cross-site scripting (XSS)
  8. Onveilige serialisatie
  9. Software zoals libraries en frameworks met (bekende) kwetsbaarheden
  10. Onvoldoende logging en monitoring


Voor een gemiddelde Moodelaar zijn de meeste punten abracadabra. Voor een Moodle software ontwikkelaar moet dit gesneden koek zijn. 

Wat doet Moodle?

Veiligheidsrisico’s beslaan een zeer breed gebied maar er zijn drie belangrijke onderwerpen die een goed overzicht geven van hoe Moodle dergelijke risico’s beperkt.

1. Inbedden van beveiliging in de ontwikkelingsprocessen

Het ontwikkelproces van Moodle software omvat meerdere stadia van peer reviewing en testen. Bij het testen wordt niet alleen gecontroleerd of de dingen werken zoals bedoeld, maar ook of er geen beveiligingslekken zijn ingeslopen tijdens de ontwikkeling. Dit is een van de gedocumenteerde punten van de checklist voor collegiale toetsing.

Zie de documentatie over informatiebeveiliging en het ontwikkelingsproces.

2. Informatie delen aan sitebeheerders van Moodle 

Moodle heeft uitgebreide documentatie  geschreven met aanbevelingen voor sitebeheerders om hun Moodle site veilig te configureren zodat beveiligingsrisico’s verminderd of geëlimineerd worden. 

Zie de documentatie met beveiligingsaanbevelingen en onze eerder genoemde serie blogs hierover.

3. Procedure omgaan met ontdekte risico’s en kwetsbaarheden 

Moodle heeft een uitgebreide set aan procedures opgesteld hoe ze omgaan met meldingen van beveiligingsproblemen. Belangrijk onderdeel is de Moodle Tracker waar alle meldingen centraal worden geregistreerd en waar de community van Moodle ook toegang toe heeft. Ook is er een speciaal formulier om beveiligingsprobleem te rapporteren.

Zie de documentatie over Vulnerability Disclosure Program van Moodle.

Moodle community

Elke applicatie bevat fouten en moet onderhouden worden en dat geldt ook voor Moodle. Het feit dat de applicatie open source is betekent dat alle ontwikkelaars wereldwijd alle code kunnen zien. Eventuele fouten en onveiligheden kunnen zo sneller ontdekt en gerapporteerd worden. Hierin zie je de kracht van de Moodle community.

Blijf op de hoogte

Vul je e-mailadres in en lees als eerste onze blogs over Moodle.

Voeg je bij 69 andere abonnees