TSU-08: Insecure custom Java

TSU-08 concerns security issues that arise from the unsafe use of custom Java code in Mendix applications. Mendix allows the standard functionality of the platform to be extended with Java code. This can be done, among other things, by:

creating additional Java actions that are invoked from microflows
creating new URL endpoints for integrations with external systems
modifying existing Mendix functionality, such as the login process

Java code requires greater responsibility

Java code runs at a lower technical level than Mendix low-code components, which means more responsibility lies with the developer to implement security measures correctly. This includes, for example:

authentication
authorization
input validation and sanitization

Depending on what the Java code does, errors can lead to:

unauthorized read and write access to data
bypassing authentication mechanisms
in some cases, even direct access to the operating system or the file system

Best practices for safe custom Java in Mendix

When adding custom Java code to a Mendix application, it is important to be familiar with both general web security issues (such as the OWASP Top 10) and how these translate to Mendix and the Mendix Core API.

These best practices help with that:

1. Use Java only where it is truly necessary

Do not use Java code for functionality that can also be built using a microflow or a (REST) integration

2. Correct handling of context (User, System, and Sudo)

If you implement a Java action that is used from an authenticated context:
- avoid using a System context for data and microflow interactions
- use the User context wherever possible, so that user permissions and access rules are correctly enforced
Does the Java code need to perform privileged actions on behalf of a logged-in user?
- then use a Sudo context, so actions can still be traced back to the current user
When Java code uses a Sudo or System context
- implement explicit authentication and authorization checks to prevent unauthorized access to data or microflows

3. Secure processing of request data

When Java code retrieves data from the current request (such as the URL, HTTP body, or headers):

implement explicit validation and authorization checks to prevent injection attacks or unauthorized data access

4. Secure XPath queries

When Java code retrieves data via XPath:

ensure that user input does not influence the structure of the query
use Core.createXPathQuery with placeholders and setVariable

5. Secure HTML-generation

Avoid generating HTML via string concatenation

If Java code must generate HTML, use a template engine that automatically encodes variables and user input

6. Responsible use of third-party libraries

If your Java code uses third-party libraries (for example for XML parsing):

carefully read the library’s documentation
check which security best practices and known pitfalls apply

Vulnerabilities within TSU-08

These are the most common risks associated with insecure custom Java.

Unauthorized access to data due to missing authentication
Unauthorized access to data due to missing authorization in a System or Sudo context
Unauthorized access to data via XPath injection
Authentication bypass via XPath injection
Cross-site scripting due to insecure HTML generation
Cross-site scripting due to missing output encoding
Access to the file system due to unsafe use of XML parsers

Train your Mendix security skills

Recognize and prevent vulnerabilities in Mendix at an early stage? Explore our updated Mendix security trainings based on The S-Unit Top 10.

Integrate The S-Unit Top 10 into your CI/CD pipeline.

Want to know how your Mendix application scores against The S-Unit Top 10? In collaboration with Omnext, we have developed a Mendix-specific SAST solution that continuously and automatically scans for vulnerabilities. By integrating The S-Unit Top 10 into the CI/CD pipeline, risks are identified early and made immediately visible. Learn more about our collaboration with Omnext and the Mendix-specific SAST module.