A client-held secret is a public capability
Browser source, network tools, application bundles, device backups, runtime instrumentation, crash reports, and reverse engineering can reveal a value the product calls secret. Restricting the UI does not restrict an extracted credential.
Once extracted, a general sending credential can be used outside your application, automate abuse, consume quota and funds, or reach recipients without your business rules.
Put a trusted backend between the client and MessageHop
The browser or mobile app authenticates to the customer's own backend. That backend verifies the user and business event, applies rate and consent policy, retrieves the MessageHop secret at runtime, and submits the bounded message request.
The client receives only the minimum state needed for its experience. It does not receive the provider credential, MessageHop server credential, internal route, or recipient-wide messaging capability.
Make compromise small with least privilege
Use one credential per independently revocable server workload. Bind it to the correct Organization, Brand, Project, Registered App, environment, actions, and channels. A checkout service that sends SMS should not automatically read billing or send WhatsApp for another app.
Use expiry and account-state checks. Removing a membership, suspending an organization, revoking a credential, or deactivating an app should take effect without waiting for a client release.
Operate the full credential lifecycle
- Issue: require appropriate permission and recent authentication.
- Display once: copy directly to the destination secret manager.
- Store safely: encrypt at rest, restrict runtime identity, and avoid broad developer access.
- Use: send in the Authorization header over HTTPS; redact request headers.
- Observe: track safe metadata such as last use and scope, never the raw secret.
- Rotate: deploy a replacement, verify, then revoke the old credential.
- Revoke: fail authentication immediately and preserve audit evidence.
What about direct client messaging?
Some narrow flows—such as an explicitly designed challenge—may use a restricted public identifier plus origin, bundle, package, attestation, quota, recipient binding, expiry, and abuse controls. That is a different credential and API design. It is not permission to embed a long-lived general sending secret.
Respond to suspected exposure
Revoke the affected credential, issue a bounded replacement, inspect safe usage and billing evidence, contain the source of leakage, notify appropriate owners, and document the event. Do not wait for proof of abuse when the raw secret has entered a public repository or client build.