Securing your server against takeover

What you are actually protecting against

"The server got hacked" is almost always the wrong description. Discord itself is rarely broken into. What happens is one of three things: somebody on your team loses their account, a bot with broad permissions gets compromised, or you gave permissions to somebody you should not have.

All three end identically — channels gone, members banned, server renamed. And all three become considerably less likely through the same set of measures.

First: two-factor for everyone with permissions

Discord offers a server setting that gets used far too rarely: require two-factor authentication for moderation. With it enabled, actions such as banning, kicking and managing channels can only be performed by accounts with 2FA active.

You will find it in server settings under "Safety Setup". It costs nothing, it costs nobody any convenience beyond a one-time setup, and it closes the most common route in: a compromised moderator account.

Note that you need 2FA on your own account before Discord lets you enable it.

Then: cut permissions back

Look at every role that holds permissions and ask two questions: does this role genuinely need that, and does it need it everywhere?

Most servers have a moderator role with Administrator, because that was fastest during setup. It is the most expensive shortcut in the entire server. Replace it with the permissions actually used: Kick Members, Ban Members, Moderate Members, Manage Messages. That covers ninety-nine percent of moderation work.

The same applies to bots. Go through the list and ask, for each: what does it do, and what may it do? The difference is your risk.

And one rule that is uncomfortable and still correct: no more than two humans should hold Administrator. Every additional one is another way in.

Role order is a security setting

Discord only lets a role modify roles positioned below its own. That applies to humans and to bots. Ignoring it builds a server where a bot with Manage Roles can grant anybody any permission — including itself.

In practice: drag your bots' roles as far down as their function allows, and always below your staff roles. Write down in an internal channel why each role sits where it does. Otherwise, three months later somebody moves one upwards because a bot reported an error, and nobody remembers the reason.

An alert an attacker will not find

Set up a private channel that plays no part in day-to-day operation and route security alerts there. The standard mistake is putting the alarm in the same channel as everything else you log — and that is the one an attacker deletes first.

If you run a bot with anti-nuke, also check whether it can reach you by direct message. An alert inside the server does not help while the server is being dismantled.

The part almost nobody does

Rehearse it once. Take a test server, give a second account Administrator, let it delete channels, and watch what your security bot does and how long it takes. Almost everyone who tries this finds at least one setting that did not behave the way they assumed.

And back up what can be backed up: some bots can export roles and channel permissions and restore them. After an incident that is the difference between an hour and a weekend.