This document describes process of running static application security testing (SAST) on the code generated by OutSystems, from the export of source code to analyzing the results.
When dealing with the static code analysis process, there are some architecture considerations to be taken into account, namely when using OutSystems cloud or self managed deployments, and web or mobile applications. The description and process of implementing SAST for Web applications can be found below.
Extracting web and mobile backend application source code
From OutSystems cloud environments
To retrieve web apps, reactive web apps, and mobile backend source code, you'll need to contact OutSystems support team.
From self managed environments
With OutSystems, upon publishing code is first translated into the native language before it's compiled and deployed to IIS. As such, there is a folder on the Platform Server where the source code is stored. Customers can take advantage of this and run SAST tools against this. The source code can be found at
These instructions work for both traditional web apps, reactive web apps and mobile back ends.
As a best practice when frequently running static code analysis, consider licensing an additional production environment, and use it to run your static code analysis.
Retrieving mobile app source code
To retrieve a mobile application's source code, contact OutSystems support team and provide the following information on the case:
- Application name and version
- Exact time of the build (including the timezone)
- Hostname used on the build (address of the environment that requested the build)
- Mobile platform (Android or iOS)
Note: The requested build must be less than 7 days old. Otherwise, please generate a new build.
Prepare the mobile app source code for analysis
OutSystems support will either enable you to retrieve the mobile app source code from your environment or provide you with a
In both situations, you'll need to open the
source.tar.gzfile and, with a unpacking tool (like 7-Zip or WinZip), extract only the
While extracting the folder, errors stating "Can not create symbolic link" will occur. They can safely be ignored and they won't affect the integrity of the source code.
Apart from the
source.tar\source\platforms\ios folder, all the remaining contents of the
source.tar.gzfile should be discarded and not subjected to the source code analysis. They contain auxiliary files that are only necessary for OutSystems Mobile Apps Builder to generate the build and aren't a part of mobile app's source code.
When reviewing static code analysis results, it's important to keep in mind that each static code analysis tool will report on findings without a proper context. These findings must be reviewed to detect false positives and experts in OutSystems development shall be consulted to help on understanding those findings in the proper context.
Following are some examples of such findings and why they should be considered false positives.
Code injection: improper neutralization of directives in dynamically evaluated code (eval injection)
<script> tags, hence the potential vulnerability.
<script> inline tags. The usages are trusted and ok to be executed. Therefore, OutSystems has added the unsafe-inline and unsafe-eval policies to our default Content Security Policies directives.
These potential threats in the form of inline scripts would only be possible to execute if the application is not protected against XSS attacks. OutSystems is by default well protected against this and customers need to specifically allow inline expressions in order to open up for this attack. These openings are accompanied with security warnings at design time, in the Service Studio (OutSystems IDE).
In order to increase the security level, there is a mechanism described in Apply Content Security Policy article.
More information can be found here.
Credentials management: use of hard-coded passwords
Details: Static code analysis tools typically raise a flag when the password word is anywhere in the code.
The files where this flag is normally raised are, SQL Server, Oracle, and DB2 database connectors. None of these files have hard-coded passwords, but they do have variables named password. All values for the password variables are obtained dynamically.
This can be verified using decompiler tools and inspect the flagged DLL files to confirm that there are no hard-coded passwords there.
Cross-site Scripting (XSS): improper neutralization of script-related HTML tags in a web page
Details: Most of the flags will be raised on file osjs.js. This happens because OutSystems uses the jQuery query selector $, which is known for being vulnerable to XSS in some earlier versions of jQuery, including the one that the platform uses.
OutSystems makes its own implementation of $, protecting it against XSS, so this is likely a false positive.
More information about this can be found in this article.
Cryptographic issues: use of a broken or risky cryptographic algorithm
Details: This issue is typically flagged when default random generators or hashing functions are used, assuming that those functions are being used for cryptographic or security related operations. This may not be the case and using a random() or hash() is perfectly fine if the results of those functions are not used to encrypt or authenticate content.
Since OutSystems doesn't use weak functions for cryptographic ends, this should be considered a false positive. This finding is commonly flagged when analyzing the file OutSystems.RuntimeCommon.dll, which contains some random and hash functions but they're not used for cryptographic or security-related operations.
Improper neutralization of special elements used in an SQL command (SQL injection)
Details: OutSystems doesn't explicitly perform SQL Injection validation on all SQL queries that are executed by applications. However, the platform has a SQL sanitization built-in action available that allows developers to validate all user inputs that are going to be used in SQL statements.
Therefore, it's the developer’s responsibility to guarantee that all user inputs are sanitizing before being used in a SQL statement. Moreover, OutSystems displays a warning at design and compile time when a pattern that may introduce a SQL Injection vulnerability is detected.
Sensitive data exposure
Details: "alert(…)", “confirm(…)” and “prompt(…)” creates a pop-up that can expose sensitive information.
All usages of the aforementioned functions has been validated for possible sensitive data exposure. The platform makes use of the functions for error handling, not exposing any sensitive data.
shred.bundle.js flagged as a potentially vulnerable library
Details: Some Static Code Analysis tools may flag OutSystems as having a vulnerable shred.bundle.js library.
OutSystems uses swagger-ui 2.0.0, which is present in all applications that expose REST web services. One of its dependencies is shred.bundle.js, which uses the window.postMessage() API with the wildcard keyword (*) in the targetOrigin argument.
Best practices recommend avoiding the use of the wildcard when dealing with sensitive information, as there is no way to guarantee that the data is only accessible to the intended recipient pages, therefore allowing cross-domain messaging access.
Therefore, even though this vulnerability is still present in shred.bundle.js, the use of the mentioned API in such conditions by OutSystems is harmless, as no sensitive information is passed on.
Cross-site scripting: DOM
Details: Some static code analysis tools may flag
plugins/cordova-plugin-inappbrowser/tests/resources/local.html as being susceptible to DOM-based cross-site scripting.
This file isn't part of the final build, nor the build system, hence it can be safely be marked as a false positive and/or excluded from the testing scope.
Support from OutSystems
OutSystems Support and Security Teams are ready to discuss the findings of the static code analysis with customers under the following conditions:
- We expect customers to involve one of their trained OutSystems engineers to do a preliminary analysis of the report, and report to OutSystems Support only the issues inherent to the product.
- The list of issues reported to OutSystems Support should exclude issues that can be fixed by developers by changing the applications.
OutSystems support reply may include:
- A reasoned identification of false positives;
- A reasoned adjustment of severity based on the specifics of the technical environment;
- An escalation of eventual product defects to
- The classification of an issue as "to be solved in the application". Furthermore, the following tables can help understand the responsibilities and expectations by deployment model:
OutSystems Cloud environments