Skip to main content

Keep FiveM resource secrets out of replicated convars

A FiveM resource may read configuration through convars, but the command used to define a value determines who can see it. Use this audit before adding database credentials, webhooks or API keys to configuration. You need permission to edit your own server files and access to the resource's official setup instructions.

Understand the exposure boundary

Cfx distinguishes standard convars set with set, client-replicated values set with setr and public server-information values set with sets. Server-information values appear in the listing and info.json. Replicated values can be read by client scripts. Neither is an appropriate place for a private credential.

A standard convar is not a password vault. Server-side resources and authorised administrators can still access server configuration, and careless logging can expose it. Use a server-only setting only when the resource documents that method; some resources use their own configuration files or environment variables instead.

Audit without spreading the secret

  1. Back up the relevant configuration privately. Do not paste it into a public validator or screenshot the entire file.
  2. List credential names, not their values: database connection, webhook, third-party token and any resource-specific private keys. Find every place each is assigned, including included configuration files.
  3. Compare the setting with the resource's instructions. If it requires a server-only convar, use its documented name with set, not setr or sets.
  4. Keep harmless client preferences separate. A language or interface colour may legitimately be replicated; replacing every setr with set can break a resource that needs client access.
  5. Check client scripts and downloadable resource files for hard-coded copies. A value hidden from the listing can still leak if included in a client bundle.

Handle a value that was already public

Assume an exposed key may have been copied. Restrict or revoke it with the issuing service, create a replacement with only the required permissions, and update the documented server-only location. For database credentials, coordinate the change so dependent resources receive the new value together. Do not simply hide the old text and leave the old key valid indefinitely.

Make this change during a planned window where the resource requires restart. Check its startup output for successful authentication while avoiding debug modes that print connection strings. Test one ordinary resource action. A successful boot alone does not prove that a background integration can authenticate.

Verify and recover

Inspect your own public server-information response and client-visible settings without publishing the results. Confirm the secret's name and value are absent where they should be private. Review recent logs for accidental disclosure and restrict any retained diagnostic copies.

If functionality fails, recheck quoting, configuration order and the resource's expected setting type. Roll back harmless structural changes if necessary, but never restore a compromised credential as the long-term fix. Current Cfx convar rules describe the transport boundary; the individual resource remains responsible for reading, storing and logging the value safely.

No comments to display