OutSystems Security Specialist cheat sheet

OutSystems Platform authentication is configured per environment in Service Center; the active authentication mode applies to all end users of that environment, not per application.

Built-in authentication modes: Platform (OutSystems-managed users and password policy), Active Directory, LDAP, SAML 2.0, and Azure AD (via SAML or OpenID Connect plugins); external modes delegate credential verification and return identity claims.

End-user authentication and IT-user (Service Center, LifeTime) authentication are configured separately; changing end-user auth does not alter back-office login.

SAML 2.0 federation requires IdP metadata (entity ID, SSO URL, signing certificate) in the environment and the OutSystems SP metadata registered at the IdP; assertion signing is validated against the IdP certificate.

Multi-factor authentication for end users is not native to Platform authentication; it is implemented through the external IdP (SAML/AD) or custom logic in the application's login flow.

Password policy for Platform authentication (minimum length, complexity, expiration, lockout threshold) is set in Service Center and enforced at login and password change.

Session variables declared in an application are per-session server-side state; they are not encrypted and must not hold secrets such as raw passwords or API keys.

Single sign-on across applications in an environment follows the environment's authentication mode; mixed modes require explicit configuration and are not automatic.

Login flow customization (custom login screens, extra checks) is done by overriding the login action; the built-in login must remain the credential verifier.

OutSystems authorization has two layers: role-based access at the module level (who can open screens/actions) and data-level access enforced in queries and aggregates (whose rows they see).

Roles are defined in the module; the built-in roles are Anonymous (unauthenticated), Registered (any authenticated user), and the module's custom roles. A user must hold a role to pass a screen's role check.

Screen and action role checks are declarative: each screen has a list of allowed roles; an unauthenticated user is mapped to Anonymous, so an empty role list denies everyone except users explicitly granted a role.

Server-side checks are mandatory: hiding a UI element with an If does not protect the underlying action; the action itself must check the role or the data must be filtered.

CheckRole built-in returns whether the current user has a role; Check generated actions are the preferred compile-checked form.

Data-level security is enforced by filtering aggregates/queries on the user's identity (e.g., UserId = GetUserId()) or by using entity-level role permissions; UI filtering alone is not access control.

Entity permissions in Service Studio (Create/Read/Update/Delete per role) are enforced for CRUD operations performed through the platform's generated actions and aggregates when the entity is exposed with permissions.

Expose REST/SOAP actions inherit the module's authentication; anonymous exposure requires explicitly setting the action to allow anonymous access, which bypasses role checks.

Granting a role in Service Center or LifeTime is environment-specific; roles granted in Development do not automatically exist in Production, so deployment must include role grants.

HTTPS is terminated at the front end (load balancer or IIS); OutSystems environments should enforce HTTPS for all end-user traffic, with HTTP redirect or rejection at the edge.

TLS configuration (protocol versions, cipher suites) is controlled by the underlying Windows/IIS or load balancer settings, not by Service Studio; TLS 1.0/1.1 should be disabled in favor of TLS 1.2+.

OutSystems supports HSTS via response headers configured at the front end; once enabled, browsers refuse HTTP for the max-age period, so enable only after HTTPS is verified.

Integrations to external systems (REST, SOAP) should use HTTPS endpoints; certificate validation must remain enabled - disabling it to accept self-signed certs is a production risk.

LifeTime and Service Center administrative traffic must be on HTTPS and restricted to management networks; back-office exposure on the public internet is a common finding.

SAML/OpenID Connect flows require HTTPS for assertion and redirect endpoints; the IdP's signing certificate must be current, and expired certificates break login for all users.

Database connections from OutSystems to SQL Server/Oracle should use encrypted connections where supported; connection strings are stored in Service Center configuration and must not be committed to source.

Mobile apps built with OutSystems use HTTPS for API calls; certificate pinning is not native and must be implemented in a plugin if required.

Sensitive data categories to classify: credentials, personal data (PII), financial data, health data, and secrets (API keys, connection strings). Classification drives storage, logging, and retention rules.

OutSystems does not encrypt entity attributes by default; encryption must be applied explicitly (e.g., using the Cryptography extension or database-native encryption such as TDE/Always Encrypted).

Passwords must never be stored in entities; use the platform's user management (Platform authentication) or a salted, slow hash (bcrypt/PBKDF2) via an extension.

Logging: Exception logs and general logs can capture request data; sensitive fields must be excluded or masked before logging, and logs must have restricted access and retention limits.

Data at rest: SQL Server TDE or Always Encrypted protects the database files; OutSystems-level field encryption protects specific columns even from DB administrators.

Data in transit: sensitive data must only travel over HTTPS/TLS; never place secrets in URL query strings, which are logged by proxies and browsers.

Secrets management: API keys and connection strings belong in Service Center configuration or an external vault, not in module code or site properties committed to source control.

Data retention and deletion: personal data should have defined retention periods; deletion must cover backups and logs, and audit trails of access to sensitive data should be retained.

Input validation: validate on the server (not only in the UI); OutSystems built-in validations and explicit checks in actions are the enforcement point, and client-side checks are advisory only.

Output encoding: use OutSystems' built-in encoding for HTML/JavaScript contexts; building HTML by string concatenation with user input creates XSS, and SanitizeHtml is required for rich text.

SQL injection: use aggregates and parameterized queries; dynamic SQL built with string concatenation of user input is the primary injection vector in OutSystems.

CSRF: OutSystems screen actions include anti-CSRF protection by default; custom AJAX endpoints or exposed REST actions must implement their own token or SameSite cookie strategy.

File uploads: validate content type and size server-side, store outside the web root where possible, and never trust the client-supplied file extension.

Error handling: show generic error messages to users and log details server-side; stack traces and SQL errors in responses leak internal structure.

Dependency and platform patching: keep the OutSystems platform version current and review third-party extensions; outdated components are a common vulnerability source.

Least privilege: application service accounts and database users should have only the permissions the application needs; IT users should not share accounts, and admin access should be limited.