Can’t Mendix applications with anonymous users be safe? Of course they can, but the attack surface is much bigger, since for every microflow, entity and page you have to determine what access is granted to the Anonymous User. This is acknowledged by Mendix:

Sure, if you need a web portal application, you do require Anonymous Users to use your application, but most applications simply don’t. Why grant the whole world a Mendix session in your application before any authentication took place?

When configuring entity access, we know that granting access is as easy as ticking a checkbox. Experience shows that access to data is granted too easily for Anonymous Users in the same way. When this concerns sensitive data and gets deployed, you could have a serious data breach, exploitable for everybody. For sure, in the development process you always need to review changes, but it can slip through. Strong security always relies on multiple layers of defence to lower the risk if one layer is broken or breached.

Before explaining how the login process works and how one should implement SSO without anonymous users, let me first illustrate the layers of security I want to highlight.

In my illustration, I show three important layers of security I want every Mendix developer to consider.

• The first layer is using a private network: if your Mendix application is only accessible from your internal network, this gives a huge security benefit, as this narrows the attack surface drastically. This requires having an internal infrastructure, including the capability to maintain this properly, which not every company has or is willing to have.
• The second layer is about allowing Anonymous Users, a setting which is turned off by default, and often turned on for simplicity reasons. Hopefully you know by the end of this blog post why you should always try to keep it turned off.
• The third layer is having SSO implemented together with a module that blocks Mendix logins. Having SSO implemented is great, having MFA configured in your Identity Provider is even better, and having the local Mendix Login disabled is the best, as the (weak) passwords of local users are out of the equation.

As the second layer of security is actionable for most developers, I want to focus on how we can avoid using Anonymous Users without detracting the user experience of the login process. Let’s deep dive into the login process!

How the login process works

Unfortunately, the Mendix documentation is somewhat lacking on the inner workings: the login process is not clearly written out, while you do want to make some modifications when implementing some form of SSO. On the OIDC documentation page there are no instructions at all how to configure this without Anonymous Users. In the SAML and Mendix SSO documentation there are some hints and options described, but it’s missing clear instructions. That doesn’t really help for us developers to build secure apps.

So how does the login process work exactly? First, the browser retrieves all static files like index.html, mxui.js, theme.compiled.css, then it starts the Mendix Client Javascript, which tries to retrieve the session data. If Anonymous Users are enabled, this always succeeds and creates a new user and new session if none exists. If Anonymous Users are not enabled, this fails and a 401 Unauthorized is returned. This “error” is caught by the Mendix Client and redirects the browser to the login page. As you can see in the GIF below: first the static files are load, then the Network shows a 401 for the /xas/ endpoint, which triggers navigation to /login.html.

Now the magic redirect to /login.html makes you wonder where that knowledge is coming from and more importantly: how we can manipulate that.

In the index.html file, a small inline code block of JavaScript is written to set the ‘originURI’ cookie. This code is run once on load of the landing page and is used when authorization fails. By default Mendix sets this to /login.html, and this is the configuration we can adjust to our needs:

• If you just want to use Mendix login functionality without any Single Sign On functionality, I recommend to use the default login.html page. You can personalize this using HTML and (S)CSS in the theme/web folder.
• If you do provide SSO, but don’t require users to be automatically redirected to SSO, I also recommend to use the login.html and add a button to navigate the SSO sign-in endpoint and optionally hide the input boxes for username and password. This could be inconvenient because of the extra click needed.
• If you (only) provide SSO and logging in should happen automatically, i.e. the SSO page being the landing page, I recommend creating or updating the index.html file in the theme/web folder as described in next section. This is the most convenient way for users as it does not require extra clicks.

How to configure your login flow

If you run your application locally, the deployment folder contains a web folder, showing all the static files which are served. It also includes an index-example.html file, which you can use as a base for your custom index.html file.

If your index.html has a script referring to DojoConfig, you are using an older (Dojo) framework. If possible, I would recommend switching to the Migration mode for React client, such that migrating to React in the future doesn’t require you to change the index file again. If it has script referring to dist/index.js, you are running the latest (React) framework. Both scripts are very similar and interchangeable in most cases as long as you don’t run the application on a sub path, i.e. domain/my-app.

