Browser security comprises several topics such as cross-site scripting, clickjacking, and local storage.
Browsers also offer possible attack vectors, such as Cross-Site-Scripting (XSS). The application has to take care of these.
Cross-Site-Scripting has become the most prominent security issue of web applications within the last years and also the most dangerous one, as it allows several ways of exploitation. Once malicious code is running within your browser, it can be used to steal your session cookies, to trigger requests within the current session, or even to exploit a known browser vulnerability to do native code execution.
For SAPUI5 applications, XSS vulnerabilities can exist on different levels:
Within the HTML page or custom data transports sent to the browser from the server
Within the HTML renderers of SAPUI5 controls
SAPUI5 can only prevent cross-site scripting in the processing and rendering of controls. For that purpose, input validation exists for all typed element properties and output encoding is done in the renderer class of controls. However, there are exceptions for controls which are especially built to include arbitrary HTML, for example, sap.ui.core.HTML.
Proper output encoding of all content embedded in the HTML page itself
Encoding JSON or XML data sent to the client
Secure processing of the JSON/XML data
Security of custom controls provided by the application
For more information, see Cross-Site Scripting.
Clickjacking, or UI redressing, tricks the user into triggering actions within an application by redirecting clicks. This is done, for example, by using an invisible iFrame which is positioned above a fake UI. When the user clicks on something on the fake UI, the content of the invisible iFrame handles the click.
SAPUI5 provides a way to prevent clickjacking since version 1.28.0. This has to be configured, as needed, by the application.
HTML5 offers a lot of new functionality, which also brings a lot of potential new security issues. This is just an overview of some of the new features and possible security issues when they are used.
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.
SAPUI5 is using the local storage of the browser for the history-capability of dropdown boxes and combo boxes.
While more and more browsers are supporting WEBGL by default, WEBGL allows accessing the graphics API of the computer on a very low level, which may also lead to low level exploits. This is the main reason Internet Explorer has no support for WebGL at all, Microsoft recently stated, that they are not going to support WebGL as they think it can not be implemented in a secure way.
SAPUI5 is currently not using WEBGL.
While WebSockets offer great new possibilities for the client/server communication of web applications, there have been many security issues rising while the first implementations were done by the browser vendors. Standardization of WebSockets has reached a stable state with RFC 6455 and is now implemented beginning with Chrome 16, Firefox 11 and Internet Explorer 10. Even if the browser implementations themselves prove to be secure, using WebSockets may require additional security measures on the client.
SAPUI5 is currently not using WebSockets.
This is another great feature in the HTML5 area, which can lead to massive security issues when not used correctly. postMessage allows inter-window-communication between windows from different domains. So basically this opens a hole in the same origin policy currently implemented in the browser. As soon you are subscribing to the onMessage event, you can receive messages from any other browser window, the application is responsible to check the originating domain and only to process messages which have been sent by trusted domains.
SAPUI5 is utilizing postMessage for its debugging and tracing functionality.