I was thinking and, if I put something in Replicated Storage, like a remote event, could an exploiter delete or alter the remote event? Or another example, if I had a part which for some reason I needed to be created on the client and I stored it in Replicated Storage could an exploiter mess with the properties? If the part was red, could an exploiter make it blue so when the client clones it, it is blue instead of red? If so, how much of a danger is this and should I be concerned or is there anything I should avoid putting in Replicated Storage?
3 Likes
ReplicatedStorage replicates from the server to the clients. Only the server can change the values or objects for everyone, as is how FE works. Yes, they could delete the remote event. However, this would only work client-sided and the server and every other player would still see it exist.
The client can only change things for themselves, not for other or the server. This is why FE was such a great update, as it prevented server side exploits.
4 Likes
From the wiki:
Although the client can access and modify ReplicatedStorage, these changes will not replicate to the server or other clients
1 Like
Ok, that’s what I was wondering! Thanks! 
Yep, glad I could help. As long as FE is enabled (which I have no idea why you would not want it enabled), the client can only change things locally. This is how speed hacks work, as the client changes their walk speed locally, and the character physics are also computed locally. The only thing the client can change serve raided is through remotes and their character, which the network own.
It’s always enabled. You can’t turn it off.
1 Like
Was never possible. That was the result of client-based changes being replicated and/or propagated to the server. Filtering sets up a wall where the greater majority of client propagations are rejected, save for some.
@colbert2677 That’s my point; Without FE the client could modify things that would replicate to the server and other clients, which basically allowed them to change any values they wanted. (Which made server-sided exploits really easy)
@posatta You used to be able, glad they removed the feature
1 Like
Yes but that doesn’t mean server-side exploits ever existed. Exploits have and will always be client-sided. FilteringEnabled simply changes the replication behaviour of the DataModel.
1 Like
Fair, I meant that values could be changed on the server by server-sided. Obviously, code is not executed on the server, so I see your point. Sorry for my bad explanation.