The App Secret is client-side by design
Unlike some platforms where a single secret key grants broad administrative access, the brainCloud App Secret is scoped specifically to the Client API. That API is sandboxed to only allow operations on behalf of the authenticated player — a player cannot use the App Secret to access other players' data, perform administrative operations, or call server-side APIs.
So while it may feel uncomfortable to include a "secret" in client code, the blast radius of exposure is limited by design. This is intentional — the App Secret is meant to live in your client.
Server-to-Server calls use separate credentials
If you need to make privileged calls — the equivalent of an admin API — brainCloud has a dedicated Server-to-Server (S2S) API. S2S calls use a separate Server Name and Server Secret, which are never distributed to clients. On top of that, S2S access can be locked down further with IP whitelisting, so only your trusted server infrastructure can authenticate.
Those credentials absolutely should be kept out of your client codebase — environment variables or a secrets manager are the right approach there.
Protecting the App Secret in client code
For the App Secret itself, here are the recommended practices:
Store it in a config file excluded from source control. For example, a
secrets.cfg,local.settings.json, or similar file that developers populate locally but never commit (add it to.gitignore).Pull it from an environment variable at build time if your engine or platform supports it — keeping it out of your repo without extra runtime complexity.
Obfuscate it in your shipped binary if your threat model warrants it (e.g., split the string, XOR encode it). Nothing is unbreakable, but raising the bar against casual extraction is worthwhile.
Honest caveat: in a shipped client binary, a determined person can always extract embedded strings. The goal is to make it inconvenient, not impossible. Since the App Secret only grants player-scoped access anyway, the practical risk remains low.
Move sensitive logic to Cloud Code
The best way to protect sensitive operations is to keep them off the client entirely. brainCloud's Cloud Code lets you run JavaScript scripts server-side, where the client never has visibility into the logic or any secrets involved.
Good candidates for Cloud Code include:
Economy calculations (e.g., determining rewards, validating purchases)
Leaderboard or score validation
Calls to third-party services that require API keys you don't want in the client
Any logic where the inputs shouldn't be trusted from the client directly
Cloud Code scripts can also make S2S calls internally, giving them access to privileged operations that the Client API cannot perform — all without exposing credentials to the player. See the brainCloud Cloud Code Guide for more details.
Optional: API Blocking
If there are specific Client API calls you want to ensure can never be made from the client — regardless of what's in your code — brainCloud supports API Blocking. This lets you block specific API calls at the app level, so even if someone reverse-engineers your client and tries to invoke them, brainCloud will reject the request server-side.
You can configure this under App > Design > Security > API Blocking in the portal.