Understanding the security best practices when integrating with Cybrid's platform.
There's several best practices to consider when implementing with Cybrid's platform:
Don't embed the Cybrid Client ID or Client Secret in your code
It can be quick and convenient to just embed client ID's or secrets in your code repo, but this increases the risk that those keys are compromised.
- Make the Client ID and Secret available via environment variables in your build environment, either as an output of your build pipeline, or using a secrets manager such as the AWS Secrets Manager if you're deploying on AWS.
- Store the keys in an encrypted fashion, instead of plain text. This reduces the risk of a key easily being copied and used.
- Restrict access to the Client ID and Secret to only certain people who must have access for the purposes of configuring the deployment / environment.
Choose the right Authorization Scope
Access to resources through the Cybrid API is granted via an Authorization Scope system. Read more about scopes in How to Authenticate to the API.
Best Practice: We highly recommend taking a least privilege approach to the Authorization scopes you select during authentication. For example, it's often convenient to authenticate and authorize for a Bank token with all scopes, and then use this token to make all of your API calls. While this works, it opens up the possibility of making the wrong call, and executing something in the Platform that you didn't mean to, leading to errors and customer issues.
For most customer-based operations, you should be generating a Customer token, instead of a Bank token, scoped to the appropriate action. For example, if you're simply retrieving information, such as trades, for a customer, a Customer Token with the read scope is the least restrictive while still providing access to the information.
Generating customer tokens can easily be done via the POST /api/customer_tokens endpoint in the Identity API.