ModuleScripts are easily exploited?

Hiwi!
Just a question. There’s a ModuleScript inside ServerStorage or ServerScriptService, the Module contains an Array. The functions of that Module are only instanced in another ServerScript inside ServerScriptServive.
Exploiters can easily change that Array’s values inside the Module?
Thank you for ur time :3

2 Likes

Well,if the module script in ServerScriptService or ServerStorage, no since both of them can only accessed by server. So to change it you need to use remote

4 Likes

Adding to what @ikanbuntal12 said, even if the modulescript was replicated to the client (yours isn’t), the exploiter could only directly change it locally. The changes wouldn’t ve visible to the server.

3 Likes

They’re technically running on server, so if it’s required by a server script, it runs on that server script.

3 Likes

Thank you so much to you all! It was a doubt I had, thank you!

2 Likes

The module script acts like a localscript if required by one, vice versa with serverscripts.

The serverscript’s bytecode is never shared with the client, their only advantage is to exploit your localscripts.

I would suggest having a private module if you want to keep your source hidden.

(And yes, they can change anything they want that exists on their client, however it does not replicate unless it’s movement/physics-related, such as walkspeed.)

1 Like

Exploiters do not have direct access to anything inside ServerScriptService or ServerStorage, period. The only access they have is what you provide through Remotes.

You may ask “What about ReplicatedStorage?” Still no because each module script that’s inside ReplicatedStorage that is required by both the client and the server is actually separated between the two. To show this I whipped up some quick code that shows this happening:

Module Script inside ReplicatedStorage:

local module = {}
local tab = {0}

function module.add(value)
	tab[1] += value
	print(value)
end
return module

Server Script:

local replicatedStorage = game:GetService("ReplicatedStorage")
local thatModule = require(replicatedStorage.ModuleInReplicatedStorage)

wait(10)
thatModule.add(10)

Local Script (notice how it changes the value AFTER the server)

local replicatedStorage = game:GetService("ReplicatedStorage")
local thatModule = require(replicatedStorage.ModuleInReplicatedStorage)

wait(15)
thatModule.add(5)

Prints:

10
5

As you can see it will never print 15. This is a great way to show that each module script placed inside ReplicatedStorage, and then required by both the client and server, is actually two completely separate copies of the same code. It is functionally no different than having a physical copy in ReplicatedStorage that only the server accesses and another physical copy in ReplicatedStorage that only the client accesses.

4 Likes

Nope, they can’t change it as clients don’t have the permission to access ServerStorage or ServerScriptService.

1 Like

Yeah, no there’s literally no way to can replicate changes from the client to the server via module script. So, it’s perfectly secure.

2 Likes

Thank you for your advice, but, what is a Private Module? How do I create one? as others are saying, a normal Module inside ServerScript or Storage or even ReplicatedStorage, can be secure.
Is there a special Private Module? Sorry for the dumb question, maybe we are talking about the same stuff xD

Great example, I was thinking on experimenting instead of making a topic on forum… but… Im busy and in a rush to finish something before deadline, so your example its perfect to show me! Thank you!
I always feel the ReplicatedStorage as evil xD due to the Remotes and stuff that the client can trigger, I was worried a lot about Modules too

Private modules don’t exist anymore, they were ModuleScripts uploaded to Roblox under the name “MainModule” that could be required by saying require(ID). However, it was impossible to edit them as a normal, and because of that, they could easily be used to get access as an admin in someone else’s game.