The integration is part of your attack surface
Chat security discussions concentrate on the widget and the agent console, because those are the
parts people see. Meanwhile a token sits in a script somewhere, pulling transcripts into a
spreadsheet, and it has been there for two years, and nobody remembers who created it.
That token is not a smaller risk than an agent account — it is frequently a larger one. It
does not have a person attached who would notice something odd, it never gets offboarded, and it
often carries broader permissions than any individual agent, because it was created with whatever
access made the first version work.
Scope down, always
The single most valuable habit is refusing to issue broader access than the job requires. A token
that only needs to read conversations should not be able to modify anything; one that serves a
reporting dashboard has no business being able to change settings.
MyLiveChat’s v1 API supports granular scopes on tokens for exactly this reason, and the
discipline is to use the narrowest set that makes the integration work, then stop. The common failure
is diagnostic: something does not work, a broad token makes it work, and the broad token ships. If
that happens, treat it as a debugging step and go back to narrow it afterwards — the temporary
version is the one that tends to survive for years.
Issue a separate token per integration, never a shared one. Shared credentials cannot be revoked
without collateral damage, which in practice means they never get revoked at all. Separate tokens
also make an audit trail meaningful, because activity can be attributed to a specific system.
Where keys should and should not live
Most credential leaks are storage accidents rather than attacks.
- Never in client-side code. Anything in page JavaScript is readable by every visitor. If an integration seems to need a secret in the browser, the design is wrong — the call belongs on your server.
- Never in the repository. Committed secrets persist in history long after being deleted from the current files, so removing the line is not remediation. A committed key should be rotated, not tidied away.
- Not in chat, tickets, or shared documents. Credentials pasted into a message quietly inherit that channel’s entire audience and retention.
- In environment configuration or a secrets manager, injected at runtime, with access limited to the systems and people that genuinely need it.
Log hygiene deserves a mention because it is so easily missed: verbose HTTP logging will happily
record an authorization header into a log file with far weaker access controls than the secret store
it came from.
Treat incoming webhooks as untrusted
An endpoint that receives chat events is a publicly reachable URL, and anyone who learns it can
post to it. If it acts on whatever arrives, it will eventually act on something forged.
Verify the payload signature before doing anything with it, and reject anything that fails rather
than logging and continuing. Use a constant-time comparison for the signature check. Reject stale
timestamps so a captured request cannot be replayed later. And keep the handler idempotent, since
legitimate deliveries get retried and duplicate processing is a real bug in its own right.
An obscure URL is not a control. Assume it is known and require proof on every request.
Rotation only works if it is rehearsed
Most teams intend to rotate credentials and do not, because the first attempt breaks something at
an inconvenient moment and the lesson learned is to avoid rotating. The way out is to make rotation
routine while nothing is wrong.
Keep an inventory: every active token, what it is for, who owns it, and when it was issued. That
list is what turns an incident into a ten-minute job instead of an archaeology project. Where the
integration allows overlapping credentials, issue the new one, move traffic, confirm the old one has
gone quiet, then revoke — rotation with no downtime. Rehearse it on a schedule so that when you
must rotate urgently, you are repeating a familiar procedure.
Revoke immediately, without ceremony, when a key may have been exposed, when the integration is
retired, or when the person who owned it leaves. Offboarding checklists routinely cover console
accounts and forget the automation those people built.
Review what the integration receives
Finally, look at the data itself rather than only the access. An integration streaming full
transcripts into a widely-readable spreadsheet has effectively re-published your chat history at that
tool’s access level, however well-scoped the token was. The permissions were fine; the
destination was the problem.
Ask what each integration genuinely needs. Often it is a few fields rather than the whole
conversation, and narrowing the payload shrinks the consequence of any downstream mistake. Apply your
retention rules to those copies too — deleting transcripts on schedule in one system achieves
little if a complete duplicate sits elsewhere indefinitely.
Rotation only works if you can tell what is still live, which is what the usage history is for: knowing which API tokens are safe to revoke covers reading it, and the kind of job it cannot see.