App security is one of the most important aspects of what developers need to get right when creating Mendix apps. However, it is common for developers to either wait until an app is mostly completed before implementing security or to not successfully implement correct security measures in the first place. This can cause serious issues once the app is in a production environment.
This blog post will discuss the key fundamentals you need to apply to an app for successful security.
Project Security vs. Module Security
The term “user role” can mean different things based on the context of where you are in the app, whether it be in the project or in one of the app modules. Technically, a user role is the role a user has in the app, whereas a “module role” is the role a user has in a specific module within the app. In practice, though, it is common to use “user role” for both situations.
This is an easy definition to help you remember which role is which: a user role is the grouping of selected module roles. When developing an app, you should create a set of module roles for each module you plan to use in the app (if a module does not need any type of security, then no module roles are needed). Then, you can create the user roles for the project itself.
This is an example of how a user role has several module roles associated to it:
Entity Security vs. Template Grid Visibility
Knowing when to use entity security and template grid visibility is crucial. To ensure an app is secure, you need to make sure that sensitive data does not leave the database when it is not supposed to. Entity security specifies what data is sent from the database to the client while also giving users the ability to create and delete objects within the app.
Without entity security in place, any page can retrieve data objects from an entity. With a template grid XPath constraint, data from the server is only sent if it meets the XPath constraint criteria. However, this is only in effect for that specific template grid. Because of the possibility that all the data for an entity can be sent from the database to the client, a template grid XPath constraint is not considered to be security and should not be used as such. This is a common mistake developers make when developing apps, and this mistake can cause serious security issues. To set a specific constraint in an entity to make it secure, you can set the XPath constraint at the entity level so that every data grid you create in the app will automatically have this constraint enabled.
If the security of this data is not critical and you only want to filter what data is visible for a specific data grid, you can go into the data grid itself and set the XPath, as shown here:
Microflow App Security
When using microflows in an app, the first security check that will occur before a microflow runs will make sure that the user has the correct module-level security. If the user has the proper module-level access, then the microflow and all the sub-microflows within this triggered microflow will run. Sub-microflows inherit their parent microflow’s security, no matter what type of module-level security is set at the sub-microflow level. So, in practice, if you have a microflow that has several sub-microflows and expect only some of those sub-microflows to run based on the sub-microflow security, then your setup should not be dependent on the sub-microflow security, as it will run every time the main microflow runs, thus causing a security issue.
Security for microflows can be tricky, because you can choose whether a microflow enables entity security to dictate what data can be used. When a microflow does not have entity security enabled, a user role can retrieve objects from an entity that the user role does not have entity access to, and thus a security issue could arise. When Apply entity access is enabled, the background of the microflow turns yellow, and any type of action on the database will take into account whether the user role has access to perform that action. This added level of security ensures that an application will not accidentally give users the ability to read, write, or delete objects they are not supposed to.
Security Causing Strange App Behavior
When developing and testing apps, one common issue you may encounter is not seeing either a button or data grid that is clearly in the Modeler.
When this behavior occurs, the first thing you should do is check the security of the action button. Since this is a New button, you should first check if the Allow creating new objects check box is selected for this entity.
If this box is checked and the button is still not being shown, you should then check if the button triggers a microflow instead of showing the default Mendix New button. In the above case, there is a microflow being triggered—the action button calls a microflow called IVK_NewSalesContent. When checking the security of this microflow, you can see that the user does not have access to the microflow, hence the button not displaying.
Conclusion
App security is a vital part of a successful app in Mendix. Taking the time early on in your app development will help you to avoid some of the issues outlined above and to make sure that your app is as secure as possible!
If you would like to learn more about Mendix app security, please read the Mendix developer documentation found here.