TSU-04: Insecure published integrations

TSU-04 focuses on insecurely configured or implemented Published Integrations. Ensure that authentication, authorization, and validation are applied consistently, and that only trusted systems have access. This prevents your API integrations from becoming the weak spot of your Mendix app.

Published integrations: a key link and a potential target

Published Integrations are the main way Mendix exposes microflows and entities to external systems through standard API formats such as SOAP, REST, or OData. They act as the bridge between your Mendix app and other services.

Typical use cases include:

Providing data interaction for internal applications
Exchanging information with (semi-)trusted third-party systems
Acting as service endpoints within Single Sign-On (SSO) solutions Single Sign-On-oplossingen.

Because these integrations often serve trusted systems, they frequently handle sensitive data and sometimes rely on custom authentication or authorization mechanisms. If a Published Integration is configured or implemented incorrectly, it can result in unauthorized access to data or functionality, or allow external parties to bypass intended restrictions.

Reduce risks by designing your microflows smartly and securely.

To prevent TSU-04 vulnerabilities, ensure that only trusted systems can access your integrations. Limit privileges at two levels:

On the integration level (allowed roles)
On the level of individual microflows or entities exposed through the integration

Follow these best practices:

Avoid using the “no authentication” option unless every operation truly exposes public data or functionality.
Do not assign integration access to module roles used by regular users. Use dedicated integration accounts with specific module roles.
Avoid building your own authentication logic. Use the built-in Mendix password authentication with strong, randomly generated passwords.
If custom authentication is necessary, choose an actively maintained and security-tested Marketplace module rather than developing your own.
When using custom authentication, select the “custom authentication” option instead of combining “no authentication” with per-operation checks. This ensures consistency and reliability
If an integration includes multiple allowed roles (for example, for partners with varying trust levels), grant each microflow access only to the role that truly requires it. Avoid duplicating all roles across every operation.
When using Import Mappings to process user input, make sure they cannot violate data restrictions. Do not map input directly to persistent entities. This may cause data exposure or manipulation. Instead, map to non-persistent entities, validate attributes, and only then interact with persistent data.

Vulnerabilities within TSU-04

The following vulnerabilities commonly occur within this category:

Missing authentication on sensitive integrations: external parties gain access to confidential data.
User access to integration endpoints: regular users can call APIs meant only for systems.
Incorrect module role assigned to an operation microflow: resulting in excessive privileges.
Insecure custom authentication microflows: self-built authentication logic often lacks proper validation or logging.
Data manipulation through import mapping: unvalidated input is stored or altered directly.
Direct object references in import mapping: users can manipulate object IDs to access unauthorized data.

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

Want to know how your Mendix application scores on The S-Unit Top 10? In collaboration with Omnext, we’ve 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 detected early and made immediately visible. For questions, feel free to contact us.