FiveM Server Security: A Practical Guide for Server Owners

This is the guide we wish existed when we started running FiveM infrastructure: a single page that lays out the realistic threats to a FiveM server, in the order they tend to hurt, with the concrete controls that address each one. It links out to deeper articles and to the tools we built for specific jobs, but every section stands on its own.

The FiveM threat model in one table

Two things stand out. First, the most damaging threats are fixed by the server owner, not by Cfx.re and not by any product. Second, the order matters: an anti-cheat on a server running a backdoored resource is protecting the front door of a house whose back wall is missing.

1. Resources and backdoors

Server-side Lua runs inside your server process with access to your database connection, your convars, the console and outbound network. A resource that contains a backdoor therefore has all of that too. Backdoors in FiveM are rarely sophisticated: most are a few lines that download a payload with PerformHttpRequest and execute it with load(), hidden behind string obfuscation in a file nobody reads.

The single most effective control is to check every resource before it reaches your server — especially anything from a leak forum, a reseller or a free 'pack'. Read the manifest to find what runs server-side, then look for dynamic code execution, outbound HTTP to unexpected hosts and heavily obfuscated strings.

2. Server events and client input

Any event registered with RegisterNetEvent on the server can be triggered by any connected client, with any arguments. Cheat menus enumerate these events and call them directly. An event like 'shop:buyItem' that takes a price from the client, or 'jobs:pay' that takes an amount, is an invitation.

-- Unsafe: the client decides the amount
RegisterNetEvent('jobs:pay', function(amount)
  local player = GetPlayer(source)
  player.addMoney(amount)
end)

-- Safer: the server decides, and checks the player is allowed to be paid
RegisterNetEvent('jobs:completeDelivery', function(deliveryId)
  local src = source
  local delivery = ActiveDeliveries[src]
  if not delivery or delivery.id ~= deliveryId then return end
  if #(GetEntityCoords(GetPlayerPed(src)) - delivery.dropoff) > 10.0 then return end
  ActiveDeliveries[src] = nil
  GetPlayer(src).addMoney(Config.DeliveryPay)
end)

• Read source into a local at the top of the handler and never accept a player id as an argument.
• Decide prices, amounts and item names on the server from your own config, not from event arguments.
• Check that the player is in a state where the action makes sense — job, location, cooldown, inventory.
• Rate-limit events that can be spammed, and log rejected calls: they are your best cheater signal.

3. Secrets, convars and what players can see

A surprising number of compromises start with a credential the owner published without realising it. Players receive every file in client_scripts, shared_scripts and files, and they can read replicated convars. Server info is public by design.

• Keep sv_licenseKey, database connection strings, Discord bot tokens and webhooks in set convars or server-only files.
• Never commit server.cfg with secrets to a public repository; keep secrets in a separate file you exec.
• If a webhook or key has ever been in a client or shared file, rotate it — assume it has been copied.

The same logic applies to what your server reveals publicly. A join code resolves to your server's endpoint and public metadata; that is how FiveM matchmaking works, not a leak. If hiding the origin IP matters to you, that is a job for a proxy or DDoS-protected network in front of the server, not for keeping the code secret.

4. Host and network exposure

The game needs one port (30120 by default, TCP and UDP) open to the world. Nothing else does. txAdmin's web panel, your MySQL or MariaDB port, Redis, phpMyAdmin and SSH should be reachable only from your own addresses or through a VPN or tunnel.

1. 1Firewall by default and open the game port explicitly.
2. 2Bind the database to localhost or a private network; give the server its own database user with only the privileges it needs.
3. 3Put txAdmin behind an IP allow-list or a tunnel, and enable two-factor authentication for every admin account.
4. 4Use SSH keys, not passwords, and disable root login.
5. 5Restrict outbound traffic where you can: a server that can only reach the hosts it needs cannot download a payload from anywhere else.

5. Permissions and staff access

FiveM's ACE system grants permissions to principals (groups or identifiers). The common mistake is granting a broad group command allow on everything and adding every staff member to it. Grant the specific commands each role needs, attach identifiers you have verified, and review the list when staff leave.

# A moderator can kick and use the report tools, nothing else
add_ace group.moderator command.kick allow
add_ace group.moderator reports.manage allow

# Identifiers are explicit and reviewed
add_principal identifier.fivem:1234567 group.moderator

Resources can be granted ACE permissions too (add_ace resource.name ...). Give that only to resources that genuinely need to run privileged commands, and never to one you have not reviewed.

6. Cheaters and anti-cheat

Cheating happens on the player's machine: injected menus, modified game memory, spoofed inputs. An anti-cheat detects and blocks what it can on the client and on the server, but it cannot make an insecure server event secure, and it is not a substitute for any section above. The two work together: server-side validation removes what cheaters can gain, anti-cheat raises the cost of trying.

7. Supply chain and updates

A resource that was clean when you installed it can ship a backdoor in its next update, and a developer's account can be compromised. Record where each resource came from, keep the original archive, and re-check on every update rather than only on first install.

8. When something gets through

Assume that one day a backdoor will run on your server. The first hour decides how bad it gets. Stop the server, cut its outbound network access at the host, and preserve evidence before you start deleting things. Then identify the resource responsible by diffing against known-good copies, rotate every credential the server could read, and restore from a backup you trust.

A checklist you can work through today

1. 1Scan or review every installed resource, starting with anything from an unofficial source.
2. 2Search your server code for RegisterNetEvent handlers that take amounts, prices, items or player ids from the client.
3. 3Move every secret out of client and shared files and out of setr and sets convars; rotate anything that was exposed.
4. 4Check from outside which ports your host answers on; close everything but the game port.
5. 5Replace blanket ACE grants with per-role permissions.
6. 6Turn on two-factor authentication for txAdmin and every hosting account.
7. 7Write down your incident response steps and test that your backups restore.