Why this comes first
Detection is expensive. Every rule needs to be written, tuned, measured for false positives and maintained as the game and the cheat market move. Configuration is none of those things: it is a one-off decision that either removes an attack or does not, deterministically, at no runtime cost.
On a typical grown ESX or QBCore server, this is the single best ratio of effect to effort available. It is also the part most often skipped, because a settings file makes for a poor screenshot and nobody sells it.
The settings that matter
These belong in a versioned configuration file that lives with your server's source, not typed
into a grown server.cfg and forgotten. The right-hand column is the part most guides
leave out.
| Setting | What it removes | Watch out for |
|---|---|---|
| sv_entityLockdown strict | Client-created entities. Removes ped, vehicle and object spawning by executor outright. | Breaks any resource that spawns entities client-side. This is the one most servers loosen. Migrate the scripts instead. |
| sv_filterRequestControl 4 | Control-request abuse, by not routing the event at all. | Poorly written resources that grab control of entities they do not own may need fixing. |
| sv_pureLevel 2 | Clients running modified game files. | Players with cosmetic mods will be blocked. Announce it before enabling. |
| sv_enableNetworkedSounds false | Sound spam broadcast from a client to everyone nearby. | Resources that rely on networked sound effects need a server-side path. |
| sv_enableNetworkedScriptEntityStates false | A class of state replication abuse between clients. | Check resources that synchronise entity state through this mechanism. |
| sv_disableClientReplays true | Client-side replay capture. | Little practical downside for a roleplay server. |
| game_sanitizeRagdollEvents true | Forced ragdoll griefing. | None in normal play. |
| game_sanitizePlayerAttachment 2 | Attaching objects and players to other players without consent. | Resources doing legitimate attachments need review. |
| game_enableVehicleHijackFix true | A hijack exploit path. | Also disables legitimate F-key carjacking. A real gameplay decision, not a free win. |
Blocked network game events
Beyond the settings above, FiveM lets you refuse specific network game events with block_net_game_event. The pickup and weapon-removal events are the usual candidates:
they are rarely needed by legitimate scripts and are directly useful to an attacker. Add them one
at a time and watch for breakage rather than pasting a list wholesale.
Culling distance
Purely visual cheats (ESP, wallhacks, radar) cannot be detected by a sandboxed resource, because nothing about them touches the server. They can, however, be partly devalued. What the client never receives, no overlay can draw. Setting entity culling and network scope as tightly as your gameplay allows is the only measure against that category with a real effect.
What it costs you
Every one of these settings has a price, and a guide that does not name it is not being straight
with you. sv_entityLockdown strict is the sharpest example: a large share of
community resources spawn entities from the client because it was easier at the time, and
enabling strict mode breaks them.
The temptation is to drop back to relaxed. That converts a fixed cost, migrating a
handful of resources, into a permanent hole. Plan the migration into the work instead. It is
finite, and it is the difference between a server where spawning is impossible and one where it
is merely inconvenient.
Whenever you are about to loosen a setting to fix a resource, you are choosing between fixing one script once and leaving one attack open forever.
A setting that does not exist
While building our own hardening manifest we went looking for the source of every convar we were
setting. One of them, sv_pure_verify_client_settings, which appears in several widely copied hardening
lists, returns zero results in the FiveM codebase. It is not a disabled feature or a renamed
one. It was never there, so setting it does nothing at all.
We removed it from our own configuration. The wider lesson is worth more than the specific finding: hardening lists get copied between blog posts far more often than they get verified, and a setting that does nothing is worse than none, because it feels like protection.
Drift: the silent failure
The most common way a hardened server stops being hardened is not an attack. It is a Tuesday evening, a broken script, and somebody loosening one value to get the server back up, and then nobody remembering.
Two habits prevent it:
- Keep the intended values in a manifest that lives in version control, separate from the file that applies them.
- Have something compare the live values against that manifest at boot and complain loudly on a difference. A deviation should be an alarm, not an archaeology project six months later.
This is the first thing SwisserAC does when it starts, and it is deliberately the least clever part of the product. Comparing two lists of values catches more real problems on a live server than most detection rules do.
What hardening cannot do
Configuration closes the doors that FiveM lets you close. It does nothing about the doors your
own resources opened. Every RegisterNetEvent on your server is a function any player
can call with any arguments, and no server setting changes that. That is a separate piece of work, and on a grown server it is
the larger one.
It also does nothing about a resource that is malicious to begin with, which is its own problem again.