The short version

For a private Minecraft server, the strongest practical baseline is to keep account authentication enabled, turn on the whitelist or allowlist, give operator privileges to as few people as possible, expose only the game port, and keep a tested backup outside the live server. A whitelist stops unknown accounts from joining, but it cannot protect you from a compromised friend’s account, an overpowered operator, a malicious plugin, or a stolen hosting-panel login. Security therefore needs layers.

This guide is for a world shared with friends, a club, or a small community. It does not rely on hiding the address or changing the default port: scanners can find an internet-facing service, so obscurity is not access control.

Start with the five-minute security checklist

Do these first, in this order:

  1. Keep online-mode=true on an internet-facing Java server. This makes the server verify connecting accounts rather than accepting a claimed username.
  2. Enable the whitelist and add only known accounts. Remove people promptly when they should no longer have access.
  3. Keep the OP list very small. Use scoped permissions for moderators or plugin commands instead of making everyone an operator.
  4. Enable MFA on the hosting panel and its email account. Use unique passwords and separate accounts where the provider supports them.
  5. Expose only the port players need. Keep RCON, the panel, SSH, file transfer, databases, and management APIs private or tightly restricted.
  6. Install add-ons only from sources you trust. Treat every plugin or mod as code with access to the server and its files.
  7. Update deliberately. Track Minecraft, server software, Java, plugins or mods, the panel, and the operating system; take a backup before changing versions.
  8. Keep versioned backups away from the live server and test a restore. A backup on the same writable disk is not enough.
  9. Retain useful logs. Record joins, permission changes, commands, plugin changes, and backup results for long enough to investigate a problem.

If you are still deciding where the world should run, use the broader server-for-friends setup guide first. The rest of this article assumes the server already exists.

Know what each layer actually stops

Threat Best first defense What that defense does not solve
Random player discovers the address Whitelist or allowlist A listed account being stolen or intentionally griefing
Attacker impersonates a known Java username online-mode=true Compromise of that player’s real Microsoft account
Friend accidentally uses a destructive command Least-privilege permissions A malicious plugin or stolen panel account
Malicious or compromised plugin Install fewer, trusted add-ons; isolate the server process Damage to data the process is allowed to edit
Internet attack against RCON, SSH, or a panel Do not expose admin services publicly; firewall and MFA Weak credentials reused elsewhere
Griefing or corruption Versioned backups plus activity logs Preventing the first incident
Broken update Staging test and rollback backup Vulnerabilities left in an old version indefinitely

The important distinction is prevention versus recovery. A claim-protection plugin may limit building but cannot replace authentication, panel security, updates, or backups.

Use authentication and an allowlist together

On a Java server that players connect to directly, leave:

online-mode=true
white-list=true
enforce-whitelist=true

Paper’s current server.properties reference explains that online-mode=true checks connecting players against Minecraft’s account service. white-list=true limits admission to listed players, while enforce-whitelist=true removes online players who are no longer listed when the whitelist is reloaded.

Manage membership from the console or with authorized in-game commands rather than hand-editing JSON while the server is running:

whitelist on
whitelist add PlayerName
whitelist remove PlayerName
whitelist list
whitelist reload

Review the list periodically and remove old accounts and temporary guests. Share the address privately, but treat that as reducing nuisance rather than providing security.

A proxy network is a special case. Velocity deployments commonly put backend servers in offline mode so the proxy can forward player identity. That backend must not be reachable directly. PaperMC’s Velocity security guide recommends firewall restrictions, binding backends to localhost where appropriate, and modern forwarding so only the trusted proxy can reach them. Do not copy an online-mode=false setting from a proxy tutorial onto a standalone public server.

Cross-play adds another identity boundary. With Geyser or Floodgate, follow the project’s authentication and forwarding instructions for your topology rather than weakening Java authentication by guesswork. Our Java/Bedrock cross-play guide explains the model.

Keep operator and plugin permissions narrow

An operator at the default high permission level can change the world, grant access, run powerful commands, and often reach administrative plugin features. Reserve OP for the owner and perhaps one trusted backup administrator. A helper who only needs moderation commands should receive only those permissions.

Paper’s post-installation security guidance recommends a permissions system to control commands and areas, and points to LuckPerms as one option. Whatever you choose:

  • Create roles such as player, moderator, builder, and administrator.
  • Grant explicit capabilities required by each role instead of broad wildcards.
  • Avoid granting *, full administrative groups, console access, or panel access for convenience.
  • Test each role with a non-owner account and review it after plugin changes.
  • Never paste a command from a stranger into the console without understanding it.

Keep Minecraft OP separate from hosting access. A moderator usually does not need billing, backup deletion rights, or the ability to replace server JARs. Give each administrator an individual account where possible.

