October Security Series: Dear Developer, Giving Every Access to Everyone Isn’t a Great Idea

The biggest threat to your application's data is not always a sophisticated attacker. Sometimes it's a well-intentioned developer trying to meet a deadline. Entity Access Rules is one of the most powerful security features in Mendix, yet it's often configured only after a security error appears on the screen.

In this blog, we'll break down Entity Access Rules from the ground up, explain what every permission does, and work through common business scenarios to demonstrate how secure access can be implemented without compromising usability.

At some point, we've all encountered this in Studio Pro:

No access to entity 'Module.Entity' for user role 'User'

No access to entity 'Module.Entity' for user role 'User'

You open the Entity Access Rules and select all roles, create, delete and set read, write to all attributes.

Error gone. Problem solved. Or is it?

What have you done? For a problem with lock, you removed all the doors in the house!

It's surprising that many developers use Entity Access Rules every day without fully understanding what each permission controls.

Entity Access Rules

It is a set of rules that defines what an end user is allowed to do with the data. Simply, controlling which user can read, write, create and delete objects of an entity.

1. Create Controls if the selected role can create new objects of an entity.
2. Delete Controls if the selected role can delete objects of an entity.
3. Read Controls if the selected role can read the attribute of an entity.
4. Write Controls if the selected role can write the attribute of an entity.

Entity Access Rule Editor Section

Module Roles Section to select module roles to which the access rule will be applied.

Access Rights Section to select the access for the selected users.

XPath Constraint Section to specify conditions at attribute or association level using XPath.

Scenario 1

Administrator can be able to create, delete, read and write but User can only be able to read.

In above case we need to create 2 Access Rules, 1 for Administrator and 1 for User.

Scenario 2

All users can read the project details expect for certain sensitive attributes which holds client details, but it can be read only by the user who created it.

In above case we need to create 2 Access Rules, 1 for user who created project and 1 for other users.

Scenario 3

User can be able to read only the leave request submitted by them and should not be able to edit it once submitted.

In above case we need to create 1 Access Rule to create and read request.

Decision Tree

1. Create Should user need to create new records?
2. Delete Should this record ever be removed by this user?
3. Read Should user need to see this field?
4. Write Should user need to change this field?

What If?

1. What if there are no access rules specified? Mendix follows Principle of least privileges, so everything is restricted by default. So, the entity without any access rules can't be accessed by any user.
2. What if create access is provided but with no write access? Mendix treats create as a special case, it allows writing to attributes even when there is no write access. Write access will only take effect on data which is already there in database.
3. What if in Generalization, parent entity has no access rules, but child entity has access rules? In Generalization, access rules of parent entity is ignored and both accesses to parent and child is controlled through child entity. There is 1 special case where System.User entity access rules is always applied to its child entity.
4. What if I didn't give read access to one or more attributes? Attributes with no read access are not sent to client, when you do retrieve these attributes will be shown empty.
5. What if I create multiple access rules for same role? Access rules are additive, there is no condition that it'll select only one or execute in specific order. So if there is 1 read rule and 1 write rule for a role, now the role can perform both read and write.
6. What if cascading delete is configured to delete B when A is deleted but there is no delete access rule set for entity B? Even though cascading delete is configured, Mendix always respect entity access rules so cascade will fail and both A and B won't be deleted.

Conclusion

Entity Access Rule is not a bug fix mechanism, it is not there to make studio pro stop complaining.

Every checkbox represents a business decision, every permission affects data security.

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

Access Rules Introduction The access rules of an entity define what an end-user is allowed to do with objects of the entity. You can…