Mendix Penetration Testing
In Mendix, a microflow ignores entity access rules unless a developer switches that setting on, leaving every record open. We test your module roles, entity access rules and microflows for that gap. CREST-certified testers, fixed price from £2,270 for a 2-day single-app scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Every Mendix microflow ships with Apply Entity Access switched off, so it retrieves every object and allows every operation unless a developer turns that setting on.
A Mendix microflow only enforces your access rules if a developer switched that setting on
Mendix access control runs on two layers: user roles, which an end-user is assigned directly, and the module roles those user roles combine underneath them, since each module defines its own roles and a user role is really just a combination of module roles pulled from across the app. Inside a module, access rules attached to an entity define, per module role, whether an end-user can create, delete, view member values or edit member values, and an XPath constraint, including the built-in Owner and Path to User options, narrows a rule to a subset of objects rather than the whole entity. Rules are additive across every module role they apply to, and none of it is inherited from an entity’s generalisation, so a specialisation such as a file entity built from System.FileDocument needs its own explicit rule or it is not limited by anything set on the parent.
Whether any of that reaches a microflow depends on two separate settings that are easy to overlook. A microflow’s Allowed Roles property gates who can start it from the client, but that check is skipped entirely once one microflow calls another, and its separate Apply Entity Access setting is disabled by default, meaning every object is retrieved and every create, read, write and delete is allowed regardless of who is signed in. Nanoflows add a further layer to check: they run in the browser or on the device rather than on the server, which is what lets an app work offline, and only a Create, Commit, Retrieve or Rollback object step calls back to the Mendix Runtime at all.
The same pattern shows up in integrations. Published REST and OData services default to basic or active session authentication once app security is switched on, but either can still be opened up: a REST service accepts anonymous access once the anonymous role is added to its allowed roles with Username and password selected as the authentication method, and an OData service can expose data to anonymous users even when Requires Authentication is set to Yes. Mendix Cloud’s licensed environments are required to run the Production security level, but a tenant is only as private as the roles, entity access, microflow and service configuration built on top of it, on Mendix Cloud or on a private Mendix on Kubernetes cluster, and that configuration is what we test.
SCOPE
What we pen test on a Mendix application
App security level: Off, Prototype/demo and Production
Mendix has three security levels: Off applies no security at all, Prototype/demo secures signing in, forms and microflows while a signed-in user can still see all data, and only Production secures entities and reports as well. Mendix’s own documentation requires every licensed Mendix Cloud node to run at Production, with Off and Prototype/demo allowed only for local testing, Free Apps and cloud environments outside Mendix Cloud set up in Development mode; we check which level is actually configured against what the app is meant to be running as.
User roles and the module roles behind them
An end-user is assigned one or more user roles, and each user role is really a combination of module roles defined inside individual modules, so the same user role can pull together a TeamLeader role from one module and an Administrator role from another. We map every user role to the module roles it actually grants, since a role named for a business function can carry far more, or less, than its name suggests once every module is accounted for.
Entity access: create, read, write, delete and XPath constraints
Entity access lets you define, per module role, whether an object of an entity can be created, read, written or deleted, and a member-level access rule further sets whether a specific attribute or association can be viewed or edited; an XPath constraint, including the built-in Owner and Path to User options, narrows an access rule to a subset of objects rather than the whole entity. Multiple access rules on the same entity are additive, so we test the combined effect of every rule that applies to a role, not any single rule read in isolation.
Access rules that do not carry over to a specialised entity
Mendix access rules are not inherited from an entity’s generalisation, which matters for anything built as a specialisation of a system entity such as a file document: a rule defined on the parent does not limit the specialisation, so every file, image or other specialised entity needs its own explicit access rule and XPath constraint. We test whether the entities actually holding your files and documents were given rules of their own, or are quietly relying on protection Mendix does not apply to them.
Microflow Allowed Roles and what calling another microflow skips
A microflow’s Allowed Roles setting is checked only when the microflow is triggered directly from the client; once inside a microflow, calling another microflow never re-checks that second microflow’s allowed roles. We test whether a tightly scoped, client-facing microflow calls into one meant for a more privileged role, since that call is never gated by the role check its own entry point relies on.
Apply Entity Access: off by default on every microflow
Apply Entity Access is disabled by default on a new microflow, and while it is off, every retrieve, create, commit and delete inside that microflow ignores entity access entirely, retrieving every object and allowing every operation regardless of who is signed in. We test every microflow that touches data for whether this setting was ever turned on, since a microflow can look properly secured at the Allowed Roles level while still bypassing every entity access rule underneath it.
Nanoflows: logic that runs on the device, not the server
A nanoflow runs directly in the browser or on the device rather than on the Mendix Runtime, which is what allows an offline app, and only specific activities such as creating, committing, retrieving or rolling back an object call back to the server at all. We test what a nanoflow is trusted to decide on its own, since a check that only happens on the client can be skipped by anyone who does not go through the client to reach the server.
Published REST services: default authentication and anonymous access
A published REST service uses basic or active session authentication by default once the app’s security level is Prototype/demo or Production, and it becomes reachable without authentication if anonymous users are allowed into the app, the anonymous role is added to that service’s allowed roles, and Username and password is the authentication method selected; a service can also be built with no authentication at all or with a custom microflow instead. We test every published REST service against the authentication method it is actually configured with, not the one its documentation implies.
Published OData/GraphQL services and Requires Authentication
A published OData or GraphQL service can require authentication or not, and Mendix’s own documentation notes that even a service set to require authentication can still be exposed to anonymous users if the anonymous role is added to it, while custom authentication can hand the whole check to a microflow, for example one validating a token issued by the Mendix SSO module. We test what each published entity and microflow in the service actually returns to an anonymous or under-privileged caller.
Anonymous users and what role they are actually given
Allowing anonymous users lets people reach parts of the app without signing in, and what they can see and do from there is set by whichever user role is assigned to the anonymous user, the same as for any other end-user. We test that role against every entity, microflow, page and published service in scope, since an anonymous user picking up broader access than intended is a configuration change, not a platform default.
OUR PROCESS
Mendix Application Penetration Testing: From Scope to Attestation
Module, Role and Environment Mapping
We catalogue every module role, user role, entity access rule and published service in the app, and confirm whether Production security level and Mendix Cloud or private cloud hosting apply.
Role-Based and Entity Access Testing
We test from accounts in every user role in scope, checking what each one’s module roles, entity access rules and XPath constraints actually allow against a live object.
Microflow, Nanoflow and Service Testing
A CREST-certified tester works through every client-callable microflow and nanoflow for its Allowed Roles and Apply Entity Access settings, and every published REST and OData service for its authentication configuration.
Reporting and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Mendix pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Mendix Application Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Mendix For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Mendix Application Penetration Testing
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Mendix app?
A login for each user role you want tested, from a standard end-user role up to Administrator, is enough to start. Studio Pro or read access to the module roles, entity access rules and published service configuration speeds up confirming what we find, though it is optional.
Will this touch our live data?
We test read-only against production by default. Where proving a create, write or delete needs real records, we agree a sandbox environment or specific test data with you first, and anything we create during testing is documented and removed afterwards.
Is this hosted on Mendix’s infrastructure or ours?
Mendix Cloud, built on AWS, is Mendix’s default deployment option and its public cloud service, though Mendix Cloud Dedicated offers a single-tenant instance and Mendix on Kubernetes lets you run the same app on your own private cluster instead. We scope the test to your app, module roles, entity access, microflows and services either way, not to the underlying platform infrastructure.
Does Mendix have a policy for customers testing their own app on Mendix Cloud?
We could not find a published self-service penetration-testing policy or notification process on Mendix’s own documentation. Mendix Cloud licensed nodes and Free Apps run on shared, multi-tenant infrastructure unless you are on Mendix Cloud Dedicated or a self-hosted Mendix on Kubernetes cluster, so we confirm Mendix’s current terms and any notification requirement with you during scoping before testing starts.
What is out of scope?
Mendix’s own platform and Runtime code, other customers’ apps and tenants on shared Mendix Cloud infrastructure, and denial-of-service testing are all out of scope. We test the app, module roles, user roles, entity access, microflows, nanoflows and published services you have built.
How long does a Mendix application test take?
A single-app engagement is scoped at 2 testing days as a starting point, rising with the number of modules, user roles, microflows and published services in scope. We confirm the exact day count once we have seen the app.
Do you need our Studio Pro project or just a running app?
A running app with test accounts in every relevant role is enough to start. Access to the Studio Pro project speeds up root-causing anything we find, particularly around Apply Entity Access settings and XPath constraints that are not visible from outside the app, but it is not required.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Mendix application
In Mendix, a microflow ignores entity access rules unless a developer switches that setting on, leaving every record open. We test your module roles, entity access rules and microflows for that gap. CREST-certified testers, fixed price from £2,270 for a 2-day single-app scope, quoted within 24 hours.
