Skip to main content





Application security overview

  • Edit
    Collaborate with us
    Edit this page on GitHub
  • Download the whitepaper version of this document by clicking here.

    OutSystems is committed to continuously improve the security of the applications generated by our platform.

    To achieve the highest level of security for your OutSystems applications, we need to consider these two levels:

    • Ensure the developed applications are secure
    • Ensure the applications run on a secure runtime environment

    OutSystems is designed to accelerate the development of secure applications and their deployment in a secure runtime environment, granting the generated applications a default level of protection against the common web and mobile application vulnerabilities.

    Because some of the security capabilities depend on the type, context, and user experience of your applications, make sure you define and implement the needed security controls accordingly. It's up to you to:

    • Decide the trade-offs between security and usability
    • Implement the security capabilities that depend on the semantics of your application

    This article describes the security capabilities that OutSystems provides by default to your applications, and provides you additional guidance on how to develop secure applications that run on a secure environment.

    Additionally, this article describes the set of post-development mechanisms that you can use to perform security checks on the built applications before going to production.

    See also how OutSystems helps you address the vulnerabilities identified by OWASP.

    What OutSystems provides by default

    Secure application code

    Applications built with OutSystems benefit from an extra level of security in the application code itself. As visual application models are translated into standard .NET code, OutSystems uses secure code patterns that protect applications from the common web and mobile application vulnerabilities.

    OutSystems high-level building blocks automatically include secure code patterns that protect applications from the common web and mobile application vulnerabilities. As developers work at a higher level of abstraction, the generated applications automatically embed many security protections, such as protection against injection or automatic CSRF protection.

    By default, OutSystems escapes content before showing it on the UI. Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) resolves reflected and stored XSS vulnerabilities.

    The OutSystems approach to mobile is a React-based hybrid client built on top of the Open-Source Apache Cordova library. Special care is taken to guarantee that the generated code complies with all Android and iOS specifications.

    Secure session data

    OutSystems includes built-in protection against session fixation attacks. It ensures that the session identifier is transparently changed on each login, and validates this on every request, thus preventing session fixation attacks.

    OutSystems serializes and deserializes session data using a built-in anti-tampering JSON deserialization mechanism. This mechanism compares incoming JSON data with predefined application models and performs strict type verification during deserialization. Additionally, it runs a salted hash-based algorithm over the serialized session data to validate potential tampering before deserialization.

    Secure authentication mechanism

    The OutSystems built-in authentication mechanism keeps user authentication information encrypted within two authentication cookies. This mechanism is configurable per environment to meet different security requirements.

    Also, OutSystems provides single sign-on capabilities by default for modules where cookies are enabled. After authenticating in one of the applications, end users can access all other applications without having to authenticate again.

    Role-based access control for applications

    OutSystems role-based access control restricts access to the application’s pages depending on specific application-level roles. Developers define application-level permissions for roles using visual building blocks.

    Once users are registered to use an application, role-based access control ensures that only authorized users are allowed to perform specific business functions.

    Role-based access control for IT users

    IT team responsibilities are defined based on roles, and users can specify what each role can do in each environment. For example, the developer role might not be allowed to push applications to production, while the operations role can.

    Protection against brute force attacks

    OutSystems provides built-in protection mechanisms against brute force attacks for the application end users and IT users. You can adjust this mechanism to your business needs, such as the number of failed login attempts before a backoff or blocking period.

    See Protection against Brute Force Attacks for further details on this mechanism and how to configure it.

    Enforced HTTPS

    OutSystems mobile apps communicate with the server endpoints over HTTPS and therefore encrypts all communication. Any attempt to use one of these endpoints over HTTP issues an error on the server-side.

    If you need extra layers of compliance, and opt for a high-compliance OutSystems Cloud, you also have enforced HTTPS communications for web applications. Alternatively, OutSystems allows selective enforcement of HTTPS security.

    Application auditing

    OutSystems provides you built-in monitoring tools that collect and present data about the running applications.

    You can view the logs and status of a specific environment, such as application logs and errors, screen requests, integration calls, business processes, and security audits.

    System activity auditing

    You can monitor the tasks performed by IT users in the infrastructure. This ensures traceability in your infrastructure, and that you can follow up when problems arise.

    Tracked events include:

    • Storing a new version of an application or component
    • Deleting an application or component
    • Deploying a new version
    • Modifying user configurations
    • Logging in to the system

    Furthermore, system audits and version control subsystems of the OutSystems platform allow auditors to identify when a modification to an application was applied, and by which user. The version control system even allows the inspection of the exact content of that change, using the OutSystems Service Studio visual difference and merge tool.

    Vulnerability management

    OutSystems constantly monitors for vulnerabilities in the product and the generated code, using a continuous delivery approach to constantly release incremental value with minimal disruptions to our customers’ operations and business. Keeping your OutSystems infrastructure updated enables you to benefit from the latest features and fixes.

    This policy describes OutSystems response to vulnerabilities that might affect the customers’ applications. Security fixes are proactively applied in our OutSystems Cloud.

    Develop secure applications

    On top of the default level of security that OutSystems grants to your applications, there are additional aspects that you must consider during application development to ensure that the developed applications are secure.

    Define and implement the application permissions model

    Use the OutSystems built-in role-based access control to restrict or allow end users to access specific screens and operations of your application. Aside from the two default roles available (Anonymous and Registered), you can create new custom roles to accommodate your permission-model requirements.

    Use the built-in actions and functions available for each role to validate the permissions of end users to screen elements or actions of the application.

    Implement application logging

    Application logging plays an important role in security, as it allows you to track temporal information on significant events.

    When designing application logic, make sure that you log relevant information to track the action flow. By logging events such as end-user application logins, access control failures, or server-side input validation failures, you collect sufficient end-user context to identify suspicious or malicious accounts. The logged information is available at runtime in the Service Center console.

    See Audit Trail for further information.

    Implement proper error handling

    Handling errors correctly is very important to the security of an application. When applications don’t handle errors properly, attackers might take advantage of this flaw and retrieve sensitive data they can use for exploitation.

    When designing the logic of your application, make sure you correctly handle code exceptions. Some recommendations:

    • Minimize unforeseen exceptions, so you can control the error message received by the end user. A stack trace may reveal sensitive data about your application, such as the application server, frameworks, or libraries.

    • Don’t include sensitive data or too much information in an error message.

    Secure your advanced code customizations

    When using OutSystems building blocks to design your application screens and logic, such as Aggregates or UI widgets, your application translates them, by default, into secure code patterns against the most common vulnerabilities.

    However, when developers need to override the default secure code patterns for advanced customization scenarios, they receive design-time warnings for potential injection flaw patterns, along with guidelines to fix them. This ensures that developers are aware of these patterns before deploying the application.

    Service Studio design-time warnings

    The Sanitization API provides a set of actions that developers can use in advanced scenarios to avoid code injection in HTML, JavaScript, and SQL snippets.

    Increase the security level of specific HTTP requests

    When SSL is enabled for the environment, you can enforce HTTPS security for specific applications or for the whole environment.

    However, for scenarios where part of your application does not require SSL, OutSystems allows you to increase the security level of HTTP requests during the design phase for individual screens, UI flows, or integration endpoints. Do keep in mind that disabling SSL goes against many compliance and security standards in the industry.

    Encrypt the application sensitive data

    You should ensure that the sensitive data of your application, such as usernames, passwords, tokens, or certificates, is protected.

    As an example, see how the CryptoAPI component encrypts sensitive database fields using an envelope encryption technique.

    For mobile applications, you can use components like the Key Store Plugin or the Ciphered Local Storage Plugin to handle the storage of sensitive data in the device.

    See Securing application data and How to fully encrypt your sensitive data for further details.

    Validate the communication between server and mobile device

    The SSL pinning technique validates the origin of the information your application receives by checking if the certificate used to encrypt the information in the communication channel matches the one you expect.

    You can use the SSL Pinning Plugin to add this extra layer of security on top of HTTPS communications, preventing man-in-the-middle attacks.

    Harden the protection of mobile apps with AppShield

    OutSystems AppShield is a subscription add-on that automatically adds an extra layer of security to your native Android and iOS apps. Fully integrated with Mobile Apps Build Service (MABS), OutSystems AppShield builds and adds protection at runtime and at rest.

    Features like root and jailbreak detection, code injection protection, screenshot protection, repackaging detection, and many others, are included. See the AppShield documentation for the full list of features and how to protect your mobile app against attempts of modification and misuse.

    Follow development best practices

    Architecture Dashboard is an OutSystems tool that enables IT leaders to visualize complex cross-portfolio architectures and identify problems while also helping developers follow best practices and avoid common pitfalls. Based on automatic code and runtime performance analysis, it recommends solutions that help you to improve the performance, security, architecture, and user experience of applications. See this video for an overview of the Architecture Dashboard.

    Use the Architecture Dashboard to validate and fix the security patterns identified in your applications.

    Also, make sure you follow other available development best practices to protect the applications from security vulnerabilities. Some examples:

    Ensure a secure runtime environment

    With your applications developed according to the security standards and best practices, there are still additional security configurations at the environment level that you should perform to guarantee the highest level of security of your applications.

    Consider setting a password rotation policy for administrator users

    During the OutSystems setup process, you are required to set the password for the platform administrator users.

    In case you need to comply with your company policies by setting a password expiration process, OutSystems allows you to change these administration passwords.

    In OutSystems, you have two administrator accounts:

    • The Platform Server administrator account to access OutSystems management consoles (LifeTime and Service Center). You can change the password for the Platform Server administrator account in the Configuration Tool.

    • The Users application administrator account, where you manage the applications’ end users for each environment when using the default authentication method. See here how to change the password for the Users administrator account. Make sure you change the administrator account of the Users application in each environment.

    Choose the right authentication method for your end users

    Choose the end-user authentication method that best fits your applications.

    You can opt to authenticate your end users using the identity provider of your choice, which enables you to have a strong centralized authentication method across your ecosystem (OutSystems and non-OutSystems). OutSystems supports the following external methods for end-user authentication:

    • Active Directory
    • LDAP (Lightweight Directory Access Protocol)
    • SAML 2.0 (Security Assertion Markup Language)
    • Azure AD (Azure Active Directory)
    • Okta

    See End Users Authentication for further details.

    Alternatively, you can stay with the default authentication method, Internal authentication, where the end user information is stored in the OutSystems database. If you want to implement strong authentication on top of the default internal authentication method, see the Touch ID Plugin, available in OutSystems Forge, which allows in-app user authentication using fingerprint or face id sensors for your mobile apps. For web applications, you can find some sample components in OutSystems Forge as a basis for your implementation, such as Google reCAPTCHA Web or Google Authenticator.

    Choose the right authentication method for your IT users

    In OutSystems, you manage your IT users (developers, testers, operators) using the LifeTime console. By default, when these users access OutSystems, they're authenticated using the built-in authentication mechanism.

    However, if you already have your own authentication systems and you want your IT users to only have one account to authenticate in all of them, you can configure IT users to authenticate using an external authentication provider. OutSystems supports the following external methods for IT user authentication:

    • Active Directory
    • LDAP (Lightweight Directory Access Protocol)

    OutSystems also gives you the capability to implement your own authentication plugin.

    As an additional note, see the SAML Platform Authentication component, available in OutSystems Forge, as a sample implementation that allows your OutSystems tools, such as Service Studio, Integration Studio, Service Center, and LifeTime, to integrate with most common identity providers that support SAML 2.0 protocol for authentication purposes.

    Secure data in transit

    Make sure that data in transit is encrypted using secure communication channels. An SSL certificate binds a cryptographic key to an organization’s details. When such a certificate is installed in an application server, the HTTPS protocol is activated. This creates an encrypted channel between your web server and your visitor’s web browser, allowing private information to be transmitted without eavesdropping or tampering.

    By enabling SSL in your infrastructure, you can use HTTPS to ensure that any content loads over a secure connection.

    Having SSL enabled, you can:

    Your OutSystems Cloud environments are automatically deployed with default valid SSL certificates with the domain. It's possible, and highly advisable, that you customize your environment hostname and SSL certificate. Make sure you change your domain prior to deploying any apps to production. For specific cases where the implementation depends on the certificates, such as SSL pinning, you must perform this change even before developing the application.

    Additionally, as TLS protocol versions are constantly changing and evolving, you should restrict the usage to the most recent release. To do so, contact OutSystems Support and request the deactivation of unnecessary and old versions. Please note that you are only allowed to customize the versions that are used, but not the cipher suites used in them.

    Secure data at rest

    Besides encrypting the application sensitive data, you must also secure your infrastructure-level data at rest. In OutSystems Cloud environments, you can activate the database encryption service, which includes the underlying storage for database server instances, its automated backups, and snapshots.

    Apply Content Security Policy

    CSP provides you a standard way of declaring approved origins of content so browsers will allow loading. Apply Content Security Policy (CSP) to your environments to protect your applications from code injection attacks.

    Enable secure session cookies

    Cookies may contain sensitive information that shouldn't be accessible to an attacker eavesdropping on a channel.

    To prevent browsers from sending cookies over an unencrypted channel, enable the secure flag in cookies. This option adds the Secure attribute to all cookies generated by the platform. Web browsers supporting the "secure" flag only send cookies having this flag when the request uses HTTPS.

    Encrypt web apps view state

    The view state is used by the OutSystems underlying technology (ASP.NET). This mechanism is used to preserve the client-side state of a web page when a postback occurs. The view state stores the values and controls of the page between requests.

    As the page's view state can contain sensitive information, such as the inputs a user added on a form, it's a good practice to encrypt the view state of web apps.

    Restrict access to management consoles

    You can restrict access by IP address to the OutSystems management consoles and connections from the development tools by configuring an internal network. Cloud customers must submit a request to OutSystems Support to set this configuration, indicating the internal range of IP addresses allowed to have that access.

    Perform post-development security checks

    Performing security checks after the development phase is a way to catch vulnerabilities that were not detected during the development phase.

    Run static application security testing

    OutSystems generates standard code from the visual application models, enabling you to run static application security testing (SAST) on the generated code.

    See how to perform these tests to your OutSystems application, from exporting the source code to analyzing the results.

    When reviewing static code analysis results, keep in mind that each analysis tool reports on findings without a proper context. To understand those findings in their proper context or detect false positives, you can contact OutSystems Support.

    Perform penetration testing on your applications

    By performing penetration testing, you get a thorough understanding of the business risks posed by your applications.

    You can perform penetration tests or vulnerability scans as long as they're limited to your own OutSystems Cloud or self-managed infrastructure.

    When reviewing penetration test results, keep in mind that each framework reports on findings without a proper context. To understand those findings in their proper context or detect false positives, you can contact OutSystems Support.

    • Was this article helpful?