There are a number of Internet resources available that can assist you, including the Open Web Application Security Project (OWASP), Web Application Security Project (WASP), Web Application Security Working Group (WASWG), and various commercial sites.
The Oracle JET framework includes components that follow best practices for security and provides the
oj.OAuth plugin for providing secure access to a user's private data. However, the application developer is expected to perform tasks that are not included in the Oracle JET framework.
Oracle JET components follow best practices for security. In particular:
strict mode using the
use strict directive.
Strict mode changes warnings about poor syntax, such as using undeclared variables, into actual errors that you must correct. For more information, see http://www.w3schools.com/js/js_strict.asp.
Oracle JET code does not use inline
Because browsers can't tell where the inline script originated, the World Wide Web Consortium (W3C) Content Security Policy prohibits the use of inline scripts. For additional information, see https://w3c.github.io/webappsec/specs/content-security-policy.
Oracle JET code does not generate random numbers.
Any HTML generated by an Oracle JET component is ether escaped or sanitized.
The Cordova documentation includes a Security Guide that provides some security best practices for Cordova applications. You can use this guide as a starting point to secure your hybrid mobile application. However, as Cordova points out, security is a complicated topic, and its guide is not exhaustive.
The Oracle JET API provides the
oj.OAuth authorization plugin which supports the OAuth 2.0 open protocol. OAuth standardizes the way desktop and web applications access a user's private data. It provides a mechanism for users to grant access to private data without sharing their private username and password credentials.
OAuth 2.0 defines the following roles:
Resource owner: An entity that can grant access to a protected resource, such as the end user.
Client: Application making protected and authorized resource requests on behalf of the resource owner.
Resource server: Server hosting the protected resources that can accept and respond to protected resource requests using access tokens.
Authorization server: Server that issues access tokens to the client after it successfully authenticates the resource owner and obtains authorization.
The authorization server can be the same server as the resource server. In addition, an authorization server can issue access tokens accepted by multiple resource servers.
OAuth 2.0 Request for Comments (RFC) 6749 describes the interaction between the four roles as an abstract flow.
The client requests authorization from the resource owner, either directly or through the authorization server.
The RFC specifies that the authorization server is preferred.
The client receives an authorization grant, which is defined as the credential representing the resource owner's authorization.
The client requests an access token from the authorization server by authenticating with the server and presenting the authorization grant.
The authorization server issues the access token after authenticating the client and validating the authorization grant.
The client presents the access token to the resource server and requests the protected resource.
The resource server validates the access token and serves the request if validated.
The access token is a unique identifier issued by the server and used by the client to associate authenticated requests with the resource owner whose authorization is requested or has been obtained by the client.
The Oracle JET
oj.OAuth plugin provides functions for the following tasks:
Getting access token credentials if initialized by client credentials.
Caching access token credentials.
Creating the header array with bearer token.