Since 2010, the general level of security of web applications has considerably improved. With the maturity obtained by the web applications sector came a set of improved methods to detect, report and publish security vulnerabilities.

Chamilo has not been idle in all this. Since the first version of Chamilo 1.8.6, we have had one major code review made by a Bulgarian security professional/hacker, then we have had one independent security vulnerabilities report for Chamilo 1.8.7, for which we have provided security patches and have fixed the vulnerabilities in less than 4 days. Some of these vulnerabilities were about a library we use and include inside the Chamilo code, not directly about Chamilo itself.

This also raised our awareness of Security threats caused by crafted data that we thought we were filtering well enough. This means that we are now coding directly paying attention to every new bit of code, to make sure it is appropriately filtereing the data input.

Amongst the most popular security threats in web applications, we find XSS, CSRF, SQL injection and browsers vulnerabilities.

We deal with XSS by filtering any input that is likely to be output on our campus, and removing any dangerous characters string.

CSRF are dealt with by ensuring every form uses a security token that prevents hacking of the form itself for other purposes.

We deal with SQL injection by filtering any data not coming from the database or from the code itself, and passing it through filters for data types and regular SQL filters.

Finally, we deal with browsers vulnerabilities by filtering input data and removing threatening strings.

Since 1.8.7, several independent reviews by security companies have been executed on Chamilo by large institutions using it, and the only issues found were related to server configuration or the ability for teachers to do more than expected in their own courses.

We think Chamilo is now a very secure application in terms of hacking. Course content privacy still has some issues though, and we are working on better ways to prevent unauthorized access for the next versions. Don’t get me wrong, we do protect them through the use of Apache settings, but these are not included by default in Chamilo, which means you data is better protected if you go through our hosting services, so far.

You can find various security reports and security patches information by following the links below

As a general warning, we recommend not to rely on insecure solutions like Dokeos: if patches are not provided by the publisher, then your application *is* insecure. Moodle is not very safe either, as hinted by the number of security issues that appear regularly (and generally take some time to be fixed). Check the Moodle security page if you doubt that.

Although Open Source software solutions like the ones mentioned here might prove to have security flaws, Closed Source solutions are generally considerably worse as they try to hide security flaws behind secrecy, leaving their users affected by serious vulnerabilities, all the while pretending this isn’t the case. Open Source is more sincere and (most of the time) has open processes which allow for review by many eyes.