Building secure applications with OutSystems
Table of contents
Most people in IT agree that application security is very important. This is easier said than done. For that reason, data breaches have increased in recent years. 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.
The OutSystems commitment to security
OutSystems is committed to continuously improving the security of the applications generated by our platform. Therefore, the OutSystems 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 10s describe the major vulnerabilities that can be found in web and mobile applications. Here's how OutSystems helps developers build applications that do not have such vulnerabilities.
OWASP Top 10 web application security risks - Final list 2021
Below you'll find the set of OutSystems capabilities that help you address each vulnerability as identified by OWASP's Top 10 Web Application Security Risks.
Broken Access Control (A1)
While this issue is 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 APIs enforce strong validation of user permissions, thereby ensuring that only users with the appropriate level of privileges can perform each operation.
Cryptographic Failures (A2)
To protect your data in transit, OutSystems allows you to enable SSL in your infrastructure, thus you can use HTTPS to ensure that any content will load over a secure connection. You can enforce the HTTPS security for the applications running in an environment, and enable HTTP Strict Transport Security (HSTS) for the whole environment.
If you need extra layers of compliance, and opt for a high-compliance OutSystems Cloud, you have enforced HTTPS communications for all web applications.
To protect your application-sensitive data, OutSystems enables integration with existing cryptographic pre-built components.
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.
Injection (A3)
By default, OutSystems escapes content before it is shown in the UI. When developers need to turn off the default escaping mechanism, OutSystems platform functions for encoding HTML, Javascript, SQL or URLs 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 or rendered on web pages.
We don’t stop there, either. The OutSystems development environment also issues design-time warnings about application patterns that can lead to code injection attacks. This ensures that developers are aware of them before the application is deployed.
Insecure Design (A4)
OutSystems allows developers to override the default secure code patterns for advanced customization scenarios. In this case, OutSystems security checks proactively warn developers of potential security issues as they publish their applications.
OutSystems generates standard applications from its runtime, enabling standard security assessment tools, such as static code analysis.
Security Misconfiguration (A5)
OutSystems Cloud infrastructures are automatically provisioned, configured, and tuned for high performance, security, and reliability. The physical infrastructure of the OutSystems Cloud is hosted in the secure data centers of Amazon Web Services.
If you need extra layers of security and compliance, you can opt for the OutSystems Sentry offer.
For self-managed deployments, OutSystems provides system administrators with clear and concise instructions on how to make the platform installation secure. Additionally, OutSystems includes a set of capabilities that enable you to define and implement the security controls required by your applications.
For both exposure and consumption of SOAP Web Services, OutSystems escapes XML parsing. Additionally, to help you protect your applications from XML External Entity attacks, OutSystems supports the use of the latest deserialization and XML processor library versions, and SOAP 1.2.
Vulnerable and Outdated Components (A6)
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 the customers’ operations and business.
This policy describes the OutSystems response to vulnerabilities that might affect customer applications. Security fixes are proactively applied in OutSystems Cloud.
Identification and Authentication Failures (A7)
By default, OutSystems ensures that:
- Session identifiers aren't sent in URLs
- Sessions time out at their expiration time
- All password handling uses strong cryptographic algorithms
Also, OutSystems ensures that the session identifier is transparently changed on each login, and validates this on every request, thus preventing session fixation attacks.
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, administrators can enable the secure flag in cookies, which makes Web browsers that support this flag to send secure cookies only when the request uses HTTPS.
Additionally, OutSystems provides built-in protection mechanisms against brute force attacks for the application end users and IT users.
Software and Data Integrity Failures (A8)
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.
Security Logging and Monitoring Failures (A9)
OutSystems tracks the details of every access to application screens. These logs include the component and screen accessed, which end users accessed it, when the access occurred, and exactly which node served the screen.
OutSystems also logs all access to external systems through web services, custom integration logic, or web service requests to applications running inside the platform. The logs keep a record of who made the request, the request’s target, the method called, how long the request took, and the exact time of the request. This enables you to track down any security issues efficiently.
Customers who choose to manage their own OutSystems installation benefit from the OutSystems standard runtime architecture to leverage their know-how and tools for logging and monitoring all system components.
OutSystems Cloud customers benefit from the logging and monitoring capabilities bundled in the service with a choice between the secure baseline of the standard configuration and the more advanced OutSystems Sentry offer.
Server-Side Request Forgery (SSRF) (A10)
OutSystems enables integration with external systems that you can statically configure. For example, when using the development environment to consume a third-party REST API, you must explicitly set the service's external fully qualified domain name (FQDN) as the base URL. This address can then be overwritten with a static configuration for each environment.
In case you need a more dynamic way of setting third-party addresses, OutSystems recommends using server-side data from the database or site properties to build the FQDN instead of relying on external data. If you really need external data, such as a URL shared on demand by a third-party service, make sure your applications validate that URL. For example, check the FQDN against a predefined list of valid, allowed third-party addresses. Then, use the OnBeforeRequest event action to set the customized base URL. Any time you want to make sure you only use static addresses throughout all your services, check all your OnBeforeRequest and make sure the base URL is not being customized there.
OWASP Top 10 mobile application security risks - Final list 2016
Below you'll find the set of OutSystems capabilities that help you address each vulnerability as identified by OWASP's Top 10 Mobile Application Security Risks.
Improper Platform Usage (M1)
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 our generated code complies with all Android and iOS specifications.
Additionally, the AppShield add-on includes root and jailbreak detection, blocks emulators, and identifies the permissions enabled on the device.
Insecure Data Storage (M2)
OutSystems provides you a set of pre-built components, such as the Key Store plugin or the Ciphered Local Storage plugin, to handle the storage of sensitive data in the device.
The AppShield add-on blocks screen readers and keyloggers. It also provides a secure local storage mechanism that blocks the copying of data to another device.
Insecure Communication (M3)
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.
To add an extra layer of security on top of HTTPS communications, you can use the SSL Pinning plugin to prevent man-in-the-middle attacks.
Insecure Authentication (M4)
OutSystems includes a robust built-in authentication mechanism that keeps user authentication information encrypted within authentication cookies. You are able to adjust the authentication cache, idle, and expiration periods per environment according to your application requirements.
Insufficient Cryptography (M5)
You can use pre-built components, such as the Key Store plugin or the Ciphered Local Storage plugin, to encrypt the application sensitive data in the device.
Additionally, the AppShield add-on blocks the copying of local data and assures it’s properly encrypted, includes repackaging protection, and ensures the security mechanisms can’t be removed from the app.
Insecure Authorization (M6)
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.
Client Code Quality (M7)
As visual application models translate into standard code-React.JS for the device, .NET for the backend-OutSystems uses secure code patterns that protect applications from common vulnerabilities.
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. Additionally, OutSystems provides a set of sanitization functions that developers can use in advanced scenarios to avoid code injection.
Additionally, the AppShield add-on includes code injection protection, repackaging detection, and verification of the application signature. It removes debug information from the application code, and blocks debugger and emulator access. Also, it allows the report of security controls and device anomalies to application code for specific handling.
Code Tampering (M8)
To prevent code modification of the apps via malicious forms, the AppShield add-on includes root, jailbreak, and repackaging detection. Also, it blocks debugger and emulator access.
Reverse Engineering (M9)
The AppShield add-on includes code obfuscation, and blocks debugger and emulator access, thus preventing reverse engineering of your mobile app.
Extraneous Functionality (M10)
Using OutSystems built-in application debugging capabilities during the development and testing stages reduces the need of creating extraneous code for testing and debugging purposes. This reduces the risk of deploying extraneous code to production.