Security
What the Security domain tests
The Security domain tests authentication, authorization, data protection, secure coding, API exposure, and tenant isolation in OutSystems applications.
Core rules
- Authentication establishes identity; authorization decides access. OutSystems separates end-user roles from IT roles. Assign end-user roles to business users and IT roles to platform operators.
- Enforce authorization at every entry point: screen roles, action roles, exposed service actions, and entity CRUD permissions. Hiding a button is not authorization.
- Use
Check<Role>built-ins in server actions that perform sensitive operations, because a service call or direct action invocation can bypass the screen. - Validate and sanitize input on the server. Use parameterized queries or aggregates; never concatenate user input into SQL. Encode output to prevent XSS.
- Protect data in transit with HTTPS and secure cookies. Keep secrets out of client-side variables and exposed site properties.
- For REST or SOAP integrations, authenticate the caller and expose only the actions the contract needs. In multitenant apps, verify tenant isolation on every query.
Worked example
A screen that deletes a Customer is visible only to Managers, so the developer sets the screen role to Manager. That is not enough: the delete server action is also called by a REST service. The action must check the Manager role and the entity's Delete permission must be restricted to Manager. Reasoning: the screen role protects the UI path; the action check protects every path; entity permission is the last line of defense. Defense in depth is the exam's expected pattern.
Traps
Trusting client-side role checks, exposing entities with broad CRUD, building dynamic SQL from input, putting secrets in client variables, and leaving integration endpoints unauthenticated.