Copy this index-example.html file to the theme/web folder and we can start the adjustments to our needs. We can start by setting a custom HTML title and the main language of your app. To manipulate the login flow, we need to adjust the script where the originURI cookie is set, which looks like this:

<script>  
if (!document.cookie || !document.cookie.match(/(^|;) *originURI=/gi)) {
    const url = new URL(window.location.href);
    const subPath = url.pathname.substring(0, url.pathname.lastIndexOf("/"));
    document.cookie = `originURI=${subPath}/login.html${window.location.protocol === "https:" ? ";SameSite=None;Secure" : ""}`;
}
</script>

The first line is to prevent overwriting the login landing page, which is only of interest if you have multiple ways of logging in. My advice: drop it, as otherwise your changes won’t reflect after deployment until the existing cookie is expired or removed. If you do want to serve the login.html page for some environments without SSO setup, for example localhost, you could add a check based on the URL, but I rather advise to have SSO configured for running all environments. Anyways, you can change it to something like this to have a readable, functional, and safe implementation to redirect directly to your SSO login page:

<script>  
  const url = new URL(window.location.href);
  const subPath = url.pathname.substring(0, url.pathname.lastIndexOf("/"));
  let newCookie = `originURI=${subPath}`
  newCookie += "/oauth/v2/login" //JF26: this triggers the login procedure of the OIDC module, may require update for your module of single signon
  if (window.location.hash != "") {
    newCookie += "?cont="+window.location.hash.replace("#", "p"); //JF26: this stores the requested deeplink for the OIDC module, may require update for your module of single signon
  }
  if (window.location.protocol === "https:")
    newCookie += ";SameSite=None;Secure";
  document.cookie = newCookie;
</script>

Once you’re ready, double check if you stored the file in the app-main/theme/web folder, and the file contains substitution variables like {{unsupportedbrowser}} and {{cachebust}} to confirm it’s correctly copied from index-example.html. Now you’re ready to go!

Security to the max

If you want to maximize security, you want to avoid inline JavaScript and enforce this via the Content Security Policy (CSP) header. In that case you can put the script in a separate file referred to by the index.html file, such that you can configure the CSP HTTP Header without allowing unsafe-inline scripts. Or if you can manipulate the HTTP Headers via the infrastructure: let the webserver (NGINX for example) add the login page as Set-Cookie header.

When deviation from the happy flow occurs

Depending on which SSO module and Identity Provider you use, the authentication or authorization can fail. Don’t forget to test these situations and provide clear instructions on error pages how users can address their issues. You can for example create a static unauthorized.html file and redirect users in the SSO module when they are successfully authenticated, but don’t have the right authorization.

Conclusion

In this blog post I showed the security impact of the Anonymous Users feature in Mendix apps. Hopefully I convinced you that it is one of the 3 important lines of defence in your Mendix application Security and should be disabled whenever possible. I was happy to share how the login process works and hopefully empowered you to develop your own index.html to redirect users to your SSO provider. Let me know in the comments whether you are able to implement it!

Vulnerability: TSU-07: Insecure custom authentication
Application: https://patientportal2025.mendixctf.com/
Reality check: Developing custom authentication is like building your own house: doable if you’re equiped for it, otherwise, use prefab or let others do it. Both straw houses and well build prefab houses can be found in the marketplace, make sure you use the thoroughly tested modules!

This challenge provides an module mpk and an example of an expired access token. This looks like some broken JWT…

An expired token for Patient Exporter I
eyJwaWQiOiAiUDAwNDIiLCJleHBpcmF0aW9uIjogMTc1NzQyMTQ0OTExN30=.9o16oqcvWYatAwLF5gf0dsPW3hke4fAC6mH/G9IBwKE=

Let’s first inspect this by base64 decoding it 🕵️:

{"pid": "P0042","expiration": 1757421449117}

Alright, that’s something, but indeed no JWT. And that second part is binary, it doesn’t give readable text, so is probably some signature. Now let’s continue the investigation loading the module in an app, hopefully without too much errors! 🫣

