4 min read time

SAPUI5 Common Pitfalls

by   in Cybersecurity

In the 2021.3 release the Fortify Software Security Research (SSR) team added support for SAPUI5 and OpenUI5.

What is SAPUI5 and OpenUI5?

SAPUI5 is a user interface development framework, mainly used for creating web applications in HTML5. OpenUI5 is a subset of the SAPUI5 framework that has been open sourced for all developers.

This post covers a couple of common pitfalls that developers of SAPUI5 applications fall into, leading to weaknesses and vulnerabilities in their code.

Cross-Site Scripting


One of the most common types of vulnerabilities introduced when developing dynamic web applications client-side is DOM-based Cross-Site Scripting (XSS). Luckily the developers at SAP made SAPUI5 safe for most typical use cases, by sanitizing the output of most common controls. The primary exceptions are certain unsafe controls and custom controls, as well as when regular JavaScript browser functionality is used in favor of SAPUI5’s more concise functionality.

Unsafe Controls


There are some specific controls in SAPUI5 that allow dangerous behavior, most notably the sap.ui.core.HTML and sap.ui.richtexteditor.RichTextEditor controls. In terms of security, the major difference between these controls is the default behavior.

The sap.ui.core.HTML control by default does not sanitize input and is therefore open to XSS if user-controlled information is passed to its content property as such:

new HTML({

    content: '<div>' + user_input + '<div>'


This can potentially be protected by setting the sanitizeContent property to true, or manually performing validation on the user input. We advise to not create dynamic HTML in this manner and instead safely extend an existing control.

The sap.ui.richtexteditor.RichTextEditor control similarly can be used to show dynamic markup, but RichTextEditor is really intended for user input and therefore by default escapes markup, but this can be disabled, as discussed below.

Custom Controls


One of SAPUI5's most powerful features is the ability to extend controls, giving you reusable components to easily use in various parts of your web app as if you were able to extend HTML itself. However, when controls are extended the framework needs to give the developer the power of choosing how the control should be rendered, which may allow attackers to insert malicious code into the DOM.

Controls as library functions

When creating a custom control, you are effectively making a separate reusable component, which means this code should be treated as a general library function to be used across multiple applications, if not at least multiple places within the same application. Since it is a reusable component, future application modifications or re-use in other applications may end up passing user-controlled information to the control. Therefore, it is best to treat any input into that control as user-controlled input, even if the application you are currently writing does not do this.

For example,

return Control.extend('DynamicControl', {

    metadata: {

        properties: {

            foo: { type: 'string', defaultValue: '' }



    renderer: {

        render: function (oRm, oControl) {

            try {

                eval(oControl.getFoo()) // UNSAFE

            } catch { }



    init: function () { }



Here we have an example of a new control with a property called "foo". As it is intended for this to be reusable, we cannot know if the foo property will NEVER be passed user-controlled data. So, when the render function passes oControl.getFoo() into the eval function, this could be user-controlled data being evaluated.

When writing custom controls, it is important to remember that any properties you retrieve from the control could be user-controlled.

Similarly, as you would in any other web application code, it is important to remember to validate input when writing information into the DOM. The RenderManager has different methods (depending on the version of SAPUI5) that allows you to write to the DOM when rendering. In older versions of SAPUI5 you could do:

render: function (oRm, oControl) {

    oRm.write('<div>' +  oControl.getFoo() + '</div>'); // BAD


This is vulnerable to XSS as oControl.getFoo() could be passed user-controlled data as mentioned above, and the write function performed no validation when rendering to the DOM. To fix this with older versions of SAPUI5 you would just change the function to writeEscaped as such:

render: function (oRm, oControl) {


    oRm.writeEscaped(oControl.getFoo()) // GOOD



This is very error prone, and so starting with SAPUI5 version 1.67, this should now be written as:

render: function (oRm, oControl) {


    oRm.text(oControl.getFoo()); // GOOD



And this would also be safe from XSS as the “text” function performs validation of markup.

Starting with v1.67, there is also a clearly stated “unsafeHtml” function that allows dynamically generating HTML via strings similar to the old “write” function. Therefore, the following would also be vulnerable to XSS:

render: function (oRm, oControl) {

    oRm.unsafeHtml('<div>' +  oControl.getFoo() + '</div>'); // BAD



Again, there is very little reason to use this unsafe functionality, and we appreciate that the developers have now made the unsafe functionality clearer.


SAPUI5 Misconfiguration: Unsanitized Editor


As mentioned above, the sap.ui.richtexteditor.RichTextEditor control is intended for user input and therefore has been engineered in the safest way, to validate markup by default. However, it is possible to disable this validation by setting the “sanitizeValue” property to false. This might be done in order to allow a greater range of inputs possible from the user but can lead to XSS.


new RichTextEditor({

    sanitizeValue: false, // UNSAFE

    value: input



In the above example, “sanitizeValue” has been specifically set to false, so if “input” is user-controlled then this is an XSS vulnerability.

SAPUI5 is a powerful framework for creating dynamic client-side applications and for the most part allows the user to work without much concern about dynamically creating unsafe websites, but as shown here there are a few exceptions that developers need to be aware of to keep their code and their users safe.  


  • By Peter Blay and Yash Shahani


Application security
Static Analyzer