Insecure cloud deployments
The model can be right and the deployment still wrong. Runtime settings, constants and environment configuration sit outside the app and can undo what it enforces, and the most common way in is not production at all: it is the acceptance environment that shares a secret with it.
How this shows up in a Mendix application.
Marketplace constants left at their defaults
Shipped defaults are public knowledge, and they are the first thing an attacker tries.
One secret across environments
The same security-sensitive constant in test, acceptance and production, so the weakest environment sets the security of the strongest.
Production data outside production
Real data in a non-production database, protected by whatever the test environment happens to have.
Headers and CSP too permissive
Missing security headers, or a content security policy loose enough that an XSS reaches as far as it likes.
Path restrictions only in production
API documentation and internal paths restricted on one environment and open on the next.
Session settings unconsidered
Multi-session, duration and timeout left on whatever the defaults were, regardless of what the application holds.
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.
Unique secrets per environment
Security-sensitive constants and environment variables that differ everywhere, so one environment cannot lend its keys to another.
Hard separation
No production credentials, APIs or data outside production, and anonymised data where test data is needed.
Same restrictions everywhere
Path restrictions, headers and a strict content security policy applied per environment, and checked before each deploy.
What Omnext checks for you.
Deployment configuration sits outside the model, so Omnext reports what it can see from the application side and the rest belongs in your release checklist. It is the one category where automation stops and process takes over.
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.