Runtime Security
How Is Security Handled in a Mendix App?
Before understanding how security is handled in a Mendix application, it is important to understand the Mendix Runtime architecture.
In a Mendix application, the UI layer is implemented in the Mendix Client as JavaScript libraries running in the browser. For native mobile applications, the UI layer is implemented as a JavaScript application bundle running in a React Native application. The logic and data layers are implemented in the Mendix Runtime (the Mendix Runtime itself is developed in Java and runs on a Java virtual machine).
Within the Mendix Client, we implement measures against JavaScript-based security threats such as cross-site scripting. This prevents other websites and web applications running in the same browser from obtaining sensitive information from the Mendix app (for example, cookies).
What is more, the Mendix Runtime addresses server-side security threats, such as SQL injection and code execution. By default, a request originating from any client (including the Mendix Client) is perceived as untrusted.
Mendix app developers do not need to take technical security aspects into consideration when building Mendix apps, as the platform handles this as a service. Of course, this does not mean that developers do not have to consider security at all. Application-level authorization and access rights need to be configured in the application model by the developer. This is because most technical security aspects can be solved generically, while the business rules and requirements that are the prerequisites for access to data can be different for each application and business.
Each operation within the Mendix Runtime is called an “action”. The Mendix Runtime provides many predefined actions, such as triggering and executing workflows and evaluating business rules. To prevent any bypassing of the technical security mechanisms, these actions are implemented at the lowest levels of the Mendix Runtime, and they cannot be changed by app developers.
The core interface of the Mendix Runtime (which is responsible for the execution of any action) has a security matrix that contains all executable actions and data access rules per user role. The data access rules are applied at runtime when a query is sent to the database. This ensures that only data within the boundary of the access rule constraint is retrieved.
How Does My Mendix App Address Common Security Threats Like the OWASP Top 10?
The Mendix Runtime and Mendix Client include built-in security measures that protect applications against a wide range of known threats, including several from the OWASP Top 10—such as SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and broken authentication. These security measures undergo monthly external penetration testing.
The Mendix Runtime and Mendix Client are scanned daily, using the latest technologies in static analysis and software composition analysis offered by industry leaders, to ensure no unmitigated vulnerabilities remain.
How Does Mendix Authenticate System & Service Interfaces Using Web Services, REST Services & APIs?
System and service interfaces require authentication and authorization.
For authentication, Mendix supports the following technical implementations:
- HTTP authentication. Basic authentication using a username and a password would be a default option.
- Web service security standards. Using OAuth Access Tokens ( opaque or JWTs ) is a supported best practice.
- Custom-defined authentication mechanisms including Java.
These options make it possible to apply identity propagation.
When implementing an API with Mendix, Authorization for APIs is derived from the authorizations defined in the application model. The OIDC SSO module can be used to validate OAuth Access Tokens and to assign authorized userroles. Mendix uses same security model for human users (userroles, entity access, etc) and ‘machine identities’. Machine identities can be provisioned on-the-fly, no API-keys or passwords for the consuming client need to be managed in the consumed API.
The Access Tokens can be issued by 3rd party technologies or can be issued by a Mendix solution using the OIDC Provider module. This module can be used to issue Access Tokens to either human identities (SSO) or machine identities.
For example, in a multi-app solution, end users logins at Entra ID and resulting tokens are used to consume APIs. Scheduled jobs make use of a ‘machine’ identity to consume APIs.