Insecure custom Java
Custom Java sits underneath the low-code layer, where the platform stops applying authorisation and validation for you. What the model enforces everywhere else becomes the developer's responsibility in this one file, and a single action running in the wrong context can quietly undo the entity access rules the whole application depends on.
How this shows up in a Mendix application.
System or Sudo where User belongs
Running in an elevated context means entity access rules are never evaluated, and nothing in the model shows it.
No check inside the privileged block
The elevated operation performs no authentication or authorisation of its own, because the caller was assumed to be trusted.
XPath built by string assembly
User input concatenated into a query instead of parameterised, which is injection with a different syntax.
Request data taken as given
Values from the URL, body or headers used without validation and without checking whether this caller may ask for this.
HTML assembled by hand
Output built by string concatenation with no encoding, which lands cross-site scripting in the page.
Libraries on default settings
Third-party libraries, XML parsers above all, used without reading their own security guidance.
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.
Use Java only where it is needed
A microflow or a REST integration handles most of what Java gets used for, and it keeps the security model visible.
User context by default
Treat Sudo as the exception, log it, and add an explicit authorisation check wherever it runs.
Parameterise and encode
Placeholders in every XPath query, and a template engine that encodes variables rather than trusting the author.
What Omnext checks for you.
Omnext analyses custom Java alongside the model: context switches, unparameterised queries, unencoded output and request handlers without an authorisation check.
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.