Secure Development

This section provides guidelines and recommendations for using and developing against the REST Web Services API published by ClearTrial. The following are recommended practices for secure usage of this API.

• Roles and Permissions
  
• Valid Content Types
  
• Injection
  
• Broken Authentication and Session Management
  
• Cross-Site Scripting
  
• Insecure Direct Object References
  
• Sensitive Data Exposure
  
• Missing Function-Level Access Control
  
• Cross-Site Request Forgery
  
• Using Known Vulnerable Components
  
• Non-validated Redirects and Forwards
  

Roles and Permissions

Developers working with the REST API are subject to the same roles and permissions required to use ClearTrial applications. To work with the REST API, developers must have the Web Services API permission.

Valid Content Types

The REST API supports application /JSON. Developers must use one of these MIME types in the Accept and Content-Type HTTP headers. Otherwise, the API will reject the requests.

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 type, JSON. Developers should encode data based on the context they are using. The REST API does not know the context, so safeguards are important.

Broken Authentication and Session Management

The REST API is stateless and, therefore, does not create and maintain an HTTP session. Therefore, the typical security issues associated with HTTP 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.

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.

Insecure Direct Object References

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

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.

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.

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.

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.

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.