In the module, we see 3 folders: ‘Authentication’ and ‘Operations’ contain logic and REST, containing a published REST service. Quick check the only operation served should be on https://patientportal2025.mendixctf.com/rest/patientexport/v1/patient/export ✅ Check, it gives a 401 in my browser. So if we manage to supply some valid authentication, we hopefully can use Postman to export a flag ehh, eleet patient using the query parameter patient=31337. 😁

Let’s fix the 12 errors by creating a Portal module with Partner and Patient entities and importing the CommunityCommons module from the marketplace. ⌛ Alright, that’s fixed!

Now focus on the SUB_ValidateAuthToken flow, as that’s the authentication flow selected in the Published REST Service 🔎

The token is extracted from the HTTP Header, the payload is extracted from the token, the expiry is checked to be in the future, a PartnerKey is retrieved from database by a provided PartnerId and then the SharedKey is used to generate a signature for the payload, which then is checked to equal the provided signature. Then the linked Partner is returned as user to execute the operation. Seems all 200 OK 🟢.

Ow, wait: the match of signatures is not done by checking if the strings are equal, but with a isMatch function, and we know that that’s an regex function. Would that be exploitable? 🤩

Yeah, it looks like it: the signature provided by the API user is used as the regular expression! So let’s try to construct a token with .* as signature to always have a match. 🕺 As payload we use PartnerId P0042, as we know this is used before and some expiry date in the future which uses apparently the milliseconds notation:

{"pid": "P0042","expiration": 1767169361000} 

Basing this 64 together, we’re gonna try:

eyJwaWQiOiAiUDAwNDIiLCJleHBpcmF0aW9uIjogMTc2NzE2OTM2MTAwMH0=..*

And there we have another flag! 🚩 Gooooo Valcon Hackers 🕵️

As mentioned in the reality check: whenever possible, use hardened modules for authentication, like OIDC and SAML, as these are pentested regularly. As soon as the bug of the provided challenge is exposed, it’s a security thread, so one could also argue that keeping your authentication logic should be kept secret, but maintaining these custom authentication modules for every app separately is definitly something you don’t want without using the (private) marketplace. Make sure you let this review thoroughly by a knowledgeable colleague or via a pentest! 🎯

Vulnerability: TSU-03: Insecure microflows
Application: https://patientportal2025.mendixctf.com/
Reality check: Too often, minimal or no validation is applied in the ‘actual’ microflow, this has a very high likelihood in production environments.

The challenge text clearly steers us towards the “My Prescriptions” page where we can order drugs we have prescriptions for. Opening the page for the ‘Obecalb’ drug gives a pop-up to edit update the ‘Preferred Dose’ value and the ‘Next fill’ date:

As always, let’s do some exploratory testing and try what happens if you enter some values and dates. Just starting with an empty date, let’s try varying the dose: 💊

• More than maximum: before I can hit the button, an on change event has reset the dose to the previous value
• Normal, exactly the maximum, negative and zero values: seems to be processed normally, an info message confirms ‘Your prescription has been updated and can be retrieved from the chosen date.’
• Empty: results into an technical error (we found a bug, but it doens’t do much more)

Also playing with the date doens’t get us some ‘Obecalp’ sooner: 🗓️

• Entering a date before 14 days in the future: before I can hit the button, an on change event has reset the date to the previous value
• Empty and any date in 2 weeks: seems to be processed normally

So what would be the goal? We see that ‘Obecalp’ is the reverse of placebo, so maybe we want a more effective drug instead? 🤷‍♂ ️Is the read-only display maybe just front-end? Let’s see if we get the readonly in our network or if we can mess around with it. ⌨️

When inspecting the network traffic, we see a lot of different operationId’s:

• cSTZ… is the data source microflow for My Prescriptions
• WNQ1… is the validation microflow for the Preferred Dose
• HQpl… is the validation microflow for the Refill Date
• Cm//… is the ‘Fill prescription’ button
• ifrO… is the Cancel button (same as close pop-up)

Looking at the response of the data source microflow: the association is not marked as readonly, only the Code of the referred drug, right?

Unfortunately, this was a waste of time, because when you properly get all the attributes using mx.data.get, the association to the drug is readonly after all. 😐

It’s time to put Burp into action and let’s start by intercepting the traffic. Maybe we can drop the validation on Dose, as this 13.36 amount is screaming to be overfilled. Let’s try to make this 13.37, as this should leet to something! 🛎️🛎️🛎️️️

