Show TOC

Secure Programming GuideLocate this document in the navigation structure

The secure programming guide introduces topics that developers should note.

Input Validation

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.

Output Encoding

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 UI development toolkit for HTML5 (SAPUI5). There are methods for encoding HTML, XML, JavaScript, CSS and URI components.

All controls in SAPUI5 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.

Note Using an XMLView with application controlled secure HTML content together with standard SAPUI5 controls (other than HTML and XMLView) containing potentially unsecure data is also safe. Only untrusted HTML content is critical.

For more information on SAPUI5 HTML code cleanup, see HTML5 Sanitizer.

URL Validation

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, SAPUI5 offers an URL validator, which can be used to validate whether a URL is well formed and properly encoded. It also contains a configurable whitelist to restrict URLs to certain protocols or certain hosts. Initially, the whitelist only checks for the http, https, and ftp protocols, but nothing else. Applications should define their own whitelist.

Cache Settings

The application has to take care that caching of data is disabled by setting appropriate HTTP headers on the server-side.

Static resources from SAPUI5 or from the application are not security relevant and are excluded from this rule, so they can safely be cached on the client.

User Management / Authentication

SAPUI5 does not provide any authorization or user management. An application, which implements such facilities based on SAPUI5 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.

Local Storage

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.