The FiveM Server-Authority Checklist
Server authority means the client can only ask, never tell — every privileged outcome is decided and computed on the server. This is the reviewable procedure for checking that claim on any FiveM resource: inventory every net event, read the first lines of each handler for a validation check, then confirm behaviorally with forged, out-of-state, and spam requests against a staging server.
Every player's client runs on hardware the server operator doesn't control. A cheat menu is not a sophisticated attack — it's a program that calls the same net events a resource already registered, with whatever payload the attacker chooses. Any client can fire any registered server event with any arguments; a resource is only as safe as what its server-side handler does before it trusts them.
'Server-authoritative' has a concrete, checkable meaning in code: the server holds the truth — balances, inventory, permissions, position — and only the server writes it. A client requesting an action is normal and necessary; a client supplying the number that gets written is the failure mode this checklist exists to catch. Client-side prediction for smoothness is fine. Client-decided outcomes are not.
This procedure works whether or not you have source access. The static half — read the code, grep for the trust smell — applies to open resources and the open portions of escrowed ones. The behavioral half — test it live on staging — applies to anything you can install, escrowed or not.
Reproducible, step by step.
- 01Inventory the surfaceList every RegisterNetEvent / RegisterServerEvent, export, NUI callback, and command the resource registers. You can't audit a surface you haven't enumerated.
- 02Read the first five lines of each handlerValidation should be immediate and visible — a source check, a state check, a permission check — before any state mutation happens. A handler that mutates state on line one and validates on line six has already failed.
- 03Grep for the trust smellSearch open source for a client-sent argument reaching a balance, inventory, or permission write with no server-side lookup in between. In Lua this often looks like an event handler parameter flowing straight into a database write or an export call.
- 04Identify who owns the numberFor every amount, price, or quantity in a handler, trace where it came from: a server-side config or database lookup is authoritative; a function argument sent by the client is not authoritative unless it's independently checked against server state before use.
- 05Check state and range, not just typeA correctly-typed integer can still be wrong. Confirm bounds are enforced and that the player's current state — on duty, within range, alive — is checked against server-held truth, not a flag the client asserts about itself.
- 06Deploy to a staging serverSame framework and artifact version as production, isolated from real players, so a forged request can't touch anything that matters.
- 07Run the live behavioral testsFrom a second client or a tool that lets you fire events directly, attempt the action with an out-of-range or forged argument, from an unauthorized state, and at above-human rate. A passing resource rejects all three.
- 08Record the result per eventPass or fail, with a file and line reference where source is available, or the exact behavioral test outcome where it isn't.
What this measures — and what it does not.
The second column is the one that matters. A method that only advertises its reach is a brochure; the limits are what let you judge whether a result means anything for your server.
What it measures
- Whether a server-side check exists before each privileged state change.
- Whether a forged, out-of-range, or out-of-state request is rejected in a live staging test.
- Where a number used in a state change — price, amount, permission — provably originates: server config or database, versus a client-sent argument.
What it does NOT measure
- Encryption or obfuscation strength of any escrowed portion — this checklist is about authority, not about how hard the code is to read.
- Whether the resource has ever actually been exploited in production — no known incident is not evidence of a passing grade.
- Performance cost of the validation itself — a resource can be fully server-authoritative and still be slow. That's the runtime test methodology's question, not this one.
What counts as a pass, and what does not.
| Criterion | Pass | Fail |
|---|---|---|
| Privileged state changes | Every write to money, inventory, permissions, or position is preceded by a server-side check against server-held truth. | Any single write accepts a client-sent value — an amount, an item, a permission flag — with no independent server-side check. |
| Forged-argument live test | A forged or out-of-range argument sent directly to the handler, bypassing the normal UI, is rejected and logged. | The forged argument is accepted and produces a state change. |
| Out-of-state live test | The handler rejects the action when the player is in a state it shouldn't be valid for — off duty, out of range, dead. | The action succeeds regardless of state. |
| Rate / spam live test | Firing the event well above human interaction speed is throttled or rejected server-side. | The event executes every time it's fired, with no server-side cooldown. |
Our own results against this method.
- This is the checklist we hold our own bridge and products to internally. It is not yet published as a completed, line-by-line audit transcript for any individual product.
- ForgeCore (vf_core), the free framework bridge every Vice Drip product runs on, ships fully open specifically so this checklist can be run against it directly — that audit is available to run today; we have not yet published our own written transcript of running it.
- No product in the catalog has a published, dated record of passing the live staging-server behavioral tests in steps six through eight. Server authority is currently an architecture claim — true by design and readable in the open portions of the code — not yet a tested-and-dated claim for every product.
- Nothing here is described as unhackable or exploit-proof. A resource can pass every item on this checklist and still contain a bug. The checklist closes off a known, common failure class; it does not certify the absence of every possible one.
What does 'server-authoritative' actually mean?
The server decides and computes every privileged outcome — a balance, a permission, a position — from its own stored state. The client can request an action, but it never supplies the number that gets written; it can only ask, never tell.
How do I test this without reading the source?
Behaviorally, on a staging server: try to trigger the feature from an unauthorized state, with a forged value, and at spam rate. A server-authoritative resource rejects all three regardless of what the client sends.
What does a client-trusting handler look like?
In outline: an event handler that receives a price or amount as an argument and writes it to a balance or database without first looking that value up from server-side config or state. If the number a handler trusts didn't come from the server's own memory or database, the client supplied it.
Does escrow make this checklist impossible to run?
It limits you to the behavioral half — you can still test live on staging without reading the code. Ask the seller in writing how they validate source, permission, rate, and argument types, then verify what you can behaviorally.
Published 2026-09-02 · Last reviewed 2026-09-02 · All methodology