Wat DIVD vond in jouw Mendix-app
Leestijd: ±5 minuten
1. Een bekend probleem op grotere schaal
In februari 2026 publiceerde DIVD een rapport over meer dan 2.000 Mendix-applicaties die gevoelige data blootstelden aan het publieke internet. Geen geavanceerde aanval, geen zero-day exploit, gewoon een browser en een beetje nieuwsgierigheid. Het enige wat ontbrak was een goede configuratie.
Wat misschien nog ongemakkelijker is: dit was niet de eerste keer. DIVD deed hetzelfde onderzoek al in 2022. Destijds werden de betrokken organisaties genotificeerd, de kwetsbare apps aangepast, en het probleem opgelost. Tot de volgende keer.
Dat roept een vraag op die deze blog probeert te beantwoorden: 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 een eigenschap van het ontwikkelproces. En een eindcheck kun je overslaan.
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 vanuit 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: de Mendix Client, die draait in de browser van de gebruiker, en de Mendix Runtime Server, die aan de achterkant de dienst uitmaakt. 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 een aantal 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: mistinuebruik 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 is dat het beveiligingsmodel van Mendix precies werkt 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 is dat dit patroon te doorbreken is, 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 kan opvragen, ongeacht de access rules, en werkt daarmee als een vangnet achter de configuratie. Geen vervanging voor correcte instellingen, maar 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. Door security expliciet op te nemen in de Definition of Done van user stories die een aanpassing in het domeinmodel vereisen, 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 ook 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 is 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 een anonieme gebruiker; wat is er zichtbaar van buiten? De meest grondige manier is een penetratietest, waarbij een security-specialist systematisch probeert toegang te krijgen tot data die hij niet zou mogen zien. Voor teams die dat niet bij elke release kunnen inzetten, is menscan.io een snelle en toegankelijke lichtere variant. 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 en 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, dwingt centraal gedefinieerde security policies af via pipeline checks en 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 en 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 en 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, is 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.
Auteur: Stephan Wolbers – Head of Technology & Innovation MxBlue | SUPERP
