Wat DIVD vond in jouw Mendix-app

1. Een bekend probleem op grotere schaal

Februari 2026. DIVD publiceert een rapport over meer dan 2.000 Mendix-applicaties die gevoelige data blootstellen aan het publieke internet. Geen geavanceerde aanval. Geen zero-day exploit. Gewoon een browser en wat nieuwsgierigheid. Het enige wat ontbrak? Een goede configuratie.

Wat nog ongemakkelijker is: dit was niet de eerste keer. DIVD deed hetzelfde onderzoek al in 2022. Destijds werden organisaties genotificeerd. De kwetsbare apps werden aangepast. Het probleem opgelost. Tot de volgende keer.

Dat roept een vraag op: als het probleem bekend is, de oplossing gedocumenteerd en de tools voorhanden, waarom blijft het dan terugkomen? Het antwoord is niet technisch. Het is organisatorisch. Security wordt in veel Mendix-teams behandeld als een eindcheck. Niet als eigenschap van het ontwikkelproces. En een eindcheck overslaan? Dat gebeurt sneller dan je denkt.

In deze blog kijken we naar wat DIVD precies aantrof. Waarom dit soort misconfiguraties zo hardnekkig zijn. En belangrijker: hoe je security zo inricht dat je de volgende DIVD-ronde met een gerust hart tegemoet ziet. De basale vraag: ben jij in control?

2. De kern van het probleem is niet het systeem

Het Mendix-beveiligingsmodel is in principe eenvoudig.
Een Mendix-app bestaat uit twee lagen:

• Mendix Client: draait in de browser van de gebruiker
• Mendix Runtime Server: draait aan de achterkant

De client communiceert met de runtime via de /xas/ request handler, de Mendix Client API. Alles wat je op het scherm ziet, komt via die route.

De beveiligingslogica zit uitsluitend in de runtime.
Entity access rules, module roles, user roles en XPath constraints bepalen wat een gebruiker mag opvragen en zien.
Mendix is hier expliciet over: de client is per definitie niet te vertrouwen. Alles wat op het apparaat van de gebruiker draait, valt buiten de controle van de server.

Dat is geen tekortkoming van het platform. Het is een bewuste architectuurkeuze. En een correcte. Het is zelfs een van de sterke punten van Mendix ten opzichte van alternatieven.

Het probleem ontstaat wanneer die serverregels niet goed zijn geconfigureerd.

Dan levert de runtime braaf data op waar hij dat niet zou mogen doen. Geen exploit nodig. Geen bijzondere kennis vereist. Een gewone /xas/-aanroep is genoeg.
It’s not a hack, it’s a “feature”.

DIVD trof in de praktijk terugkerende patronen aan:

• Anonieme gebruikers met leestoegang tot privé-entiteiten
• Module roles die te ruim zijn ingesteld
• XPath constraints die ontbreken of onvolledig zijn
• Microflows die toegangscontroles stilletjes omzeilen

De gevolgen zijn concreet. Blootgestelde namen. Adresgegevens. Klantdossiers. Interne documenten. Soms identiteitsbewijzen. AVG-risico. Kans op fraude en phishing. Reputatieschade.

En het meest verraderlijke: misbruik is nauwelijks te detecteren. Een /xas/-aanroep van een kwaadwillende ziet er in de logs precies hetzelfde uit als een aanroep van een gewone gebruiker.

De ironie? Het beveiligingsmodel van Mendix werkt precies zoals het moet. Het probleem zit niet in het platform. Het zit in het proces.

3. Hoe je het dan wél aanpakt

Het goede nieuws: dit patroon is te doorbreken. Maar niet met een eenmalige fix.
Security moet een eigenschap zijn van het hele ontwikkelproces. Niet een checkpoint aan het einde.
De Software Development Life Cycle (SDLC) biedt daarvoor een natuurlijke kapstok. In elke fase zijn er keuzes te maken die het risico structureel verkleinen.

3.1 Design: least privilege als vertrekpunt

