Open LMS App – Security Overview

1. Introduction

Open LMS is a hybrid mobile platform designed to deliver seamless, secure, and scalable digital experiences. The application is built on top of Apache Cordova, enabling cross-platform functionality while maintaining strong security standards.

Security is a foundational pillar of Open LMS. Our architecture and development practices prioritize the protection of user data, secure communication, and controlled access to all system resources. We follow modern security principles and continuously evolve our practices as the platform grows.
 

2. Security Philosophy

Open is built around a defense-in-depth strategy, ensuring that multiple layers of security protect the system at all times.

Our approach is guided by the following principles:

• Least privilege access: Users and systems only have access to what is strictly necessary
• Secure by default: All communications and interactions are protected unless explicitly designed otherwise
• Server-side enforcement: Critical security decisions are always validated on the backend
• Transparency and adaptability: We acknowledge limitations and continuously improve

3. Authentication & Authorization

Open LMS uses a token-based authentication model to manage user identity and access.

Authentication

• Users authenticate through secure login flows
• Upon successful login, the system issues a temporary access token
• Tokens are time-bound and can be configured to expire after a defined period
• Tokens are uniquely associated with each device/session

Authorization

• All requests are validated server-side
• Access to resources is determined based on the authenticated user’s role and permissions
• Sensitive operations may require re-validation

Session Behavior

• Sessions are isolated per device
• Multi-device access is supported without compromising token integrity
   

4. Data Protection

Protecting user data is a top priority in Open LMS.

Data in Transit

• All communication between the app and backend services is encrypted using HTTPS
• Unsecured (HTTP) connections are not supported in production environments

Data at Rest

• Sensitive data such as authentication tokens are stored securely using:
  • iOS: Keychain
  • Android: Keystore
• No sensitive credentials are stored in plain text within the application

5. Permissions & Access Control

Open LMS enforces strict access control through a role-based access system (RBAC).

• Users can only access features and data permitted by their role
• All permission checks are enforced server-side
• The client application cannot grant or elevate privileges independently

This ensures that even if a client environment is compromised, unauthorized access cannot be obtained.

6. Backend & API Security

All backend services are designed with security as a primary concern.

API Protection

• All API endpoints require authentication
• Requests are validated and sanitized server-side
• Unauthorized or malformed requests are rejected

Additional Safeguards

• Rate limiting may be applied to prevent abuse
• Logging and monitoring are used to detect suspicious activity
• Sensitive operations are protected with additional validation layers
  
   

7. Mobile Application Security

As a hybrid application built on Apache Cordova, Open LMS follows best practices aligned with modern mobile security standards.

Platform Protections

• The app relies on operating system-level protections such as:
  • Device encryption
  • Automatic screen locking
  • Secure storage APIs

Security Decisions & Trade-offs

Jailbreak / Root Detection

• Not implemented due to lack of reliable official APIs and high false-positive rates
• Mitigation: secure token storage and strict backend validation

Certificate Pinning

• Not enforced due to the flexible nature of connecting to multiple environments
• Mitigation: strict HTTPS enforcement and backend validation

Code Obfuscation

• Not required as no sensitive keys or secrets are embedded in the app

8. Session Management

Open LMS follows a user-friendly but secure session model:

• Users are not required to log in repeatedly during short inactivity periods
• Session duration is controlled via token expiration policies
• Logout behavior can include:
  • Soft logout (local session cleared)
  • Full session termination (token invalidated server-side)

9. Shared Responsibility Model

Security in Open LMS is a shared responsibility between the platform and the organizations using it.

Open LMS Responsibilities

• Secure app architecture
• Safe authentication and token handling
• Protection of backend services

Organization Responsibilities

• Enforcing HTTPS on all endpoints
• Configuring token expiration policies
• Managing user roles and permissions
• Ensuring secure operational practices

10. Security Testing & Maintenance

Open LMS maintains an ongoing commitment to security through:

• Continuous monitoring of dependencies and frameworks
• Application of security patches and updates
• Internal testing of authentication and data flows

• Periodically AI-driven security reviews are conducted with different models and prompts.

11. Known Limitations & Mitigations

We believe transparency strengthens trust. The following considerations apply:

12. Continuous Improvement

Security is not static. Open LMS is committed to:

• Evolving with industry best practices
• Adapting to new threats and vulnerabilities
• Continuously improving architecture and policies

13. Open LMS app code

The code of the application is a fork of the Moodle™ application which is an open source project provided by Moodle™. The foundational source code for this application is derived from a fork of the established Moodle™ platform. Moodle™ is a widely-adopted, open-source learning management system (LMS) that is actively developed and maintained by the global Moodle™ community and Moodle™ Pty Ltd.

This means that while the core architecture, security principles, and much of the underlying functionality are inherited from the robust, peer-reviewed Moodle™ project, this specific application represents a customized and tailored iteration. The decision to base the application on Moodle's™ open-source code provides several key advantages:

1. Community Vetting: The base code benefits from continuous scrutiny and security patching by a vast, worldwide developer and user community, significantly reducing the likelihood of undetected core vulnerabilities.
2. Established Security Practices: Moodle™ adheres to recognized industry standards for web application security, including best practices for authentication, authorization, input validation, and data protection, which are incorporated into the application's foundation.
3. Auditability: The open-source nature of the core platform allows for full transparency and independent security auditing, a critical factor for maintaining trust and compliance.

The forking process involved taking the Moodle™ source code and introducing specific modifications, enhancements, and custom features unique to this application's requirements. Consequently, the maintenance and security strategy involve both tracking and incorporating upstream security updates and patches released by the Moodle™ project, as well as independently managing the security integrity of the proprietary modifications and customizations made within this specific fork.