Engineering
A checklist for reviewing FiveM resources
A checklist for reviewing FiveM scripts before release: event validation, SQL placeholders, secrets, cleanup, resmon, compatibility, NUI focus and docs.
Overview
Whether you are about to sell a script or install one on a live server, twenty minutes with a checklist catches most of the problems that later cost days: exploitable events, slow loops, leaking tables and hard-coded secrets. Here is the list experienced reviewers run through.
Security
- Each
RegisterNetEventhandler validates arguments and never trusts amounts or prices — see secure server events. - Callbacks validated like events — see callbacks.
- Queries use
?or named placeholders — see SQL injection. - Rate limits on actions that pay or query — see rate limiting.
- No webhooks, keys or admin lists in client/shared files.
- NUI callbacks do not grant anything the server does not re-check.
Performance
- Loops sleep when idle;
Wait(0)only when drawing or reading input. - Distance checks with vectors, not natives in tight loops.
- No database queries inside per-frame code.
- resmon idle ≈ 0.00–0.02 ms — see resmon.
- NUI messages sent on change, not every frame.
Correctness and cleanup
local src = sourceat the top of handlers.- Per-player tables cleared on
playerDropped— see memory leaks. - Entities, blips, zones and NUI focus released on
onResourceStop. - Handlers registered once, at file level.
- Errors handled (nil players, failed queries, missing items).
Compatibility
dependency/dependenciesdeclared in the fxmanifest.- Framework and inventory detected or configurable — see bridges.
lua54 'yes'set; no deprecated natives where alternatives exist.- Works after
restartwithout a full server restart.
Usability
- Config with defaults and validation — see config best practices.
- Text in locale files — see localization.
- README with install steps and troubleshooting — see documentation.
Frequently asked questions
What should I check before installing a FiveM script?
That its server events validate input, queries use placeholders, it idles near 0.00 ms and it cleans up after players and restarts.
How do I spot an exploitable event?
Look for server events that accept amounts, prices or item names from the client without re-checking them.
Can I review escrowed scripts?
Only the unencrypted parts (config, NUI); test behaviour on a dev server and check resmon.
What is a good idle resmon value?
Around 0.00–0.02 ms for a resource that is not doing anything.
Need this built, not just explained?
Ten years of FiveM work, from Lua to NUI
Custom resources, React NUI, ESX / QBCore / Qbox integration, OneSync performance audits and security reviews — plus the websites and SEO around your server brand.
Related guides
- EngineeringWriting server events that cannot be abusedAny client can call any event you registered with RegisterNetEvent, with any arguments. In each handler: copy source into a local, check argument types and ranges, re-derive everything from server state (prices, amounts, rewards), verify the player can do this now (distance, job, item, cooldown), and log refusals. Events only other server scripts should use are registered with AddEventHandler alone, so clients cannot trigger them.
- EngineeringOptimising FiveM Lua scriptsSleep loops dynamically (long Wait when nothing is nearby, Wait(0) only when you must draw or read input), replace polling with events and state bags, measure distance with #(a - b) on vectors, read values like the player ped once per tick (or from ox_lib’s cache), use backtick hashes, avoid creating tables and strings in hot loops, and batch database writes. Measure before and after with resmon and the profiler.
- EngineeringKeeping your database safe from SQL injectionNever concatenate or format player-controlled values into SQL. Use oxmysql placeholders — ? or named @name parameters — and pass values separately, so they are always treated as data. Table and column names cannot be parameters: pick them from a fixed whitelist. Validate types (numbers are numbers), escape % and _ in LIKE searches, and give the server’s database user only the rights it needs.
- EngineeringFinding and fixing memory leaks in FiveM resourcesMeasure first: watch the resource’s memory in resmon or print collectgarbage('count') (kilobytes) over time. The usual culprits are per-player tables not cleared on playerDropped, handlers or threads created inside other handlers, caches without size limits, and entities or blips created and never deleted. Clean up on playerDropped and onResourceStop, bound every cache, and register handlers once at file level.