The Name on the Message Is a Field
On a Discord webhook the name shown on a message is a field in the message. Not a setting, not an account — a value the sender chooses, per message, with nothing checking it. Which makes the sender name in that channel a claim rather than a fact.
Look at a notification in a chat channel and you read two things almost simultaneously: what it says, and who sent it. The second one is doing an enormous amount of work — it is what makes an approval request from your operations system different from the same words typed by a stranger. It is worth knowing, per platform, how much that name is actually worth.
Five platforms fix it. One does not.
Of the six chat destinations here, five decide the sender name outside the message.
| Platform | Where the sender name comes from | Can the message change it? |
|---|---|---|
| Slack | The webhook's own configuration, set when it was created | No |
| Teams | The workflow that owns the webhook | No |
| Google Chat | The webhook registered in the space | No |
| Telegram | The bot, named when it was created | No |
| The verified business behind the number | No | |
| Discord | A field in the request body | Yes, per message |
That last row is a genuine design decision by Discord rather than an oversight, and it exists for a good reason: Discord webhooks are used by relay bots that post on behalf of many different sources, and a single webhook that must show a different name each time needs the name in the message.
A name that can be set per message is a name that has been asserted, not established.
What the connector does with it
It sets a fixed name on every message and never varies it.
The value in doing so is straightforward: without it, messages carry whatever name was typed into Discord when the webhook was created, which is often something like webhook or the name of whichever integration was configured first. In a channel receiving alerts from several sources, that is genuinely confusing.
What it deliberately does not do is vary the name by event, by workspace or by module. A notification about a purchase order and one about a stock level arrive under the same name, because they came from the same place, and the name is supposed to mean where this came from.
It would be easy to do otherwise — one field, one line — and it would degrade the only signal the reader has for source. A name that changes with the content is a name that tells you about the content, which is what the title is for.
What this means for the channel
Combine two facts from this series and the practical consequence follows.
A webhook has no signature: possession of the address is the entire authorisation. And on Discord, the sender name travels in the message. So anyone holding the address can post under any name they like, and the message will be indistinguishable from a genuine one — because there is nothing in a genuine one that a forgery lacks.
The four webhook connectors all share the first half. Discord adds the second, which makes the impersonation cleaner: on the others, a forged message at least arrives under whatever name the webhook was set up with.
None of that makes Discord unsuitable. It makes two ordinary habits worth actually doing rather than nodding at:
-
Rotate the webhook when the people around it change
Somebody leaves, a contractor's access ends, the URL turns up in a screenshot in a ticket. Revoke and recreate takes under a minute and there is no state to migrate.
-
Keep the acting-on-it in the product
A notification says something happened and links back. The approval, the adjustment and the release are recorded in your workspace under a real account with real permissions — so a convincing chat message is still only a message.
-
Use a channel whose purpose is alerts
A dedicated channel makes an out-of-pattern message visible as out of pattern. In a busy general channel it is furniture.
-
Treat the URL as a credential
Encrypted, out of logs, behind a permission. It does not look like a secret, which is exactly why it needs to be handled as one.
The general shape of this
It is worth naming the category, because it recurs well beyond chat.
Some fields are authenticated — established by the platform, not settable by the sender. Some are asserted — supplied by whoever sent the message. They look identical when rendered, and readers cannot tell them apart, because nothing in the interface distinguishes a fact from a claim.
A sender name in email is asserted. So is a display name in most chat platforms. So is the name on a webhook message here. In each case the interface presents it with the confidence it would give a verified fact, and that gap between presentation and guarantee is where a whole family of social attacks lives.
The useful discipline is not suspicion of every message. It is knowing which of the two you are looking at, so the weight you put on it is the weight it can carry — and, in a product, making sure that acting on something is never as easy as reading it.
What is in place, layer by layer
Sender identity across the six chat destinations
A fixed sender name on Discord
Set on every message and never varied, so the name means where this came from rather than what it is about.
Platform identity used where it exists
On the other five, the sender is the webhook, the bot or the verified business — established outside the message and not settable by it.
A source line inside the message
Where a platform offers a subtle context line, it names the system, so a channel carrying several sources stays readable independently of the sender name.
Webhook addresses treated as credentials
Encrypted at rest, kept out of logs and error messages, and behind a permission to configure.
Rotation with nothing to migrate
Replacing a webhook is revoke, recreate, paste and save — which is what makes doing it on a schedule reasonable.
Acting stays inside the product
A notification links back; approvals, adjustments and releases are recorded under a real account with real permissions rather than triggered from chat.
One outbound direction
These connectors post and never read. Nothing typed into a channel is treated as an instruction, so a convincing message cannot become an action.
Inbound events are a different connector with a different model — there a shared secret and a computed signature decide whether a request is genuine, because inbound is where a claim would otherwise become an action.
Three positions held on purpose
- The sender name is fixed rather than varied per event. It is the reader's only signal for source, and spending it on information the title already carries leaves them with neither.
- Chat is outbound only. Nothing posted in a channel is read back as an instruction, which is what keeps a forged message a message rather than an action — and it is the reason the asserted sender name is a nuisance rather than a hole.
- The distinction between an asserted and an established field is stated rather than glossed. A reader deciding how much to trust a channel deserves to know which one they are looking at.
Five questions about who a message says it is from
Where does the sender name come from?
A good answer sounds like
A per-platform answer.
What ours actually is
A message field on Discord; the webhook, bot or verified business on the other five.
Does it change per event?
A good answer sounds like
No.
What ours actually is
Fixed on every message, because it is meant to say where this came from.
Could someone forge a message?
A good answer sounds like
With the URL, yes — say so.
What ours actually is
A webhook has no signature. That is why the URL is handled as a credential and rotation is routine.
Can a chat message trigger an action?
A good answer sounds like
No.
What ours actually is
These connectors post outward only. Nothing in a channel is read back as an instruction.
How do I limit the damage of a leak?
A good answer sounds like
Rotate, and scope.
What ours actually is
Replace the webhook — nothing to migrate — and keep alerts in a channel where an odd message reads as odd.
Our take
The most useful question to ask about any notification channel is not whether it is secure but what a convincing fake could accomplish. If the answer is that somebody sees a message and then goes and does something in a system that knows who they are and what they may do, the exposure is bounded and mostly social. If the answer is that a message can approve, release, or pay something, the sender name has quietly become an authentication mechanism, and it was never designed to be one. Keeping chat firmly on the telling side of that line is worth more than any amount of care about the messages themselves.
Keep the telling and the doing apart
Alerts belong where people are. Decisions belong where there is an account, a permission and a record. A link between the two is the whole design.
Talk through operational alertsFrequently asked questions
Can we change the name that appears on our Discord alerts?
It is fixed rather than configurable, and deliberately so — it is the reader's only reliable signal for where a message came from, and in a channel carrying several sources a varying name makes that signal worthless. Which channel receives which events is configurable, which is usually the thing people actually want.
Could someone post fake alerts into our channel?
With the webhook address, yes — a webhook has no signature and possession is the whole authorisation. That is true of four of the six chat destinations. The mitigations are handling the address as a credential, rotating it when the people around it change, and the fact that reading a message never causes anything to happen.
Can we approve a purchase order from Discord?
No, and that is deliberate. The message links back to the record, and the approval is recorded in your workspace under the approver's own account with their own permissions. A decision with an audit trail should not be triggerable by anyone who can put words in a channel.
Does the connector read anything from Discord?
No. It posts and nothing else. There is no read path in it, so nothing typed in a channel — by anybody, genuine or not — can reach your workspace.
How often should we rotate the webhook?
There is no detectable signal that one has leaked, so the honest answer is on a schedule rather than on suspicion — and whenever the people around it change. It takes under a minute, there is no state to migrate, and anything already dispatched against the old address simply reports a refusal.
