The S-Unit Top 10
TSU-10: Insecure cloud deployments
TSU-10 covers all vulnerabilities related to the cloud configuration of a Mendix application. When a Mendix application is deployed in the cloud, there are various cloud-specific settings that impact the security of the application. These include, for example:
the values of application constants
enabling or disabling scheduled events
the configuration of HTTP headers
access restrictions based on IP address or URL path
custom runtime settings
custom environment variables
Consequences of incorrect cloud deployment settings
For some settings, Mendix provides secure default values that can unintentionally be overridden by developers with insecure ones. For other settings, the default values are deliberately permissive, while your application may not be able to handle that.
In both cases, incorrect settings can result in an unnecessarily large attack surface or even the bypassing of intended security measures.
Best practices for secure cloud deployments
When deploying an application to the cloud, ensure that the cloud configuration aligns with the security requirements of your application.
If these requirements differ per environment (for example test, acceptance, and production), it is necessary to use environment-specific configurations.
The following best practices help prevent vulnerabilities:
1. Use unique security-sensitive settings per environment
Ensure that security-related constants and environment variables are unique per cloud environment.
This prevents an attacker from pivoting from a less sensitive environment (such as test) into a sensitive one (such as production).
2. Strictly separate production and non-production environments
Non-production environments must not have access to production data or production services. This means:
Do not use production APIs or production credentials in test and acceptance environments; instead, use test, acceptance, or mock APIs.
Do not use real production data in non-production databases; use test data or properly anonymized data instead.
3. Consistently restrict access to API documentation
If you use path-based access restrictions for API documentation (the default in production on Mendix Cloud), make sure these restrictions also apply in non-production environments.
If documentation needs to be available to external parties in a specific environment, use IP whitelisting or certificate-based access so that only authorized parties can gain access.
4. Enforce a strict Content Security Policy
Adjust the HTTP header configuration of your environment to enforce a strict Content Security Policy (CSP). This helps limit the impact of, among other things, Cross-Site Scripting.
5. Align session settings with your security requirements
Check whether session settings, such as allowing multiple sessions per user, session duration, and time-outs, match the level of security your application requires.
Vulnerabilities within TSU-10
These are the most common risks associated with insecure cloud deployments.
-
Bypassing authentication or authorization due to unchanged default constant values in Marketplace modules
-
Horizontal escalation between test/acceptance and production environments caused by reusing the same constant values
-
Exposure of production data in non-production environments
-
Bypassing path-based access restrictions via non-production environments
-
Increased impact of Cross-Site Scripting due to an insecurely configured Content Security Policy
Train your Mendix security skills
Want to identify and prevent vulnerabilities in Mendix at an early stage? Take a look at our renewed 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.
