Hey there and welcome to this tutorial about permissions in Discord.
What you should know about permissions
This section has been heavily inspired by the official Discord Developer Documentation.
- A user can grant roles to other users that are of a lower position than its own highest role.
- A user can edit roles of a lower position than its highest role, but it can only grant permissions it has to those roles.
- A user can only sort roles lower than its highest role.
- A user can only kick, ban, and edit nicknames for users whose highest role is lower than the user’s highest role.
Otherwise, permissions do not obey the role hierarchy. For example, a user has two roles: A and B. A denies the
Send Messages permissions on a #coolstuff channel. B allows the
Send Messages permission on the same #coolstuff channel. The user would ultimately be able to view the #coolstuff channel, regardless of role positions.
Certain permissions can be applied to roles or directly to members on a channel-level by using permission overwrites.
When using overwrites, there are cases where permission collisions could occur for a user; that is to say, the user may have certain overwrites with permissions that contradict each other or their guild-level role permissions. With this in mind, permissions are applied to users in the following hierarchy:
- Base permissions given to @everyone are applied at a guild level
- Permissions allowed to a user by their roles are applied at a guild level
- Overwrites that deny permissions for @everyone are applied at a channel level
- Overwrites that allow permissions for @everyone are applied at a channel level
- Overwrites that deny permissions for specific roles are applied at a channel level
- Overwrites that allow permissions for specific roles are applied at a channel level
- Member-specific overwrites that deny permissions are applied at a channel level
- Member-specific overwrites that allow permissions are applied at a channel level
Permissions in Discord are sometimes implicitly denied or allowed based on logical use. The two main cases are
Send Messages for text channels. Denying a user or a role
View Messages on a channel implicitly denies other permissions on the channel. Though permissions like
Send Messages are not explicitly denied for the user, they are ignored because the user cannot read messages in the channel.
When creating a new role, the new role has the same permissions as the everyone role by default. We suggest clearing every new role’s permissions before starting to set up its permissions as it can prevent duplicated and unused permissions.
So what are we trying to achieve now?
Based on what you learned above, here are some things you need to make sure.
Avoid duplicated and unused permissions
To get a more clean and less messy permission setup, you need to remove permissions, that are being set multiple times.
A scenario of a duplicate is when your everyone role or a member role has the
Create Instant Invite permission and you have a channel overwrite that grants the same role the
Create Instant Invite permission.
As long as there is no other channel overwrite denying the user to have the
Create Instant Invite, there is no need for the channel overwrite.
Another scenario of duplicated permissions is when your everyone role or a member role has the
Read Messages permission and another role has
Read Messages too.
Read Messages permission of the other role is useless, as every user already has it.
Let’s imagine your everyone role or a member role has some basic permissions including
Read Message History and some more. Additionally, you have a Moderator role for your trusted members. This Moderator role has permissions to
Read Message History,
Kick Members and
While the system is working as it is, it is not clean.
The Read Messages,
Send Messages and
Read Message History are unused, because the Moderators already have them from the everyone or member role.
Why should I remove duplicated and unused permissions?
These permissions have no effect, but can collision in the future.
As you already learned, new roles get their default permission from the everyone role. That might be useful, but causes a lot of unused and duplicated permissions.
If you didn’t remove the default permissions from new roles, most of your roles (e.g. color roles, bio roles or just normal staff roles) might include permissions they got from the everyone role when you created the role.
If you now want to change the permissions of the everyone role, for example removing the
Change Nickname permission, all other roles that were created when the everyone role had that permission might still include that permission and therefore suddenly allowing people with another role to still change their username, even though you changed the everyone role. That can lead to dangerous security flaws, especially if its about moderator permissions and not only basic permissions like
Another scenario would just be a muted role. As you have learned above, if there is a role overwrite that explicitly allows a member to send messages, other role overwrites that explicitly deny that permission won’t have any effect. Therefore, if you have a role overwrite, e.g. for your member role, that explicitly allows
Send Messages in a channel, you can not add a role overwrite for a Muted role that explicitly denies the
Send Messages permissions, not matter the hierarchy.
When talking about security on a Discord server, permissions are very important.
This is by far the most dangerous permission of all – not only does it allow users with that roles to change everything on the server, it also includes every permission, like
Manage Roles, which means a violator could give everyone else on the server access to this permission.
Manage Roles allows a user to manage roles and give and remove roles to and from other members. It can be very dangerous as if it is abused, the violator can give everyone else on the server the same permissions as they have.
This permission might sound harmless as it allows to change the server name and icon, but it also allows to manage invites. If this permission is abused, a violator is able to delete all and every invite on your server, which will significantly prevent your server from growing.
Mention @everyone, @here and All Roles
This permission can not change the server settings or kick/ban members, but it can lead members to leave your server. Most members do not like pings, and if a violator abuses this permission and spams messages containing pings, a lot of people will leave your server. This mainly affects active members which can significantly decrease your server’s activity.
Kick and Ban Members
While this is a permission that you can give to your moderators, make sure that only your very trusted staff gets it. When abused, a violator is able to kick or ban all* members on your server.
What you might not know
When talking about safety on Discord, one thing important is that you know what you are doing. Below are some things a server owner might now know yet.
Under the Moderation tab of your server settings, you can set a Verification Level.
Verification levels are one of the most effective yet easiest way to require verification. What most people don’t know about it is, that it will ignore members with roles.
Therefore, if you have automatic roles that are applied to every user on join, these verification levels are utterly useless. To have autoroles but still use verification levels, it might make sense to use another bot where users have to type a command like
!verify to get their roles. Requiring a chat message is way more effective than requiring a reaction as people that do not meet the verification level set can not send messages and therefore not verify themselves until they meet the verification level set in the server settings.
Integration Roles are automatically created when you invite a bot with permissions to your server. You can identify them by their orange header in the role settings.
I’ve heard about a lot of server owners that do not like integration roles because it means that every bot has an own role, but that is exactly the very big advantage of it:
- You can specify permissions for each bot separately and give them a specific position in the role list.
Also, and even better:
- Integration roles can not be assigned to other members or bots than the bot that the role was created for.
That means, you can easily give an integration role kick and ban members, and you can be sure that your staff member that is abusing their
Manage Roles permissions can not assign themselves the bot’s role, and therefore not giving themselves the bot’s permissions.
Just to be clear: It does not prevent the bot from abusing it’s permissions, but it prevents other users from abusing the bot’s permissions.
Also, as it allows you to specifically manage permissions for each bot separately, you have better control about each bot’s permissions and can adapt them to each bot’s functionality.
One of the worst solutions I have seen is one bot role that has the Administrator permission and every bot has it – do never do that. Have an integration role for each bot so you can give your moderation bot kick/ban members and your selfroles bot manage roles. If you want to have your bots listed under the same category, you can still create a bot role without permissions but separating on and give it to your bots.
No matter how much you trust your staff members or even go so far as to say that only you have rights, if another person gets access to someones Discord account, they can abuse all permissions. There is no 100% safe way to prevent this, but the chance can be significantly decreased by setting a secure and unique password and activate multiple factor authentication (2FA/MFA). 2FA will require you to enter a second, 6-digit-long number that changes every 30 seconds every time you log in.
By activating 2FA Requirement, your staff will have to activate 2FA or they will not be able to use their Moderation permissions.
You can enable 2FA Requirement in the server settings unter the Moderation tab. You need to have 2FA enabled on your account and be the server owner in order to enable it.
That’s it with this tutorial, I hope I was able to help you keep your server secure. If you have any questions, feel free to leave a comment below.