OK: intercepted the call to WNQ1, dropped it and clicked away the error, now let’s try to order! Technically, this will result in a call to CM// including a part with ‘changes’ in the request.

Ah no, it’s still validated! We found out that the order flow also validates the dose, how can be bypass that? During the CTF, I did some digging around the Next Fill date, but without any luck. The hint we finally got during the CTF is to look again to all the operations. So we took a better look at the untouched 2 operations: cancel and validation, there must be something there! 🕵️

Let’s redo what we just did: drop the call triggering the dose validation and then trigger the other operations, first the Cancel: maybe it doesn’t really cancel?

No, it really resets the Dose value, back to it’s committed value.

The validation of the Date? How would that work? Anyways, again: drop the call triggering the dose validation and then trigger the date validation. Hey, that looks nice: our 13.37 seems committed, maybe that helps?! 🤩

Can we order this prescription? Yes, we can and we find the flag! 🚩Gooooo Valcon Hackers 🕵️

So what was happening? Why did the validation flow only trigger the first time and not the second? 🤔 The only difference was that the changes were committed, so apparently the Order flow only executed the validation when the attribute was changed. It seems ok to only validate changed attributes, but as it turns out: it may be unsafe! ⚠️

How to prevent situations like this in your development:

• Always validate input for flows which can be called by the client, just reuse the (partial) validation flows triggered in on change flows.
• Don’t assume validations have taken place earlier in the process, preferably do double validations then the possibility to bypass them!
• If possible, avoid committing the full object after partial validation.

For us, this was quite a challenge! Did you manage to solve it? Don’t forget to check if your validations cannot be bypassed! 💡

Vulnerability: TSU-09: Insecure UI Components
Application: https://patientportal2025.mendixctf.com/
Reality check: Unused microflows which are (still) available for users is very common and developers should definitely check this regurlarly.

As we saw in the Fiscal Life Support challenge, the first /xas/ request is to get_session_data and this returns a lot of valuable data. Let’s inspect the microflows hidden in there! 🕵️

For applications without anonymous users (I always recommend to disable anonymous users whenever possible), the first /xas/ request returns a 401 Unauthorized response. This 401 is handled to navigate the user to the originURI, a cookie telling where to login, by default at /login.html.
Just after succesful login the get_session_data will again be fired towards /xas/ returning the valuable data for your role(s).

In our case the application allows anonymous users, so the /xas/ response returns the session data, and scanning through that huge response, we find from line 2167 a list of microflows in a special format: 📃

    " microflows ": {
        "{\"a\":[],\"p\":[\"Portal.Doctor\"]}": "RLV22MuV1lKyNXb6P7skxA",
        "{\"a\":[[\"Portal.Prescription_Drug\",\"Portal.Prescription\"],[\"Portal.Prescription_Patient\",\"Portal.Patient\"],[\"Portal.Prescription_Patient\",\"Portal.Prescription\"],[\"Portal.Prescription_Drug\",\"Portal.Drug\"]],\"p\":[\"Portal.Prescription\"]}": "WNQ1syd+uViq0xVlNY1LaQ",
        "{\"a\":[],\"p\":[\"Administration.Account\"]}": "GuVxpf6dSleq/eoTRqzDWQ",
        "{\"a\":[],\"p\":[\"System.FileDocument\"]}": "lzxQG0GrbluQH/8ctDV9Bg",
        "{\"a\":[[\"Portal.Prescription_Patient\",\"Portal.Patient\"],[\"Portal.Prescription_Patient\",\"Portal.Prescription\"],[\"Portal.Prescription_Drug\",\"Portal.Drug\"],[\"Portal.Prescription_Drug\",\"Portal.Prescription\"]],\"p\":[\"Portal.Prescription\"]}": "HQpl+c5/ZV6mNfULUmJzRg,Cm//EjKFy1ebyWMUgehf4w",
        "{\"a\":[],\"p\":[\"Portal.Document\"]}": "wQuDuG4/N1uvnet+70S7hw",
        "{\"a\":[],\"p\":[]}": "sEmr/aO5tlm4cS8t54h6Eg,mipcOCQUxVeI3F4I20YtCA,7Xpa+yKV+1e1H+TF38wilQ,iANWNVJEcl6jvPDhzmWNKQ,WvzxrypJTFqEvTpiuPFUXA",
        "{\"a\":[[\"Administration.AccountPasswordData_Account\",\"Administration.AccountPasswordData\"],[\"Administration.AccountPasswordData_Account\",\"Administration.Account\"]],\"p\":[\"Administration.AccountPasswordData\"]}": "mt0bQnybUFSUB9Dqc5JjvA",
        "{\"a\":null,\"p\":[]}": "2PIVCck2kFyTQCZb7aPkTQ"
    },

