It seems that OutSystems in recent years has not been evolving the built-in security mechanisms on the platform, and the technology is being left behind by some other platforms with better authorization controls, such as Mendix.

This idea intends to propose better authorization controls over all objects, not only screens.

Now, the platform only provides some real basic security mechanisms via roles, which can be attached to screens or manually used to be granted, checked, or revoked. The built-in screen role checks are quite useful, and they work as expected. However, there is a huge burden on the developers to manually implement role security checks in all logics. Besides, there is not much control over database entity access unless tenants are also used.

OutSystems developers working with "low-code" features usually do not have extensive knowledge of how to improve security beyond the limits of the basic features of the platform. OutSystems also promotes openly the idea that a developer is not required to have much technical knowledge, but security proves the opposite. It's a constant issue to find security vulnerabilities after the login, where developers build web-react client actions that pass parameters, and those parameters are easy to tamper with. They simply "forgot" to add role checks, and there's a brand new security breach. So easily achieved.

In the face of the Achilles' heel of the platform related to security, much of which is in the manual hands of developers, it's proposed a new security authorization model:

A. Short-term measures:

1. Extend role checkboxes (by default) for each server logic, query, entity, ability to run a timer or BPT, or any other action that communicates or runs within the server. Those objects could have roles' checks as the screens, so developers will easily check and apply controls over those objects, avoiding plenty of manual work and the vulnerability of forgetting a specific action. Besides, when a logic is copied, the copy should inherit the roles' checks, promoting security across the whole app being developed.

2. Extend the warning messages to verify if all objects have the proper roles applied. Otherwise, state how many artifacts have undefined or anonymous roles.

B. Long-term measures:

1. It seems the security via roles is very basic. It's suggested that the platform provide a new authorization model based on objects with the right to access and the level of access. It means it's not enough to have access to an entity; it also requires controlling which information can be accessed within that entity and the level of power, such as whether the user can only retrieve or view data, update, or delete it as previously authorized.

2. Improve client-side security by implementing a built-in model of authorization for client actions and improving, via cryptography or another means, how parameters are exposed.