#5 - Broken access control

When a developer exposes a reference to an object without proper access or other protection, then this reference becomes a source of attack. The objects defined in the Clinical Data API have been tested to validate proper authorization constructs within the functions of the defined service. When developing code and sending data to and from the API, ensure that the authorization model of the API interface is consistent to guard against insecure direction object references.

The defense in depth design pattern specifies that multiple layers of security must be implemented in an application. This also means that application functionality that executes methods and operations should be guarded by authorization checks even if the underlying data object is protected through entity security. When the client application calls out to the Clinical Data API to submit the data, such calls should be protected with the level of the access control. As a best practice, never assume that a specific method will only be called within the context that it was initially designed for. All access to functionality that manipulates data must be protected either by access control on the entity or by guarding the invocation of methods with the appropriate permission checks. The credential of the identity associated with the access control in the client application must be encrypted and stored in the secured identity management system as the API does.