Roles, hierarchy, and holders
Record each powerful permission, the role that grants it, the role's position, whether Discord marks it as managed, and who is expected to hold it.
DISCORD SERVER SECURITY CHECKLIST
Review the controls that shape who can do what.
Security starts with an explicit access model, then a careful review of verification, roles, channels, AutoMod, and installed apps. This checklist helps owners find configuration risk without pretending a settings scan can observe every threat.
✓Configuration audit only✓No message content✓Not a security certification
10 OWNER CHECKS
Start with intent, then follow effective access
Work in this order. It prevents a tidy-looking role list from hiding a public overwrite, an overpowered bot, or an exception that changes the result for one important channel.
Write down the intended access model
Decide whether the server is public, invite-only, paid, internal, or mixed. Define what a new arrival, verified member, moderator, and specialist role should be able to see and do before judging the current configuration.
Inventory owners and powerful administrators
Confirm the server owner, list every role with Administrator or broad management permissions, and identify who is accountable for each role. Administrator bypasses channel restrictions, so it should be exceptional rather than a convenience setting.
Choose a server-wide verification level
Match Discord's verification level to the cost of a bad join and the friction legitimate members can tolerate. Remember that verification is server-wide: it controls who can send or join voice, but it does not replace channel permissions or onboarding.
Review the @everyone baseline
Treat @everyone as the arrival state. Remove powerful management permissions, decide whether members may create invites or mention everyone, and confirm that default channel visibility matches the access model you wrote down.
Trace role hierarchy and delegation
Check every role that can manage roles, channels, members, webhooks, or the server. A member or bot can only manage roles and members below its highest role, while Administrator bypasses channel restrictions entirely.
Resolve channel access from real perspectives
Review categories and channels as an unverified arrival, ordinary member, moderator, and each private-group role. Flag explicit channel overwrites, member-specific exceptions, and channels that are no longer synced to their category.
Inspect native AutoMod coverage
Record each enabled and disabled rule, trigger, action, alert destination, and exemption. Confirm that the alert channel is private, exemptions are intentional, and the configuration covers the community's actual language and abuse patterns.
Audit bots, apps, and webhooks
For every integration, record its purpose, owner, current permissions, role position, and the channels it can reach. Remove abandoned access and question Administrator, Manage Roles, Manage Webhooks, or Manage Server unless the documented job truly requires it.
Test onboarding and private entry points
Follow the join path from invite to first useful action. Check welcome and rules destinations, onboarding choices, membership-gated rooms, staff spaces, voice rooms, and any channel that exposes operational or customer information.
Save evidence, assign fixes, and rescan
Capture the configuration before changing it, assign an owner and decision to each finding, test from representative roles, and rerun the review after staff changes, bot installs, or structural work.
EVIDENCE TO COLLECT
A useful review records what exists—not just what feels safe
Keep enough detail for another owner to reproduce the conclusion. Screenshots can help with a one-off check; a structured inventory is better for comparing future changes.
Categories, channels, and exceptions
Record the server baseline plus category, role, and member overwrites. Note which channels are synced and test the final view from the perspectives that matter.
Verification, AutoMod, and integrations
Record verification and safety settings, rule status and exemptions, alert destinations, installed applications, bot permissions, and credential-free webhook inventory.
How to choose a Discord verification level
Discord's verification level applies across the server. Members who do not meet it cannot send text or join voice. A verified phone number satisfies the other verification requirements, but the setting still does not decide which channels a member may view.
| Level | Current Discord requirement | Owner question |
|---|---|---|
| None | No verification restriction | Is unrestricted participation intentional? |
| Low | Verified email | Is email verification enough for the join model? |
| Medium | Verified email for more than five minutes | Does a short delay reduce abuse without harming onboarding? |
| High | Email timing plus an account older than five minutes and server membership longer than ten minutes | Can new members wait before participating? |
| Highest | Verified phone | Does the risk justify phone-verification friction? |
Check Discord's current verification-level documentation before making a policy decision, because product controls can change.
Do not stop at the role list
Discord combines server-level role permissions with channel overwrites. Administrator receives every permission and bypasses channel restrictions. Without Administrator, effective channel access starts with @everyone, adds role permissions, then applies channel-level denies and allows—including member-specific exceptions. A channel that is not synced to its category will not follow later category changes.
That is why a security review should test several perspectives instead of reading role names. “Moderator” is a label; the effective permissions and hierarchy are the evidence. Discord's permissions reference documents the calculation and hierarchy, while its permissions setup guide explains synced and unsynced channels.
Know what this checklist cannot prove
A configuration review cannot tell you whether a moderator account is compromised, a link is malicious, staff respond well under pressure, or a raid is happening now. It also cannot certify that a server is secure. Those questions require live operational controls, account protection, incident procedures, moderation evidence, and human judgment.
DisplayState's Oracle audit engine reads supported server configuration and reports assessed, partial, or unavailable coverage. It does not read message content, watch member behavior, detect live scams or raids, or turn missing evidence into a clean bill of health. Read the product security boundary before connecting a server.
FREE DURING BETA
Turn the checklist into a private configuration baseline.
Connect a server you manage, run the free audit, and review prioritized evidence before approving any supported change.
Run the free audit