What Years of Mendix Development and Findings Taught Me to Build

"Entity has no access rules." "Password policy does not meet minimum requirements." "Image missing alternative text."

I've read findings like these in pentest and accessibility reports on more than one Mendix project. None of them were hidden. They were in the model the whole time, and nobody had a systematic way to look.

I've tried to solve this with process more than once: senior developers paired on code reviews, checklists before releases, dedicated security walkthroughs. They help for a while. Then a deadline hits, the senior gets pulled onto something else, the checklist becomes a formality, and a few weeks later there's another report.

I don't think the problem is that Mendix developers don't care about quality. What I kept noticing is that, as far as I know, Studio Pro has nothing that checks for these things while you build. No security linter, no accessibility check, no in-depth static analysis of the model.

So I started building something. This post is what it is, how we're piloting it, and where it stops. Whether it's useful is for you to judge.

What I built

It's called MxGuard, and it's a Studio Pro extension. You open it from the menu, it docks next to your model like any other pane, and you click Run Scan.

No CLI. No external tool. Everything runs locally, and your model never leaves your machine.

What comes back is a prioritised list of findings, grouped by severity, each with a plain description of what's wrong and what to do about it. Click the arrow on a finding and Studio Pro jumps to the microflow, page or element inside a page that caused it. For entity findings it opens the module's domain model.

The summary cards at the top double as filters. Click "Critical" and the list narrows to Critical. It's a small thing, but it makes a long list easier to work through.

The security checks

Mendix's security model is powerful, but it's opt-in at every layer: access rules per entity, per role, per attribute, security level set to Production, roles on every page. Miss one step and there's a gap, whether or not anyone knows about it.

MxGuard turns some of the most common gaps into rules that run on every scan. These are the ones I've seen most often:

· An entity with no access rules (Critical). Someone creates an entity, wires it to a page, moves on. In development, with security off or on prototype, everything works. It stays that way until Production security is switched on, or until the report arrives.

· Access rules that grant ReadWrite by default (Critical). The rule exists, but it's the default one nobody customised, so every attribute is editable by whoever holds the role.

· Sensitive attributes exposed (High). Anything named like a password, token, API key or secret that a role can read or write.

· Full CRUD with no XPath constraint (High). Every user in that role can reach every record in the table.

· Project security not set to Production (Critical). Easy to do when you lower it to debug something and forget to put it back.

· Pages with no allowed roles (Medium), guest access enabled, weak password policy, and sensitive constants with a hardcoded default value in the model.

The accessibility checks

Accessibility is the one I've seen skipped most often, usually until an audit or a legal requirement forces the issue and a lot of pages need rework.

The same scan covers it at model level, before you deploy: images without alternative text, inputs with no label (including inputs that only have a placeholder), buttons with no caption, pages with no title, positive tab indexes that break keyboard order, data containers without an accessible name, and a few more.

These are common failures in web applications in general, and a visual platform can make them easy to miss.

Scan your code, not the Marketplace's

Real projects aren't just your code. They include system modules, Atlas, and whatever came from the Marketplace for charts, PDFs or email. You usually can't fix those, so a report full of them is noise.

By default MxGuard skips system modules and detects Marketplace modules automatically, so only the modules you own are scanned. If you forked one and it's yours now, toggle it back in. The choice persists across sessions.

The part I actually care about: what the model can't tell you

Everything above reads the model. It's fast and needs no running app, but it can only see what the model says. Some things only show up at runtime: what a logged-in user can actually reach, and what the browser actually renders.

So there's a runtime scan too. Click Runtime Scan, enter your app's URL (localhost by default) and click Copy Script & Open App. MxGuard generates a script, copies it, and opens your app. You log in, paste the script into the browser console and run it. The scan runs as whichever user you're logged in as.

When it finishes, the findings come back into the Studio Pro dashboard, marked as runtime findings. The full report, with the access matrix, the data explorer and the export, is rendered in the browser page you ran the script on.

It looks at three areas:

· Security. It builds a CRUD access matrix for the logged-in user: for every entity, can this user read it, write it, create it, delete it? It also checks whether the anonymous session is active, whether /rest-doc and /ws-doc are exposed, whether System entities are readable, and whether sensitive attributes are reachable.

· Accessibility, on the real page. The things the model can't show: computed color contrast, ARIA roles and required properties, landmarks, focus traps, suppressed focus outlines, touch target sizes, duplicate IDs, ambiguous link text.

· Code review. Naming conventions, entities with a lot of attributes, deep inheritance chains, bidirectional references, enums with generic keys, orphaned and empty entities.

The code review checks only exist in the runtime scan on purpose. Some things can't be tested without a running app, and the static side is limited to what the Mendix APIs make available.

From the report in the browser you can export the results as HTML or JSON.

There's one more piece in the access matrix. You can click an entity to see its live data, and where the logged-in user has write access, edit cells in place (with a confirmation before anything is saved). I added it because seeing "this role can edit this column" on screen makes the point faster than a finding card does.

How we intend to pilot it with my team

This is the reason I built it, and it's what we're doing right now in a pilot:

Before committing a revision, the developer runs a scan. Critical findings get fixed first.
High findings get fixed or explained in the commit description. "Intentional, and here's why" is a perfectly good answer.
Before a release, someone runs the runtime scan on a test environment, once per role. The scan reflects whoever is logged in, so an admin scan says nothing about what a regular user can do.
The reviewer's time can then go to architecture and logic instead of "you forgot access rules on this entity."

It doesn't replace the review. The idea is that the review doesn't have to start with the obvious things.

What you still have to do yourself

· It isn't a pentest. A skilled security engineer will find things it never will.

· The static scan reads the model, not the behaviour of a deployed app. That's what the runtime scan is for, and it only sees what the user you're logged in as can see.

· Some checks are heuristics. A "sensitive attribute" is detected by name, and naming rules are opinions. Expect some false positives, and treat the output as a to-do list, not a verdict.

· The runtime scan is for development and test environments only. It is not read-only. Its permission tests and the data explorer can change data directly in the database. Don't point it at production.

· You paste a script into your browser console. My advice is the same as for any script: read it first.

· It's early (version 0.1.0). It needs Studio Pro 10.24 or newer, and I've tested it on 10.24 (Dojo and React clients) and 11.12.

Try it

For now MxGuard is Siemens-internal, and you can get it from the Siemens Marketplace.

If you're a Mendix developer at Siemens, run a scan on the project you're working on and see what it finds. Whether it's useful for your team is your call, and I'd like to hear it either way: what it catches, what it misses, what's just noise. If there's a check you do by hand on every project, tell me. It might already be in there, or it could be.

If you'd like to know more, feel free to send me a message! Happy coding :D

Contents