Access control
What the exam tests
Access control in OutSystems is role-based and enforced server-side. Roles are defined inside modules, granted to users or groups, and checked on screens, exposed integrations, and entity operations. The exam tests whether you can design permissions that hold even when a request does not come from your UI.
Core rules
- Module roles are the unit of authorization. Grant them to users directly or through groups; users inherit the union of permissions.
- Screen permissions are set on the screen for module roles. Hiding a link is not a permission; the screen itself must be protected.
- Exposed REST and SOAP methods have their own authentication settings. An anonymous endpoint bypasses login entirely, so enable it deliberately and validate input.
- Entity permissions are role-based CRUD rights. If a role can Update an entity, that role can update it from any server action, not only from the screen you designed.
- Use server-side checks such as the CheckRole system action before sensitive operations, and combine them with entity permissions.
- Groups simplify administration but hide effective access; audit the resulting role membership.
Worked example
A Manager-only refund action is exposed as a REST API. The developer grants the Manager role on the screen and hides the button for others, but leaves the API method anonymous. An attacker calls the API directly. Fix: require authentication on the method, call CheckRole('Manager') in the action, and restrict the Refund entity Update permission to Manager. Reasoning: the API is a separate entry point; screen-level controls do not protect it.
Traps
- Treating client-side visibility as authorization.
- Granting broad roles to service accounts.
- Forgetting that groups can grant roles indirectly.
- Leaving default anonymous access on integration methods.