The “attributes” of this object are JSONs representing the associations (a) and parameters (p) of the microflow and the “values” represent the scrambled microflow names, comma separated if there are multiple. So the first line (starting with RL) takes a Doctor as input parameter when called, while the last line (2P) doesn’t take any parameters. Also the 2-but-last line is without parameters, and contains 5 more microflows: sE, mi, 7X, iA and Wv. Let’s try to call them! 🤙

If you want to see how the Mendix runtime server translates requests with an operation id into functional operations: check the deployment folder (or unzip a deployment package) and navigate to the model folder, in which you will find operation.json. This file reveils the translation of an operationId to a readable microflow name, XPath query or something else. 💡

Now another challenge comes into play: we would like to manipulate the request to the server, as the javascript interface is not very convenient. Here Burp Suite saves the day, as this tool enables you to intercept requests and manipulate them before actually send to the server.

As we click the button to open the homepage, we can intercept:

And we recognize this request (sE), and manipulate this to the next on ein the list (mi) to try it out. After clicking away some error, we get the pop-up about some test admin account, this goes smooth! 🥳

Not sure if we should do something with the pop-up, but let’s base64 decode what’s there.

Gooooo Valcon Hackers 🕵️We found another flag! 🚩

The amount of solves surprised me a bit, probably because using Burp is more common practice for the CTF visitor than using mx.data.get? 🤷‍♂️

As accessing random microflows is definitely something you want to protect, how does Mendix handle this? A microflow ends up in the session data when the following two conditions are met:

1. The logged in user has access (via the module roles configured).
2. The microflow is used on at least one place, regardless if that page is used and which module roles are linked to that page.

Did you know this? For me this was really an eyeopener, and I think page access should be handled stricter by Mendix to also tighten this better.

Vulnerability: TSU-02: Insecure entity access
Application: https://patientportal2025.mendixctf.com/
Reality check: It’s very common that entity access is not as tight as desired. Also for non-persistent objects it’s important to apply zero trust.

For this flag, we didn’t need extra sleep as we solved within 2 hours after the CTF started. The /rest-doc/ endpoint is not exposed, so we definitely should load the provided mpk-module in Mendix.

In the Published Rest Service (PRS), we see one operation is served without any authentication on /rest/pubsync/v1/synchronize?resource={resource}, which calls the microflow SUB_SynchronizePublicData. Well, opening this in the browser doesn’t reveil much, does it? 🤔

Let’s continue our investigation. The flow does another REST Call and that endpoint is secured, so maybe we need to breach that security somehow? Ahh, there is a FlagEndpoint, what happens if we call that?

OK, so we do need that session key! In SUB_GetSessionKey, we see that an API-key is exchanged for a SessionKey, can we do the same? Let’s call /rest/v1/auth/token using HTTP-Header X-API-Key: my_secret, as that is the default value. This worked during the first day of the CTF, but that route was not intended and cut off. So let’s continue on another route. 🕵️

SUB_GetSessionKey is only used in SUB_SynchronizePublicData, but wait: this flow is also used in the nanoflow ManualImport, used on the page ManualImport. Can we open the page, trigger the nanoflow and subsequently that microflow? Let’s try to open the page using mx.ui.openForm2("Importer.ManualImport", {}, null, null, { location: "content" }); and yes: click that button! 😃

If we do this while monitoring the Network in our browser Dev Tools, we see that the raw response contains a lot of objects: mostly Importer.Result objects, but also the Importer.Token having the Sessionkey 🎁:

