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
5. Align session settings with your security requirements
Vulnerabilities within TSU-10
- 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