Moodle app security

The Moodle app is a hybrid app (uses web-technologies) developed on top of a well-tested widely used framework called "Cordova" that provides a robust container for HTML apps.

Security is very important to us, this is why we follow the Cordova and Moodle security recommendations:

• Cordova: https://cordova.apache.org/docs/en/latest/guide/appdev/security/
• Moodle: https://docs.moodle.org/dev/Security (when developing Web Services)

How we approach security

• Login and authorisation
  • Authorisation is done via temporary access tokens. The duration of the access tokens can be configured via Moodle settings.
  • Single Sign-On (or auto-login) from the app to the site is done using a special private token (that is obtained and stored when the user log-in with the app)
  • Single Sign-On (or auto-login) from the app to the site has several additional restrictions (like limiting it in only several times per hour)
  • QR-Login is done using temporary tokens that require the user to be in the same network (IP address) and it is limited to 10 minutes time
  • For retrieving files from the server (images or other assets), a different non-authentication token is used.

• Permissions
  • The app only has access to a subset of Moodle functionalities (available through the Moodle App Service)
  • Privileges escalation is not possible via the Web Services layer since all the operations are done in a non-privileged way, permissions are checked based on the currently authenticated user.
  • Even if a temporary access token for an admin (or privileged user) was hijacked, it wouldn't be possible for the attacker to access to site administration functionality via the Moodle site.

Because the app is a Webservices client we recommend to enable it only under https and use the following settings to enforce security like:

• Enable only certain roles to be able to access via the app via system capabilities (avoid site administrators)
• Use Moodle security settings to reduce the expiration time of WebService access tokens (so the user has to authenticate again)
• Apart from that, the Cordova framework enforces security adding restrictions like avoiding connecting to sites running non-trusted certificates.

What is the Moodle app security issues process?

• We follow the standard Moodle security process: https://docs.moodle.org/dev/Moodle_security_procedures
• There is only one relevant difference: security patches are applied immediately in the next app release or in an emergency release (depending the risks attached to the issue)

Shared responsibility

• The organisation hosting the Moodle site is also responsible for providing secure access to the Moodle site, the site should be configured to use HTTPS (secure connection) so the connection is app-to-site encrypted.
• Apart from the previous, the Moodle site administrator can enable additional security measures such as enforcing end-to-end encryption for Push notifications via the site administration notification settings.

Do you run security/penetration/pentest or static code analysis tests?

We do occasionally receive automated vulnerability reports of this nature. The issue with automated tools is that they usually output generic results that indicate where an exploit may be possible, which means the results often contain many false positives.

As mentioned above our app is built on top of Cordova, we rely on the Cordova framework developers to detect any native code issue.

You can do a search in the Cordova project tracker to see that several runs with the Static Code Analysis Veracode tool created issues that have been already solved, see: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20text%20~%20%22veracode%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Unfortunately, those Veracode runs are not publicly available because most of the time are run by external parties using the framework.

Please, note also that there are CVE codes for Cordova security issues: https://www.cvedetails.com/product/27153/Apache-Cordova.html?vendor_id=4

Warnings typically raised by static code analysis tools

• Lack of Jailbreak Detection The Moodle app does not include jailbreak or root detection. This is due to the lack of official APIs from Google or Apple, and our testing of existing non-official plugins to support it showed a high rate of false positives, particularly on Android with budget devices or recent iOS updates. Notably, the app securely stores authentication tokens in the keystore/keychain, not in the session. The session token is used only for temporary content retrieval and has limited validity, ensuring that even on compromised devices, attackers cannot extract sensitive data to perform impersonation attacks.
• No Certificate Pinning The Moodle app does not support certificate pinning because it is designed to connect to any Moodle site globally (there are hundreds of thousands of sites, each one with its own URL, using Moodle), whether hosted on HTTPS, HTTP, or local networks. Additionally, the Cordova framework we rely on does not natively support certificate pinning.
• Lack of Encryption for Manifest Files The app does not include sensitive keys or certificates in publicly accessible files, eliminating the need for encryption of manifest files. The Firebase certificates available in the app’s GitHub repository are bound to the app’s fingerprint, ensuring they cannot be exploited.
• Static Web Service Authentication Tokens (Session Fixation) Web service tokens are not regenerated with each login by design. This aligns with how the Moodle Web Services API operates, allowing users to connect across multiple devices (e.g., phone and tablet) without invalidating tokens. Regenerating tokens would restrict multi-device access.
• Lack of Code Obfuscation The Moodle app code is open source. Since no keys or private data are generated during compilation, code obfuscation is not necessary.
• Improper Session Timeout & Logout Function The Moodle app follows a common approach used by most mobile apps on Android and iOS, where users are not prompted to log in repeatedly after short periods of inactivity. Mobile devices provide adequate protection through features such as automatic locking when inactive. However, Moodle site administrators have full control over how the app handles session timeouts and logout behavior. They can:
  • Define how the logout function works (soft logout or complete session termination).
  • Set a custom session timeout duration.
  • Configure the duration of the Web Service authentication token.

These configurations can be managed through:

• • Site administration > Mobile app authentication settings
  • Site administration > Security settings

---

Does this fully address your requirements? Let me know if you'd like further refinements!