Building secure applications with OutSystems

Table of contents

  1. OutSystems commitment to security
  2. OWASP Top 10 vulnerabilities

Most people in IT agree that application security is very important. This is easier said than done. For that reason, the number of data breaches have increased in recent years because It is easy for developers to overlook something or to develop an application that is secure by yesterday’s standards (but not by today’s). It is also easy for developers and infrastructure managers to forget that there is no checkbox or 1-click button to make a system secure.

OutSystems commitment to security

OutSystems is committed to continuously improving the security of the applications generated by OutSystems. Therefore, our platform features mechanisms that empower developers to build secure applications with minimal effort.

OWASP Top 10 vulnerabilities

The Open Web Application Security Project (OWASP) is a free and open software security community. The OWASP Top 10 describes the major vulnerabilities that can be found with web applications. Here's how OutSystems helps developers build applications that do not have such vulnerabilities.

Injection (A1)

By default, OutSystems escapes content before it is shown on the UI. When developers need to turn off the default escaping mechanism, OutSystems provides functions to encode HTML, Javascript, SQL or URLs, which will provide the appropriate escaping based-on their usage context.

On top of that, OutSystems provides sanitization functions for HTML, JavaScript and SQL. These functions allow developers to remove potential malicious content, coming or computed from user input, before it is stored in the database, and also before that content is rendered on web pages.

Going some steps further, the OutSystems development environment provides the developer with design-time warnings about application patterns that can lead to code injection attacks. This ensures that the developer is aware of them even before the application is deployed.

Broken authentication and session management (A2)

By default, OutSystems ensures that:

  • No username/user-id is included in the identification cookies.
  • Session identifiers are not sent in URLs.
  • Sessions time out at their expiration time.
  • All password handling uses strong cryptographic algorithms.

Likewise, OutSystems ensures that the session identifier is transparently changed on each login, and validates this on every request, thus preventing session fixation attacks.

Moreover, OutSystems provides developers with mechanisms to ensure that any content is transmitted over a secure connection. This can be enabled for an individual screen or integration endpoint, or grow to widen the scope, up to an entire app and API portfolio. This fine-grained level of control allows organizations to tweak the security to model your applications to fit your specific enterprise needs.

By default, all mobile applications have HTTPS enabled for all screens and integration. OutSystems also provides mechanisms that allow easy integration of applications with external authentication providers, thus minimizing the effort required to fit applications to an organization's ecosystem.

Cross-site scripting (A3)

Cross-site scripting (XSS) problems are handled similarly to Injection problems: OutSystems provides functions that encode and sanitize inputs. Unlike traditional development, our model driven approach allows real-time analysis, providing developers with warnings in the OutSystems visual editor at design-time to fix a security issue even before they deploy their applications.

Additionally, OutSystems provides mechanisms that allow architects, operators or administrators to define content security policies, that is, the domains from which application pages can retrieve resources (images, css, scripts, media). This setting can be configured for each environment, generically applying to all applications, or defined for specific applications. Limiting the sources from which the applications can load resources effectively mitigates XSS attacks that require loading a script from a malicious site.

Content security policy can also be used to prevent applications pages from being embedded in frames and thus prevent ClickJacking attacks.

Insecure direct object references and missing function level access control (A4, A7)

While these two issues are typically a problem related to the design and implementation of the applications, OutSystems enables developers to easily define which users are allowed to access which application resources such as:

  • Defining which user roles are required to access a given screen or which users have access to a given application
  • Disabling or hiding UI elements based on user permissions
  • Validating user permissions when actions are executed
  • Executing specific logic and accessing subsets of data depending on user permissions

All OutSystems management consoles and API enforce strong validation of user permissions, thereby ensuring that only users with the appropriate level of privileges can perform each operation.

Security misconfiguration and sensitive data exposure (A5, A6)

These two issues usually occur when the application is poorly designed or implemented. As far as OutSystems goes, it provides system administrators with clear and concise instructions on how to make the platform installation secure.

OutSystems includes complete error and exception handling in the generated code, and never exposes sensitive information to users and browsers. Careful exception handling applies also to encryption, authentication, authorization, auditing, and logging.

At the same time, OutSystems provides developers what they need to ensure that any content is transmitted over a secure connection. Similarly, it enables integration with existing cryptographic APIs to secure data stored in a database.

Cross-site request forgery (A8)

OutSystems includes in each page, by default, a token-based mechanism that ensures that the web page was generated for a given user in a given environment. The tokens are encrypted and signed with information that only the legitimate end user will have. When POST requests are issued to the server, the token is validated against the user making the request and if a POST request comes in without such tokens, or bearing an invalid token, the request is aborted without any changes to the underlying data.

Using components with known vulnerabilities (A9)

OutSystems regularly updates supported stack versions.

Unvalidated redirects and forwards (A10)

Like it does for injection or XSS, the OutSystems visual editor provides design-time warnings about application patterns that can lead to unvalidated redirect attacks. Additionally, OutSystems provides functions that allow a developer to ensure that the URL to which the flow is being redirected belongs to the same domain as the one where the application is running, thereby preventing potential unvalidated redirect problems.