De eerste keuze is de belangrijkste. Standaard geen toegang, tenzij expliciet toegekend. Niet andersom.
Dat klinkt vanzelfsprekend. Maar in de praktijk is het verleidelijk om tijdens het modelleren ruim te beginnen en later te beperken.
Echter: niets is zo permanent als een tijdelijke oplossing.
Least privilege betekent dat je bij elke nieuwe entiteit de vraag stelt: wie mag dit zien, en onder welke voorwaarde?
Die vraag hoort thuis in het ontwerpgesprek. Niet in de post-mortem.
Voor teams op Mendix 10.12 of hoger is er bovendien Strict Mode. Het beperkt wat de client mag opvragen, ongeacht de access rules. Het werkt daarmee als vangnet achter de configuratie.
Geen vervanging voor correcte instellingen, maar wel een zinvolle tweede laag.

3.2 Coding standards: security als onderdeel van de Definition of Done

Een entiteit zonder access rules is geen half werk. Het is een open deur.
Neem security expliciet op in de Definition of Done van user stories die een aanpassing in het domeinmodel vereisen. Dan wordt het geen vergeetpunt maar een afrondingscriterium.
Geen user story klaar zonder dat de access rules, module role mappings en XPath constraints zijn doorgelopen.
Gecombineerd met peer review – vier ogen op elke security-gevoelige wijziging – wordt dit een structurele rem op sluipende misconfiguratie.

3.3 Testing: geautomatiseerde validatie

Access rules laten zich automatisch testen. Bijvoorbeeld via Menditect.
Dit is optioneel, maar het verkleint het gat tussen peer review en releasecheck aanzienlijk.
Een falende test op een ontbrekende access rule? Altijd prettiger dan een melding van DIVD.

3.4 Release: de outside-in check

Vóór elke productie-deployment is het de moeite waard om de app te benaderen als anonieme gebruiker. Wat is er zichtbaar van buiten?
De meest grondige manier is een penetratietest. Een security-specialist probeert dan systematisch toegang te krijgen tot data die hij niet zou mogen zien.
Voor teams die dat niet bij elke release inzetten, is menscan.io een snelle en toegankelijke alternatief. Het gebruikt dezelfde Mendix Client API als de browser en simuleert precies wat een aanvaller zonder inloggegevens zou zien.
Het controleert onder andere op:

• Anonieme toegang
• Demo users die nog actief zijn in productie
• Blootgestelde metadata

Weinig tijd. Veel preventief vermogen.

3.5 Governance: continue feedback

Een eenmalige check bij release is niet genoeg. Autorisatiedrift treedt op tussen releases: nieuwe modules, gekopieerde configuraties, stille rolwijzigingen.
AppControl van Blue Storm bewaakt het gehele Mendix-portfolio continu. Het scant zowel het projectmodel als gedeployde apps. Het dwingt centraal gedefinieerde security policies af via pipeline checks. En het signaleert drift voordat het productie bereikt.
Aangevuld met een periodieke toegangsreview – zeker na teamwisselingen of grote functionele uitbreidingen – wordt governance een sterke eigenschap van het landschap.

Conclusie

De DIVD-melding is geen reden tot paniek. Het is geen platformfout. Er is geen urgente patch. Je hoeft je app niet offline te halen. Maar het is wel een signaal. Een herinnering dat security niet vanzelf goed blijft als een applicatie groeit, een team wisselt of een deadline nadert.

De aanpak is niet ingewikkeld:

• Least privilege als uitgangspunt bij het ontwerp
• Security als vast onderdeel van de Definition of Done
• Een outside-in check voor elke release
• Continue governance over het portfolio

Geen van deze maatregelen is bijzonder zwaar. Samen vormen ze een proces waarbij misconfiguraties worden gevangen voordat ze productie bereiken.
Vertrouwen in je team en de gemaakte afspraken is een sterke basis. Continue governance is beter.
Mendix geeft je de juiste tools om veilige apps te bouwen. Wat DIVD (nogmaals) aantoont? Dat het hebben van die tools niet hetzelfde is als ze goed gebruiken.

Het verschil zit niet in het platform. Het zit in het proces.