Skip to content
MCRank

A Minecraft Server Security Checklist

Twenty checks that close the most common ways servers are taken over: accounts, ports, proxies, panels, plugins and backups.

MCRank Editorial · Published October 14, 2026 · Updated October 14, 2026

Most servers are not hacked by anyone clever. They are taken over through a handful of mistakes that repeat: an open port, an operator account nobody remembers, a plugin from a stranger, a panel that was never updated. This checklist is ordered by how often those mistakes matter.

Accounts and operators

  • Keep online-mode on. The Minecraft Wiki documents it as the setting that only allows players verified with Mojang's account system to join, and it defaults to true. Turn it off only behind a proxy that authenticates players for you, or accept that names can be impersonated and use a login plugin.
  • Use a whitelist while a server is private, and consider enforcing it. The enforce-whitelist setting kicks online players who are not on the list after it changes.
  • Count your operators. An operator can do anything. Give people permissions through a permissions plugin instead, and keep op for the one or two people who need it. The default op permission level is 4, the highest.
  • Review your staff list every few months and remove people who have left.

Network exposure

  • Know your open ports. A Java server uses TCP 25565 by default. A Bedrock bridge uses UDP 19132 by default. Everything else should be closed to the internet unless you can say why it is open.
  • Keep rcon off. enable-rcon is off by default, and if it is on and its password is blank the server will not start it as a safeguard. If you turn it on, use a long password and restrict access by firewall.
  • Keep query off unless you need it. enable-query is off by default.
  • Use a firewall on the host. It is the most effective protection, and every part of your setup assumes it.

Proxies and networks

  • Use modern forwarding on Velocity, and set the same secret on every backend. The Velocity documentation says modern forwarding is not a replacement for a firewall.
  • Make backends reachable only by the proxy. Test it from outside.
  • Protect the forwarding secret and, if you use Floodgate, its key.pem. The Floodgate documentation warns not to distribute that key, because it lets Bedrock accounts bypass Java authentication.

Panels and hosting

  • Put panels behind HTTPS, keep them updated and enable two-factor authentication where available.
  • Give each user only the access they need.
  • Run the server as an unprivileged user, not as root or administrator. The Velocity security notes make the same point about services in general.

Plugins and software

  • Install plugins only from the creator's own pages or well-known platforms, and check who publishes them. Every plugin runs with the server's full power.
  • Read what a plugin does before you install it, especially if it asks for network access or for permission to run commands.
  • Keep Paper and plugins updated. Fixes for exploits arrive in new releases.
  • Remove plugins you no longer use.
  • Use an anticheat if cheating matters to your server, and test it before it can issue bans. A predictive anticheat such as Grim aims to catch new cheats without a list of signatures, but any anticheat can flag honest players.
  • If your server cannot use online mode, use a login plugin, such as AuthMe, to protect names.

Logging and recovery

  • Log what happens to the world so you can reverse damage; CoreProtect is one option.
  • Back up on a schedule, store copies off the machine and restore one to a test server.
  • Keep a short written plan: who can reach the server, how to take it offline and how to restore it.

Secrets

  • Keep tokens, passwords and keys out of chat, screenshots and public repositories.
  • Use a different password for every service, and a password manager.
  • Rotate anything that might have leaked, and update every place that used it.

Players and community

  • Publish your rules and how to report problems.
  • Make it easy to report an exploit privately, and thank people who do.
  • Do not share staff accounts. One account per person means logs mean something.

How to use this list

Go through it once on a test server and note what you would change. Fix the exposure and the accounts first, since they are the cheapest and the most common, then the rest. Repeat after any big change to your setup.

This guide is editorial content. It is not advertising and it does not rank or endorse any resource.

Sources

Where the facts in this guide come from. MCRank links to them; it does not copy them.

Resources mentioned

Approved resources this guide mentions. Mentioning one is not an endorsement.