October Security Series: What’s That Checkbox Actually Doing? A Guide to Mendix Security Settings

Every Mendix project has that collection of checkboxes we've all seen a hundred times: Check Security, Apply Entity Access, Multiple Concurrent Sessions, Strict Mode. Most of us enable them because the project template did, a previous developer did, or because changing them feels a little risky. Somewhere along the way, the checkbox became more familiar than its actual purpose.

In this blog, we'll uncover what these security settings really do, when they matter, and why understanding them is far more valuable than simply leaving them enabled and hoping for the best.

Security Level

It is what defines if the security is turned on or off in an application and what needs to be configured.

There are three security levels.

1. Off Security of the application is turned off, and nothing needs to be configured.
2. Prototype / demo Security of the application is turned on and need to configure user roles, module roles, page access, microflow access and nanoflow access.
3. Production Security of the application is turned on and need to configure user roles, module roles, page access, microflow access, nanoflow access and entity access.

Default Security Level is set to Off.

Check Security

It is what checks the security of each user roles for page access, microflow access, nanoflow access and entity access of the document, which is being accessed by navigation, page, microflow or nanoflow.

When any security issue is found, it is directly shown inside studio pro as error.

Ever seen the following error?

Check Security is what shows the above. If disabled, that error won't be showed in studio pro.

Just because you disabled check security and there is no error in studio pro doesn't mean the security is turned off. It is still checked in runtime and those data and document are not accessible.

It is enabled by default.

Strict Page URL Checking

Check Security will only check documents which are accessible through navigation, page, nanoflow or microflow but there are pages which are not accessed by mentioned but through page URLs.

These pages are not checked for security. So, to enable check security for these pages, Strict Page URL Checking needs to be enabled.

It is enabled by default.

Strict Mode

It is an additional layer of runtime security which helps by restricting certain client APIs.

Consider a scenario where you have hidden a button which call a microflow through visibility. The button will be shown only if certain business logic is met. This can be bypassed, using data.action client API will invoke the microflow which is hidden.

The above scenario can be avoided if strict mode is enabled.

It is enabled by default.

User Management

This is where a user role is given access to manage users of other user roles.

Managing users means creating, viewing, editing and deleting users of selected user role.

Consider an application with Administrator, Manager and Employee user roles. Administrator can manage Administrator, Manager and Employee, Manager can manage only Employee and Employee cannot manage any users.

In the above, Administrator is selected with Administrator, Manager and Employee, Manager is selected with only Employee and Employee is selected with none in the user management.

When no user roles option is selected, the user can create a user but cannot assign any role to it.

All roles are disabled by default for newly created user role.

Password Policy

It helps in creating a strong password which is hard to crack or guess.

Password Policy is applied when creating password. It won't affect the stored password until changed.

Module Security

It allow us to view or edit module roles, page access, nanoflow access, microflow access and entity access consolidated of that module.

1. Selected Module role have access to the document.
2. Unselected Module role don't have access to the document.
3. Yellow Selected Selected module role is not required for the document.

OData, REST and Dataset access are also managed from here. Shown only when those documents are created.

Security Overview

It is used to view module roles, page access, nanoflow access, microflow access and entity access assigned for user role at selected module level.

Multiple Sessions Per User

It defines if the users in the application can have multiple sessions or not.

If users want to maintain multiple sessions in defferent devices then it needs to be enabled.

If users want to logout from previous sessions when new login performed then it needs to be disabled.

It is applied at application level not at user level.

It is enabled by default.

Conclusion

Mendix gives us powerful tools to secure applications. The challenge isn't enabling them.

The challenge is understanding what they're protecting, why they're protecting it, and when a seemingly innocent checkbox can have significant security implications.

So the next time you're reviewing your project's security settings, take a moment before clicking Save.

Let me know if you'd like further adjustments or additional points for the blog post!

Have you learnt something new today? Leave a like and share the blog for better visibility. Follow for more content.

Read more

App Security Introduction In App Security, you can switch security on or off for the whole app. You can also configure security…

Strict Mode Introduction Configuring access rules is essential for the security of your app. However, accurately setting up these…

User Roles Introduction A user role aggregates a number of access rights to app documents such as data, pages, and microflows…

Password Policy Introduction You can specify a number of requirements for passwords. These requirements will be applied when creating…

Module Security Introduction For more general information on security, see Security. Within a module you can define module roles and…

Security Overview Describes the Security Overview in Studio Pro, which summarizes entity, page, microflow, and nanoflow access for each…