Reactive Security Pitfalls and Best Practices

In Justin James' knowledge exchange, he discussed the important security concerns when using OutSystems Reactive as opposed to Tradition. In Reactive, the major difference is that client actions are executed on the client side using JavaScript and the server is only called through server actions or aggregates. Client variables are stored in the web browser, making them visible to anyone, including in plaintext through developer tools.

One major concern is the lack of an optimizer in reactive. Previously, aggregates in traditional programming could efficiently limit records exchanged between the client and server. However, in reactive, user lists could potentially expose sensitive information until a change occurs. Malicious users, ranging from those with ill intentions to merely curious individuals, could exploit this vulnerability.

To mitigate these security risks, several measures are recommended. Enabling the optimizer in OutSystems version 11.10 or later is crucial. Filtering data before returning it, either by removing unauthorized records or setting fields to null, helps prevent unauthorized access. Avoiding key logic on the client and moving important decisions, such as user permissions, to server actions enhances security. It is also advised not to send entities directly to CRUD operations but rather create a business logic layer that verifies roles and record ownership. Paying attention to screen roles and considering splitting screens based on role needs can further improve security. Finally, using GUIDs or similar unique and non-deterministic values for record IDs helps prevent unauthorized data access by anonymous users.

Overall, these measures aim to strengthen the security of reactive applications developed using OutSystems and mitigate potential vulnerabilities related to client-side execution, data exposure, and unauthorized access.