8 Secure Development

This section provides guidelines and recommendations for using and developing against the REST Web Services APIs published by OHMPI RM. The following sections includes the recommended practices for secure usage of the RM APIs.

8.1 Roles and Permissions

A developer working with the REST APIs is subject to the same roles and permissions required to use OHMPI RM applications. To work with the REST APIs, developers must have the access permission of the RESTful Web Services.

8.2 Valid Content Types

The REST API supports application/XML and application/JSON. The RM REST APIs support application/JSON content type only. Developers must use the correct MIME type in the Accept and Content-Type HTTP headers. Otherwise, the API will reject the requests.

8.3 Injection

To prevent SQL injections, the REST API uses bind variables in SQL queries that might involve any user input.

The data that the REST API returns is properly encoded for their returned types in the JSON format. Developers should encode data based on the context they are using. The REST API does not know the context, so safeguards are important.

8.4 Broken Authentication and Session Management

The REST API is stateless and, therefore, the RM service does not maintain an HTTP session information and status for the duration of multiple requests. Therefore, the typical security issues associated with HTTP stateful sessions do not apply.

However, the API does require transmission of the username and password in the HTTP authorization header. Developers, therefore, should ensure that the username and password are stored securely and use the HTTPS protocol. For example, this might be the Oracle Platform Security Services (OPSS) framework.

8.5 Cross-Site Scripting

The API validates input from developers before using it. For outbound data from the REST API, developers are responsible for properly encoding the data, depending on the context where the data is being used.

8.6 Insecure Direct Object References

The REST API ensures that the invoker has the permissions to access every requested resource and representation or entity returned.

8.7 Sensitive Data Exposure

The username and password are the only business-agnostic data that is considered sensitive for the REST API. The data is transmitted over HTTPS and is never at rest; that is, it is not stored or output to log files. Developers should also provide safe and secure storage when data is at rest.

8.8 Missing Function-Level Access Control

The REST API ensures that the invoker has the permissions to access every requested resource and representation or entity returned.

8.9 Cross-Site Request Forgery

Because the REST API is stateless, there is no HTTP session to exploit via Cross-Site Request Forgery (CSRF). Every request needs to carry the Authorization header with valid values; otherwise, it is rejected.

8.10 Using Known Vulnerable Components

The REST API stack is constantly updated with the latest security fixes and patches. Oracle recommends that developers using the API do the same.

8.11 Non-validated Redirects and Forwards

Although REST API responses might provide URLs to other resources and/or sub-resources in the representations that are returned, none of these URLs contain any user input. Therefore, the REST API is not subject to this vulnerability.