An API key can turn a useful cBot into a quiet credential leak if it travels with the source code. Protecting it means checking what the algo can access, where the secret lives, and how you would revoke it—not just hiding a string in a different file.
Start with the cBot's actual access rights
cTrader algos declare an AccessRights level. Its access-rights guide describes FullAccess as permitting broad actions, including Internet access and file reads and writes. The file-operations guide documents a restricted option for supported algorithms: file work can be confined to the algo's designated folder. Use the narrowest permissions that still support the feature you need.
One important detail is easy to miss: AccessRights.None does not mean “cannot make a network request”. cTrader's network-access documentation says its HTTP and WebSocket functions work with None. A secret available to the code may therefore still be sent to a remote service by code that has network access. Review outbound destinations as well as file permissions.
Keep credentials out of source and shared settings
An API key, OAuth token or similar credential is a secret. OWASP's Secrets Management Cheat Sheet describes the risks of plaintext secrets in source and configuration, and recommends limiting who or what can access each credential. Microsoft's application-secrets guidance likewise treats API keys and OAuth tokens as secrets and recommends secure storage, restricted access and an audit trail.
For a cBot review, trace the value from input to use. Search source, sample files, build settings and any shared configuration for a real token. Do not commit, publish or send a credential in a support log. A placeholder such as YOUR_API_KEY is fine; a working key is not. If the algo needs a credential, select a storage and delivery method appropriate to the machine and account running it. The cTrader pages cited here describe access rights and file handling; they do not establish a dedicated cTrader secret vault.
Make a leak recoverable
Before enabling an external integration, know where its credential is managed and how to disable it. OWASP recommends fine-grained access, supported rotation and revocation when a secret is no longer needed or may have been exposed. Microsoft's guidance also distinguishes planned rotation from reactive revocation. These practices reduce the time a copied key remains useful; they cannot make an exposed key harmless.
A practical pre-deployment pass:
- Identify every credential and the external service that accepts it.
- Remove live values from source control, screenshots, shared files and logs.
- Confirm the algo's declared access rights and every network destination it calls.
- Give the key only the permissions required for that integration, where the provider offers scopes.
- Write down how to revoke and replace the key, then test that process without a live trading action.
That last step matters. A credentials check should not require placing an order. Keep integration checks separate from trade execution, and review the cBot's order logic on its own. For a broader permission boundary, see how cTrader AI account access differs from order authority; for API authorization itself, compare cTrader Open API account and trading scopes.
What this checklist cannot promise
These checks do not prove that a cBot is safe, that an external service is trustworthy, or that a credential is stored securely by a particular platform. Inspect the exact source and deployment setup you use. cTrader's documented access model is not a substitute for reviewing the code that receives and sends the secret.