Let’s use that sessionkey as HTTP-Header in a similar format as the synchronization call towards the Flag Endpoint using Postman and see if that reveals the Flag! Yes, it does: we captured another flag! 🚩 Gooooo Valcon Hackers 🕵️

So why does that Token object show up in your network? Only because you have read access for the Token entity, it’s returned in the response from the microflow to the nanoflow, even passed along from the subflow! This may seem insecure, but in this way allows Mendix you to update the client’s cache via microflows. Anyways, as developer: make sure ‘secret’ stuff is never exposed to users, even when it’s non-persistent! 🏁

Vulnerability: TSU-09: Insecure UI Component
Application: https://patientportal2025.mendixctf.com/
Reality check: Unintended ability to show pages is very common with Mendix unfortunately, but usualy static pages don’t disclose secrets, data does.

From previous CTFs we know that pages and layouts are (were) a static XML file, and conditional visibility is handled front-end. However, with strict mode everything is a bit scrambled and broken into multiple pieces, making it somewhat more challenging. The initial load of the home page results into ~30 requests and no XML files anymore:

Portal.Home_Web is aparently the main page served, but now as static javascript file. Good to know: references to pages still use the .page.xml extension, so when we search for .page.xml in any document we find a lot of references to pages in those javascript files:

We recognize some of the menu items (Home, Documents, MyDoctors, MyAppointments, MyPrescriptions) and also see 2 items which are hidden items for us as User:

• Administration/Account_Overview.page.xml for Administrator
• Portal/DevTools.page.xml for Tester

The latter asks for some further inspection, don’t you think? 🕵️

In strict mode, the ‘old’ mx.ui.openForm() function doesn’t work anymore . It is replaced by mx.ui.openForm2(). However, I did not find any documentation on that function, so I investigated before the CTF event how this function can be used. With some help of ChatGPT deducting the input parameters, I unravelled a way to show pages just like we did before strict mode: 😎

mx.ui.openForm2("Portal/DevTools", {}, null, null, { location: "content" });

And applying this during the CTF showed the page and revealed the flag, another flag captured! 🚩 Gooooo Valcon Hackers 🕵️

Having only 21 solves on this challenge shows that this code snippet to open pages is not common knowledge, so store it in your toolbox! This enables you to check your page security and will reveal which queries are executed on that page. Off course, the data should be correctly restricted using entity access to prevent situations like this.

To prevent usage of openForm2 function, one should hide sensitive page names completely from regular users or anonymous users. This could be achieved using microflows having the ‘Open page’ activity and configure the allowed roles to call those microflows accordingly. Don’t forget to choose an unguessable page name as well. 💡

• Write-up Mendix CTF 2025: No Accessible Vector (Tier 2)
• Write-up Mendix CTF 2025: Site Unseen

