Insecure published integrations
A published REST, OData or SOAP service puts your microflows and entities on the network. It is the one part of the application that faces outward by design, it skips everything the user interface implicitly protected, and it is regularly the weakest point of an otherwise well-built app.
How this shows up in a Mendix application.
No authentication on sensitive data
The endpoint is open because it was easier during development, and the data behind it is not public.
End-user roles on system integrations
The service is granted to module roles that ordinary users also hold, so anyone who can log in can call the API.
Hand-built authentication
A custom login microflow in place of the platform mechanism, usually without the custom authentication setting that would make it enforceable.
Every role on every operation
Access is granted at the service level and never narrowed per operation, so one endpoint opens all of them.
Import mappings straight into persistent data
Incoming payloads are mapped directly onto persistent entities, without validation and before anything has been checked.
Direct object references in the mapping
Identifiers in the payload point at objects by key, so changing a number in the request reaches somebody else's record.
What it lets someone do.
Every item below has been found in production applications. None of them requires a sophisticated attacker: they require somebody who reads the page source, edits a request or simply logs in.
How to keep it out.
Built-in authentication, dedicated accounts
Mendix password authentication with long random credentials or SSO, on integration accounts with their own roles, not on end-user roles.
Restrict at both levels
Allowed roles on the service and roles per operation, so an open endpoint cannot be used as a door to the rest.
Map to non-persistent first
Land incoming data in non-persistent entities, validate it there, and only then write anything that persists.
What Omnext checks for you.
Omnext lists every published service with its authentication setting, the roles allowed on the service and per operation, and the import mappings that write into persistent entities.
The framework is The S-Unit's.
The S-Unit Top 10 is the work of The S-Unit, the Mendix security specialists. They built it from more than ten years of offensive security work and hundreds of Mendix penetration tests, and they maintain the canonical version. Omnext automates the checks in the Security Analysis module; the framework itself is theirs, and this page explains it in our own words.
Which of the ten are you sure about?
Ten questions, about four minutes, results on screen. Or let the scan answer all ten with evidence from your own model.