LUA security foundations

Treat external data as untrusted and protect identities, permissions, secrets, and stored information.

Chapter goal: Treat external data as untrusted and protect identities, permissions, secrets, and stored information.

Simple explanation

Security is a locked door with a guard. Authentication checks who someone is; authorization checks what that person is allowed to do.

In LUA, this chapter is about checking who may perform an action and validating all data at a trusted boundary. Start with the idea above. Then connect each symbol to a value or action in the example.

Do not try to remember every symbol. First ask what data the program has, what it does with that data, and what result it creates. Technical words become easier when you connect them to those three questions.

Why this topic is important

A feature that works but exposes data or trusts forged input is not complete. In LUA, the syntax may look different from other languages, but the thinking skill transfers: name the data, choose the right operation, and make the next step obvious.

When to use it

Apply security to authentication, APIs, file access, payments, database rules, and multiplayer events.

Example code

RegisterNetEvent("shop:buy", function(itemId, amount)
  local playerId = source
  if type(itemId) ~= "string" or type(amount) ~= "number" then return end
  if amount < 1 or amount > 10 then return end
  purchaseOnServer(playerId, itemId, amount)
end)

Line-by-line explanation

• RegisterNetEvent("shop:buy", function(itemId, amount) — This defines a reusable function. Its name describes the job that other code can call.
• local playerId = source — This stores or updates playerId. The value on the right is worked out first, then saved under that name.
• if type(itemId) ~= "string" or type(amount) ~= "number" then return end — This checks a true-or-false condition. The controlled block runs only when that condition is true.
• if amount < 1 or amount > 10 then return end — This checks a true-or-false condition. The controlled block runs only when that condition is true.
• purchaseOnServer(playerId, itemId, amount) — This line supports one focused piece of application logic. Read it together with the block directly around it.
• end) — This line supports one focused piece of application logic. Read it together with the block directly around it.

What the output means

The protected action runs only after identity, permission, and input checks pass.

The output is evidence that the program followed the instructions. If your result is different, read from the first line and write down how each value changes. That is debugging, not failure.

Mistake example

RegisterNetEvent("shop:buy", function(itemId, amount)
  purchaseOnServer(source, itemId, amount) -- trusts client data
end)

The protected action trusts caller-controlled data or skips a permission check.

Fixed version

RegisterNetEvent("shop:buy", function(itemId, amount)
  local playerId = source
  if type(itemId) ~= "string" or type(amount) ~= "number" then return end
  if amount < 1 or amount > 10 then return end
  purchaseOnServer(playerId, itemId, amount)
end)

The corrected version checks identity, permission, and untrusted values at a trusted boundary.

Common mistakes

• Trusting client-side validation.
• Putting secrets in mobile or web code.
• Checking login but forgetting authorization.

Warning: Change one part at a time. If you change many lines together, it becomes harder to learn which change caused the result.

Real use cases

• Validate a RedM reward on the server.
• Protect an API endpoint by role.
• Keep Firebase rules least-privileged.

Small real-project example

A reward claim is only paid out after the server re-checks the input and the player's real progress.

RegisterNetEvent("quest:claimReward", function(rewardId)
  local playerId = source
  if type(rewardId) ~= "string" then return end

  local reward = Rewards[rewardId]
  if not reward or not PlayerHasCompletedQuest(playerId, reward.questId) then
    return
  end

  GivePlayerMoney(playerId, reward.amount)
end)

How the project example works

• source identifies which player triggered the event; the client cannot spoof it.
• type(rewardId) ~= "string" rejects malformed or unexpected input before it is used.
• PlayerHasCompletedQuest re-checks eligibility on the server, ignoring anything the client claims.
• Money is only given after both the input check and the game-state check pass.

Practice exercise

1. Reject an unauthorized action.
2. Validate untrusted input on the server.
3. Remove any secret that is stored in client code.

Tip: If the exercise feels too large, complete only steps 1 to 3. Small working code teaches more than a large unfinished project.

Mini quiz

1. What data is untrusted?
2. What is the difference between authentication and authorization?
3. Which check must happen on the server?

How to read AI-generated code

Do not copy AI code first. Read it like a detective. Find the data, follow the changes, and locate the final output. Ask AI to explain a line only after you have made your own guess.

• What data goes in?
• What values are stored?
• What calculation or decision happens?
• What is printed, displayed, saved, or returned?
• What can go wrong?
• Can you rename one value and still explain the code?

RedM safety check

RegisterCommand creates a named command. Its callback receives source (who triggered it) and args (the words after the command). Client code handles the local player's screen and input. Server code owns trusted game state. Never trust prices, rewards, permissions, or item counts sent by a client; check them again on the server.

Before you move on

• I can explain this topic in my own words.
• I can read the small example without AI.
• I can change the example and predict the new result.
• I can find and fix one simple mistake.
• I can name one real project that uses this idea.

Next topic

Next, learn performance and measurement. Before opening it, explain this chapter out loud in under one minute.