Mendix Security Checks Explained: Check Security, Strict Page URL Checking, and the User Role Check…

Introduction

Three small settings in Mendix App Security decide which security mistakes Studio Pro shows you before you deploy: Check security, Strict page URL checking, and the Check security checkbox on each user role. None of them adds or removes runtime protection. They control how thoroughly Studio Pro inspects your model for gaps between page access and entity access.

Most developers never touch these settings. They keep their default values from the day the app is created, so few people know what each one actually does or what would change if it were disabled. This blog explains what each setting does, what happens when it is switched off, how the settings depend on each other, and walks through a real example using a Request entity.

All three settings are available only when the security level is set to Production.

In one line: the first setting turns the check on, the second makes it reach further, and the third leaves out specific roles.

1. Check security (App Security radio button)

This is the master switch; Check security = Yes makes Studio Pro verify, role by role, that every page a role can open only shows data that role is allowed to read.

What it does

1. For each user role, Studio Pro works out which pages that role can reach. It follows the navigation menu and then every page and microflow that leads on from there.
2. For each of those pages, it checks that the attributes and associations shown on the page are readable for that role, according to entity access rules.
3. If they aren't, it adds an error to the Errors pane naming the page, the role, and the attribute or association.

Things to know

• Design time only. It's a consistency check in Studio Pro. At runtime, Mendix enforces entity access regardless of this setting.
• Shown last. Security errors only appear when the app has no other consistency errors. If you fix a normal error and a batch of security errors suddenly appears, that's why.
• One role at a time. The check assumes each user role works on its own. It doesn't consider users who need two roles combined to use a page. If your app relies on combined roles, you'll see errors for setups that work fine for real users.

What happens if it is disabled

With Check security = No, Studio Pro stops comparing pages against entity access, for every role. Runtime behaviour doesn't change, because entity access rules still protect the data. But mismatches are no longer reported, so users without read access see empty fields, missing columns, or broken pages. The first sign is a user complaint instead of an entry in the Errors pane.

2. Strict page URL checking (App Security radio button)

Strict page URL checking = Yes adds pages that users can only open by typing their page URL to the security check.

The gap it closes

The Check security scan follows navigation, buttons, and microflows. A page with a page URL (for example /requests/overview) may have none of those links. Users reach it from a bookmark, an email, or by typing the address.

• No: a page that is only accessible through its URL is skipped. Its security is never checked.
• Yes: URL-only pages are checked exactly like pages reached through navigation.

Things to know

• On by default in new apps. Older, upgraded apps may still have it set to No.
• Page URLs only. It works for pages with a page URL configured in Studio Pro. It doesn't cover deep links, because those are configured at runtime and Studio Pro can't see which page they open.
• No effect on pages without a URL. Those are already covered (or not) by Check security.

What happens if it is disabled

With Strict page URL checking = No, the normal check still runs for pages reached through navigation, buttons, and microflows. Pages that users can only open by URL are left out completely. A gap on such a page only shows up when someone opens the URL and sees empty or missing data.

3. Check security checkbox (per user role)

The Check security checkbox on a user role decides whether that one role is included in the security check.

When to clear it

Clear it only for roles that never sign in to the app's user interface. The typical case is a role used only by published web service, REST, or OData clients. Those users never open a page, so page-based checks only produce noise.

When to keep it ticked

Keep it ticked for every role that real people use in the browser or mobile app: Initiator, Manager, HR, and so on.

What happens if it is cleared

Clearing the checkbox doesn't fix anything. It only hides that role's errors. The Test role has the checkbox cleared. If Test is a normal UI role, any page-access gaps for it will never show up in Studio Pro.

How the three settings differ and depend on each other

The settings form a chain: Check security turns the scan on, the role checkbox decides who is scanned, and Strict page URL checking decides how far the scan reaches.

If Check security is No, the other two settings have no visible effect, because there is no scan for them to adjust.

How they depend on each other

• Check security is the master switch. It defines the scan the other two adjust.
• Strict page URL checking adds pages to the scan. It can't add anything if the scan is off.
• The role checkbox removes roles from the scan. It only matters while the scan is on.
• None of them changes runtime security. Entity access rules protect your data whatever these settings are.

Recommended default for production apps: Check security = Yes, Strict page URL checking = Yes, role checkbox ticked for every role except API and web service roles.

Conclusion

These three settings work as one system. Check security is the switch, Strict page URL checking widens its reach to URL-only pages, and the role checkbox leaves out roles that never use pages. You rarely need to change them, but knowing what they do helps you read the security errors Studio Pro reports, understand why an older app reports fewer errors than a new one, and notice when a role has been left out of the check.