The secure programming guide introduces topics that developers should note.
From the application point of view, the validation of user input must be done on the server and, optionally, on the client. This can be achieved by using two-way data binding and model types.
From the control point of view, the input of control properties must be validated, so that integer properties only accept integers and enumeration properties only accept an existing enumeration value. While this sounds obvious, in JavaScript it is not. The type system of JavaScript does not do type validation on assignment.
All data sent from the server must be properly output encoded according to the context they are contained in. For more information, see Cross-Site Scripting.
Content, which is created on the client side either for display within the browser or for data transport, needs to be properly output encoded with the encoding methods provided by OpenUI5. There are methods for encoding HTML, XML, JavaScript, CSS and URI components.
All controls in OpenUI5 libraries properly encode their data, except for HTML-control and XMLView. The latter two are explicitly built to display arbitrary HTML content. If applications use these two controls and provide unsecure HTML content, they have to check/validate the content on their own.
Using an XMLView with application controlled secure HTML content together with standard OpenUI5 controls (other than HTML and XMLView) containing potentially unsecure data is also safe. Only untrusted HTML content is critical.
For more information on OpenUI5 HTML code cleanup, see HTML5 Sanitizer.
URL validation should take place on the server-side when possible. In case URLs are entered on the client-side or are loaded from an external service, OpenUI5 offers a URL validator, which can be used to validate whether a URL is well formed and properly encoded. It also contains a configurable allowlist to restrict URLs to certain protocols or certain hosts. Initially, the allowlist only checks for the http, https, and ftp protocols, but nothing else. Applications should define their own allowlist.
The application has to take care that caching of data is disabled by setting appropriate HTTP headers on the server-side.
Static resources from OpenUI5 or from the application are not security relevant and are excluded from this rule, so they can safely be cached on the client.
OpenUI5 does not provide any authorization or user management. An application, which implements such facilities based on OpenUI5 has to make sure that SSL/TLS is enabled to prevent cleartext passwords sent over the wire. Applications must not store any logon information on the client.
The local storage of browsers is not a secure storage, so while it can be used for static data, like enumerations, applications must not store any user or application data within the local storage.