What does the official event guidance establish?
This is an evergreen engineering checklist, checked against Cfx.re documentation on 11 September 2026. It does not announce a new vulnerability or claim that a particular resource is exploitable.
Cfx.re distinguishes local handlers from networked events and recommends server-side checks for valuable actions. Client-controlled input should not determine permissions, inventory changes or a payout without validation. Read Secure Your Events.
The event-listening reference also warns that the global source value is only reliable for the initial event call. In Lua or JavaScript, keep the caller in a local variable before a wait or asynchronous continuation. Read Listening for Events.
Where should a developer start the review?
Choose one valuable action, such as completing a delivery. Write its intended result in a sentence before reading every handler in the resource. An example contract is: an eligible player can complete an active delivery once and receive the reward assigned to that delivery.
Next, trace the actual call path. Name the client input, the server lookup, the decision and the final data change. Mark which values come from the caller and which come from state your server controls. If a helper hides the final inventory or account write, follow that helper too. This is a proposed review method, not a description of a specific framework API.
Do not begin by adding checks at random. First identify which business rule each check protects, then give it a rejection case. A numeric field being well formed does not establish that its value is allowed for the requested action.
How do you test rejection without risking a live economy?
Use an isolated development server and disposable test records. Write down the initial balance or inventory state and the result expected from each test. Exercise missing fields, wrong types, an ineligible player and an action that no longer exists. After rejection, check the stored state as well as the response.
Add a repeated-request case to your plan. Decide whether the second request should report that the action is complete or return a harmless rejection. The important observable result is that one completed action does not produce a second reward. Implement the state transition with the consistency guarantees your storage and framework provide.
Keep this testing limited to systems you own or have permission to assess. There is no need to probe someone else's server to evaluate your handler.
What changes when the handler waits for another service?
Preserving a caller variable is necessary for the documented source-lifetime issue, but it is not a complete transaction design. Our recommendation is to review whether the player session and action are still valid when the asynchronous work returns. A request that was eligible before a wait may no longer be eligible afterwards.
Document what happens when a lookup fails, a dependency times out or the caller disconnects. Do not report a successful reward until the authoritative write succeeds. If your framework splits inventory and payment across separate operations, review partial failure explicitly rather than assuming both completed.
What should go in the release review?
Attach a small result table to the change: scenario, expected state, actual state and the version tested. Keep unresolved cases visible. This article is a review plan; it does not supply a production handler or claim that these tests have already run on your resource.
Use the framework comparison to keep framework assumptions explicit, and the server fix order when an event problem is part of a wider operational issue.