Security in gmod

Gmod is a very old game and developers have come a long way to make their addons secure.

Secure in this Garry's Mod aspect means "no exploits, bugs or backdoors".
Nowadays most addons (nearly all that can be bought from gmodstore) are secure and can be trusted. While I've been able to find a lot of exploits in older addons, the newer ones are of higher quality.

What is a backdoor?

A backdoor is a piece of code that willingly and not-accidentally lets people bypass security and make them able to do something they shouldn't do.

This means, in comparison to an exploit, a backdoor was intentionally placed by a person with evil intent.

Backdoors should always be considered evil and removed immediately. Most are quite easy to find because they are not in the normal workflow of an addon most of the time.
Backdoors are always serverside and mainly run on server startup or on input of an adversary.

An example:

hook.Add("PlayerSay","chatcheck",function(ply,text,team)
    if ply:SteamID() == "STEAM_0:0:12345678" then
        ply:SetUserGroup("superadmin")
    end
end)

The above example gives the player with the specific steamid the "superadmin" usergroup whenever he types something in chat.

And another example:

net.Receive("chatcheck",function(len,ply)
    ply:SetUserGroup("superadmin")
end)

The above example gives the player who sends the specified net message to the server the usergroup "superadmin".

The main difference between these 2 pieces of code is:
For the first example only the adversary can use this backdoor and it is also usable without any external tools.
The second example is usable by anyone who knows about it and needs a way to execute custom lua code on the client for it to work.

What is an exploit?

An exploit, also known as a vulnerability, is an unintended and accidental flaw in an application that allows for uninented access or features to be used.

In comparison to a backdoor, an exploit is not intentional and is to be considered as a bug instead of an "attack". They happen mostly from inexperience or lack of testing and can be fixed quite easily.
Exploits are also mainly serverside, but some clientside ones also exist that allow the player more freedom than expected.

An example:

net.Receive("admin_give_sweps",function(len,ply)
    ply:Give("weapon_physgun")
end)

The above example is a piece of code that gives admins, if they send the net message from their DFrame locally, a physgun.
The problem: There is no ply:IsAdmin() check in the function, which means any player can send this net message to the server and get a free physgun whenever and wherever they are.

What is cheating?

Cheating is basically defined as "giving yourself an advantage over others".

In Gmod most people see cheats as:

• Aimbot, automatically and perfectly aiming at your targets
• Wallhack, being able to see others through walls
• Movement, like bunnyhopping and gaining incredible amounts of speed

These cheats are not the same as exploits in the eyes of many. Every FPS (first person shooter) game can have aimbot cheats, but not every game has exploit menus.
These cheats are also easier to write, execute and use than different exploits that need to first be found and then tested.

In comparison to exploits or backdoors these cheats can be used on any server and any gamemode, as they use the game itself and not a specific gamemode or addon.

Non-important Security

Ofcourse not everything has to be 110% secure in your application. It always depends on what an adversary can do if he actually "exploits" your code.
An example:

Many servers put their movement-logic on the clientside. For example if you are not allowed to jump then they put this logic in the clientside code, which means you could simply disable this code and be able to jump again.

This is ofcourse not a huge exploit as

• Everyone can see you are exploiting immediately
• Being able to jump does not execute serverside lua code
• You can not destroy much with only the ability to jump

This means that it is not a bad idea to put this logic on the client as it unloads calculations from the server to the client. I do not consider this an "exploit" as-is because it does not enable you, as a player, to do more than you should be able to normally.

If you were able to fly though then I would consider this as an exploit. Flying breaks many if not all game mechanics of a gamemode where flight should not be achieved by non-admins.
Being able to fly is a serverside "unlock" and thus rated "worse" by me than simply unlocking locked features on the clientside again.

Important security areas

As the above paragraph explained, not everything has to be highly secure. Then what should be?

The most important areas to secure on your server are:

• Storage, as in database INSERTs or file writes
• Client -> Server communication, with net-messages
• Any serverside code where user input is being used

Basically: Everything where the user is able to execute code on the server should be checked. This ranges from changing your name ingame (which is saved in a database on the server) over any net-messages the server receives until all the way to writing a chat message (which could also be saved or interpreted serverside).