Vulnerability: TSU-02: Insecure entity access
Application: https://patientportal2025.mendixctf.com/
Reality check: It’s very common that entity access is not as tight as desired. This can be prevented by periodically reviewing the security overview within Studio Pro (https://docs.mendix.com/refguide/security-overview/).

This first challenge explicitly directs us in finding financial details about the budget, a clear clue what to look for. 🕵️ In the first request to /xas/, the session is initialized, and the response contains next to the real session data (User info and CSRF-token) also values of enumerations and constants, system texts and locale information. But most importantly, it contains the metamodel (entities) and some objects. Hopefully we find something useful in this 42 kilobytes of information 😉.

In the list of objects, we find a patient, an appointment, a document, a message, another appointment and a prescription, all from the Portal module. In the total list of 43 entities, we focus on the Portal module and find the existence of the following 12 entitities are probably of interest:

 Line  156:             " objectType ": " Portal.SessionSettings ",
 Line  190:             " objectType ": " Portal.Drug ",
 Line  297:             " objectType ": " Portal.Doctor ",
 Line  356:             " objectType ": " Portal.Ban ",
 Line  562:             " objectType ": " Portal.Hospital ",
 Line  885:             " objectType ": " Portal.Document ",
 Line 1154:             " objectType ": " Portal.Appointment ",
 Line 1247:             " objectType ": " Portal.Message ",
 Line 1566:             " objectType ": " Portal.Patient ",
 Line 1784:             " objectType ": " Portal.Partner ",
 Line 1969:             " objectType ": " Portal.Prescription ",
 Line 2123:             " objectType ": " Portal.Budget ",

As we look for the budget details, that Portal.Budget entity is definitely of interest, but we don’t have objects yet… 🤔
Browsing through the entities, we see an association from Hospital to Budget, from Doctor to Hospital and from both Message and Appointment to Doctor. Let’s check that out!

mx.data.get may be restricted for arbitrary XPaths, it’s still possible to retrieve objects by their ID, assuming we have read access at some of their properties. 💡
We have an ID for our Doctor using the objects Message and Appointment, so let’s try to retrieve all attributes we may read executing the following code in the console, resulting into:

mx.data.get({
    guid: "3659174699036655",
    callback: console.info
});

Opening the resulting Jg object, we see in _jsonData > attributes a filled association to Hospital, and if we repeat this exercise for the Hospital id, we see a filled association to Budget. 🎉 We’re getting somewhere!

Retrieving this Budget object, we don’t see any suspicious attributes, but we see it’s a File Document. So let’s download by putting
/file?guid=23643898043823266 in the URL.
And there we have it: we found the flag in the downloaded Excel file! 🚩Gooooo Valcon Hackers 🕵️

If strict mode wasn't enabled, this flag was very easy to find using some developer tool. This stresses the importance of configuring entity access correctly.

A couple of weeks ago, Valcon hosted a Mendix Meetup with an interactive quiz on Maintenance vs. Performance, where these developer profiles were characterized by Johan vs. Johan (me). The idea was to determine your inner developer profile by asking questions on your development approach. For those who couldn’t join, let’s reflect on these questions and look at the given responses in this Mendix Meetup Recap. If you did join, you might want to revisit quesions 4 and 8, where the majority had an incorrect answer!

Question 1: Developer focus

We kicked things off with a self-reflection: where do you think your primary development focus lies? Most questions throughout the quiz could earn you either Maintenance or Performance points — and sometimes neither if your answer was just plain wrong.

Of the ~60 attendees, 52 participated in the quiz. The majority saw themselves as maintenance-oriented developers. But when the points were tallied, the difference was surprisingly small: 29 leaned Maintenance, 22 towards Performance. So… do we really know ourselves?

Question 4: Retrieve over association vs. database

After warming up, things got serious. This question sparked one of the most surprising insights of the evening.

This is a real myth buster, as retrieving over association in the child direction (i.e. the originating entity is not the owner of the association) always performs a database retrieve and combines this with the cache (items in dirty state). However this merge is unmeasurable fast, making C the only right answer (performance points). Did you know this? Only 35% got this right!

FYI: retrieving over association in the other direction may be faster, only if the owning object is in dirty state. However, being in dirty state, the functional difference (from database or over association) should determine your solution, not performance.

Question 5: Find vs. retrieve in loop

Next up: a classic performance-vs-maintainability trade-off in a data import flow. Imagine we regularly import a list of Phone Numbers and instead of just using the existing String attribute “Country prefix”, we want to associate it with the Country as entity. In the process flow, we update all the Phone Numbers by looping over all of them and committing the updated association in the end. Would you ‘Retrieve the country from the database in the loop’ or ‘Load all countries in a list before the loop, and find the country within the list in the loop’?

A satisfying large group chose for the second option, which is indeed better performing without losing maintainability.

Based om some testing, we now apply as rule of thumb:

For lists smaller than ~1000 items, the Find activity already outperforms multiple DB calls after just two iterations.

Just be careful with large lists: memory usage and Find performance may become problematic depending on your data model.

Question 8: Retrieve generalization or specialization?

This one stumped more than a few people! Consider these 2 different retrieves:

Which one is faster when retrieving from database? Retrieving a Vehicle or retrieving a Car being a specialization of Vehicle? When you have retrieved the Vehicle, you only can only use the generalization attributes, right?

Maybe this will surprise you, but retrieving the Car (answer B) is faster! We saw that any retrieve of a generalisation will also retrieve the specialization in an additional query. And if the specialization contains more layers or your results contains different specializations, this will even execute multiple queries. The fun side: executing a cast doesn’t trigger a database call!

If you directly query a specialization, the database retrieve is executed using a join on database level, resulting in a single query, making it faster.

Question 10: Use a generalisation for master data

Let’s say your app has over 30 master data entities, many with common behaviors like Activate/Deactivate and a sorting order for dropdowns. What’s your modeling strategy? Would you:

• A) Create a generalization of masterdata to take care of the requested functionality and create specializations for the masterdata items.
• B) Create a unique masterdata item and create the requested functionality separately for the masterdata items.

