OutSystems Penetration Testing

Anonymous is OutSystems’ built-in role for users who haven’t signed in, and it isn’t just a screen setting. Every aggregate and server action that screen calls generates its own REST method, and giving the screen the Anonymous role opens that generated method to the same public access.

An Anonymous screen makes everything it calls Anonymous too

Every end-user role you create gets a matching CheckRole() function, and OutSystems’ own documentation confirms it is available in both client and server logic, with a lighter icon marking the client-side version. Restricting a screen through its Accessible by and Authorization settings controls who can open that screen, but restricting what a signed-in user can do inside an action still depends on someone adding an If element with CheckRole() to the server-side logic itself. We test every role against both surfaces: what a screen’s Authorization setting allows a user to open, and what the server actions and aggregates behind that screen will still execute or return if the same request is made directly by a user who was never meant to reach it.

OutSystems’ own security guidance is direct about where sensitive data belongs: never store sensitive data in Client Variables, which persist in the browser’s local storage and are shared across every app on that device, and never let one control the flow of the application, because both can be edited with ordinary browser tooling. The same discipline applies to aggregates. Current documentation confirms an aggregate retrieves only the attributes bound to a widget on the screen, and its own advice for sensitive data is to filter that aggregate with CheckRole() or GetUserId() rather than trust anything the client sends back, reinforced by a server-side check. We test what a screen’s generated REST methods actually return, independent of what the interface currently displays, and whether an aggregate’s filter can be bypassed by calling that method with different input.

An exposed REST API is only as secure as what runs in its authentication pipeline. OutSystems’ own pattern for token-based authentication for exposed REST APIs validates a JWT’s signature and its issuer, audience and expiry claims inside the API’s own logic on every request, and warns against trusting a token’s claims client-side or putting sensitive data in an unencrypted payload. The same platform lets developers extend an app with compiled .NET or Java code through an Integration Studio extension, or with custom JavaScript, and that code runs with the same trust as the platform’s own generated logic rather than under any separate sandbox. Whether the app runs on OutSystems Developer Cloud, OutSystems 11 Cloud or a self-managed OutSystems 11 install changes who owns the infrastructure beneath it, and OutSystems’ shared responsibility model names identifying vulnerabilities through penetration testing as a customer responsibility on its Cloud offerings. We test the application, roles, APIs and extensions you have built, whichever infrastructure they run on, and confirm the current rules of engagement with you during scoping.