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.
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.
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.
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.
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.
Increase the security level of specific HTTP requests
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.
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:
- Protecting OutSystems apps from code injection / Cross Site Scripting attacks
- Protecting OutSystems apps from authentication vulnerabilities
- Protecting OutSystems apps from access control / permissions vulnerabilities
- Protecting OutSystems apps using encryption and SSL/TLS
- Protecting OutSystems apps from Cross Site Request Forgery attacks
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)
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:
Enforce the HTTPS security for specific applications or for all applications running in an environment.
Enable HTTP Strict Transport Security (HSTS) for the whole environment.
Your OutSystems Cloud environments are automatically deployed with default valid SSL certificates with the outsystemsenterprise.com 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.