The audience results were nearly split, with a slight preference for B.

Clearly, buttons like activate and deactivate can be easily reused, making option A better for maintenance. However, it has a slight performance impact and masterdata may be heavily used, making B a logical choice from performance perspective. As we as Johan and Johan still don’t agree on this one, we’re glad the audience doens’t either.

Thanks for joining us at this Mendix Meetup — whether in person or now via recap. We had a great time debating, myth-busting, and sometimes being proven wrong. See you next time!

Pagination, sorting and filtering

Datagrids are good at pagination, and only request data from the page currently shown when you retrieve from database. If you retrieve from microflow however, it’s retrieving all records. Having large datasets, this heavily impacts the performance and is the number 1 reason to not use microflows as data source. Once loaded, pagination, sorting and filtering happens client side and will be super fast. Depending on the size of your dataset this reason may apply.

For those thinking: wasn’t there some System.Paging entity to support server side pagination, sorting and filtering? Yes, that’s supported in the Datagrid 1, but not in Datagrid 2 anymore/yet. See https://docs.mendix.com/refguide/server-side-paging/

Restriction by access rules

The end-result of a microflow is not exactly the same as what is shown front-end. Between the end activity and the response message to the client the restrictions from access rules are applied. Depending on the complexity of the access rules, this already has negative impact on the performance executing these on the server instead of on the database.

In addition – as ‘apply entity access’ is never switched on in my experience – the resulting database retrieve is probably too broad causing too much data to be transferred between database and Mendix server again impacting the performance.

Retrieved members

When a database retrieve is done ‘directly’ by the client, the query can be optimized by only retrieving the members (attributes and associations) shown to the user. This is the default optimizing behavior of Mendix:

Using a microflow or nanoflow as data source, you can still configure this option, but it will only affect the communication between client and server and this optimization is not propagated in the communication between server and database. This increases database load and communication overhead, negatively impacting performance.

Exceptions

Exceptions I can think of now:

• Small datasets, i.e. <100 records in total
• Specific retrieval of single item
• Complex retrievals

I’m curious to your exceptions, feel free to share in the comment section!

Alternatives

If you think the performance is indeed negatively impacted, but you do need a data source microflow, there are some alternatives you might want to consider:

• Apply entity access has 2 benefits: it limits the size of the dataset retrieved and it doesn’t retrieve members that aren’t accessible, e.g. associations without read access.
• Implementing your custom server side filtering using a containing data view.
• And also a view entity may help to optimize your query. If someone does have access to attributes, applying entity access does very little restraining. Having a view entity allows to specifically retrieve the attributes you want to show.

Conclusion

Microflows as a data source often lead to performance bottlenecks due to three key reasons:

• Pagination, Sorting, and Filtering — A microflow retrieves all records at once, whereas a database retrieve only fetches the necessary data for the current page. This can severely impact performance, especially for large datasets.
• Access Rules Processing — Entity access rules are applied after a microflow executes, which may result in unnecessary data retrieval and extra server-side filtering, increasing load on the Mendix runtime.
• Inefficient Data Retrieval — When retrieving directly from the database, Mendix optimizes queries to fetch only required attributes. Microflows bypass this optimization, leading to higher database load and increased network traffic.

Before implementing a microflow as a data source, ask yourself:
✅ Can I retrieve data directly from the database instead?
✅ Is my dataset small enough (<100 records) to justify a microflow?
✅ Are there complex retrieval requirements that truly require a microflow?

If a microflow is necessary, consider:
🔹 Applying entity access to limit data retrieval.
🔹 Using a view entity to optimize queries.
🔹 Implementing server-side filtering instead of fetching unnecessary records.

Final tip: Always document your decision in an annotation to help future developers understand why a microflow was used!

Have you encountered performance issues using microflows as a data source? Share your experiences in the comments!