Treat every plugin and mod as executable code

Plugins do not run in a harmless browser-style sandbox. PaperMC’s plugin installation documentation warns that a plugin receives full access to the server and the machine it runs on. Mods deserve the same caution.

Before installing an add-on, verify its official distribution page, compatibility, maintenance, publisher identity, and dependencies. Prefer Paper’s Hangar or the project’s linked Modrinth/GitHub release over a re-upload site or direct-message file. Record the installed version.

Install as few add-ons as the world needs. Test additions on a copy, read startup logs, and remove abandoned add-ons. Never run Minecraft as root or with sudo; PaperMC recommends an unprivileged user in its server security advice. On a managed host, ask whether customer server processes are isolated.

An anti-grief plugin can add block rollback, land claims, container controls, or audit history. It is a gameplay control, not permission to skip the layers above.

Keep admin services off the public internet

Players normally need only the game port. RCON, SSH, SFTP, databases, node daemons, panels, and management interfaces are administrative surfaces. Disable unused services; restrict the rest with a firewall, private network, VPN, or administrator IP allowlist where practical.

Java’s RCON is disabled by default. Leave enable-rcon=false unless a specific tool requires it; if enabled, use a strong unique password and firewall it so arbitrary internet clients cannot connect. Similarly, Minecraft’s newer management protocol is disabled by default and supports a secret and TLS, as described in Mojang’s Java Edition 1.21.9 notes. Keep its listener on localhost or a private management network rather than opening another public port.

Enable MFA for both the hosting panel and its recovery email. CISA’s MFA guidance recommends MFA for remote and privileged access. Store recovery codes separately and never reuse administrative passwords.

If you self-host, do not expose a router’s administration page or a generic web panel through the same port-forwarding exercise. Patch the operating system and panel, use key-based SSH where possible, and run the Minecraft process as a dedicated unprivileged account that cannot read unrelated personal files.

Make backups survive the incident

A useful backup includes every world dimension, player data, server properties, access lists, permissions, add-on configuration, and software versions. Stop cleanly or use a method that coordinates with world saving; copying during active writes can produce an inconsistent archive.

Use versioned retention rather than one archive that is overwritten every night. Keep at least one copy outside the live server account or on storage the Minecraft process cannot rewrite. CISA recommends offline or otherwise protected backups and regular restore testing in its ransomware recovery guidance. That principle matters even for a game world: a stolen panel account may delete the server and every backup visible in the same panel.

Test a restore on a temporary server. Confirm that the world opens, inventories exist, dimensions load, and permissions work. The backup and migration guide covers the full archive and transfer process.

Keep enough evidence to investigate

Preserve server logs, panel login history, firewall events, add-on installation dates, and permission changes. Restrict access because chat, IP addresses, account names, and commands may be sensitive. Keep enough history to investigate your oldest useful backup.

Review logs when an unknown join is blocked, an operator is added, the allowlist changes unexpectedly, commands appear under the wrong account, files change without an update, or backups begin failing. A log is most useful when server time and timezone are correct and administrators use separate accounts.

Respond to a suspected compromise in order

If you see unexplained destruction, unauthorized commands, or unfamiliar panel activity:

  1. Stop new access. Put the game server behind the firewall or stop it; revoke the suspected account and active panel sessions.
  2. Preserve evidence. Save logs, timestamps, configuration, the suspicious plugin or mod file, and a snapshot or copy before cleaning. Do not keep playing on the affected world.
  3. Identify the boundary. Check whether the event came from a player account, OP permission, plugin, panel login, SSH/RCON, or the host itself.
  4. Rotate affected credentials from a clean device. Change panel, email, Microsoft, SSH, RCON, API, database, and proxy secrets as relevant; enable MFA.
  5. Rebuild or clean the server. Remove untrusted software, patch the system, and re-create access using least privilege. For a host-level compromise, restoring only the world folder is not sufficient.
  6. Restore a known-good backup to a clean environment. Choose a version from before the earliest suspicious activity and verify it before reopening.
  7. Review what failed. Close exposed ports, reduce permissions, replace the compromised add-on, and shorten the gap between backups or log reviews.

Do not immediately restore the newest archive over the live directory. It may contain the same malicious plugin, damaged configuration, or already-griefed world. Containment first, evidence second, clean recovery third.

Bottom line: an allowlist is the front door, not the whole house. Keep real account authentication on, minimize OP and panel access, isolate management ports, trust fewer add-ons, update deliberately, and maintain a backup that the live server cannot destroy. Those layers make a private world harder to enter, limit the damage of one mistake, and give you a credible path back when prevention fails.