Permissions and security

The design assumption is that the client is hostile. Everything below follows from that.

What the server decides

Prices, random outcomes, inventory changes, payments, quality, ranks and heat are computed on the server. The client asks for things; it never reports results.

How requests are validated

Every remote call goes through the same path before it reaches any logic:

• Allowlisted. An action the server does not recognise is rejected outright.
• Rate limited. Repeated calls beyond a threshold are refused.
• Serialised per player. One request at a time per player, so the same action cannot be fired concurrently to race a check.
• Permission checked. Administrative actions verify permission on the server, not by trusting that the client only shows the console to administrators.

Rejections are recorded with their reason.

Two-phase actions

Crafting and harvesting could otherwise be cheated by a client that simply skips its own progress bar. Instead:

1. The client asks to begin. The server decides whether it may, and issues a token with a duration.
2. The client asks to complete, presenting the token. The server checks that enough time has actually elapsed, that the token has not expired, and that the player is still in the right place.

A completion that arrives too early, too late, or from the wrong location is refused. The yield is rolled on the server, and the possible range is never sent to the client.

Buyer verification

Street sales validate the buyer server-side. Buyers are created as networked entities so that they can be resolved reliably, and a sale whose buyer cannot be resolved is rejected by default.

That default can be relaxed if your server produces unresolvable entities under load. With it relaxed, such sales are marked as unverified and still have to pass every other check — rate limit, cooldown, alive and vehicle state, quantity bounds, minimum police and real inventory. Either way, the verification result is recorded on the transaction row, so you can measure how often it actually happens on your server before changing the setting.

Settings worth reviewing

Two in particular, both in the security block of config.lua:

Buyer verification — described above. Strict by default.

Flag decay — rejected requests count towards a threshold that eventually kicks a player. Flags expire after a configurable period, so a long legitimate session cannot slowly accumulate its way to a kick. Lowering the decay makes kicks rarer; raising it catches slower probing.

Reporting a vulnerability

Privately, please. There is a disclosure path on the support page. A public report puts every server running the resource at risk during the window before a fix ships.