TL;DR: don’t store private or secret things in CreatiCode like user data if you wanna make an app like a social media or something because databases and storage is able to be hacked regardless of you hiding your code blocks when publishing a project, which is not great. CC isn’t popular enough for that to even be a possibilty currently, but when its audience becomes more diverse and starts to have people inspecting its code and looking for vulnerabilities, things could get ugly for some projects.
Sorry for the all caps title, but this mainly concerns anybody doing anything with databases and chatting systems (like what @Tyller_ is making). You don’t need to take immediate action, but I’d say by at least when CreatiCode blows up in popularity. Basically, CreatiCode is possible to hack (in many ways) so you should never be storing stuff like banking details or whatever, especially if youre a famous/often targeted person. I say this because of the nature of Scratch itself, which it’s built on, its past vulnerabilities, and other things I can sense coming mile away. I know with my game YOUniverse3D that people are going to attempt hacking it and therefore hacking CreatiCode, so I want to let it be known in order to minimize the potential of destructive actions caused by random internet people. With my game that won’t be much of an issue because data is stored on my personal site and server, and hacking the game wouldn’t provide much benefits other than fun.
What I have observed
CreatiCode allows for data storage with things like databases and private/public variables which is “secure”. A SUPER big programming principle is “Never trust the client”. The client means the user’s device. For example (dw, creaticode doesnt do this), a horrible thing to do would be coding a login page on ur site that checks if the username and password are right by having the server send the password corresponding to that username and having the client check if the submitted password is correct, and then doing tasks as normal. On the outside, it might look normal to you and you’d likely notice nothing weird. But to get on the inside, anyone can juse use “inspect element”, edit the page code to show them the user’s password instead of using it for validation, then now the attackers can log into ANYONE’s account and takeover as they please. CreatiCode (as in the site and forum) doesnt do this, but this basically what’s possible with the playground/project runner if you’re using databases or storing data in other ways for sensitive data like chat messages or passwords. CreatiCode is capable of making full feature packed applications and games, but you have to be very careful about security to ensure that users of your app/game don’t get all their user data leaked or destroyed. To make it easier to understand here’s a block code demonstration:
Here, the inputs of the username and password boxes are taken, the client goes to the server and asks the database to give the password of a user where their username is equal to that of the username box value, and the server/database return it to the client, the client checks if it’s right, and either lets the client go (“accepted”) or denies (“incorrect password”) . This is exactly how websites SHOULD NEVER implement validation, but the only reason to do it on CreatiCode is because it’s the only way. And right now (with my code blocks exposed to the public), someone can go inside the code and click a block and authenticate themselves (just let themselves in, not even like uninvited guests, literally trespassers). The playground offers nice web & utility-related blocks, but the thing is they run on the client and there is NEVER going to be a solution to secure validation or preventing project databases being letting in just anybody unless CreatiCode adds new blocks, implements a new project running system or feature, or changes the way the blocks are. I will give a list of suggestions at the end for how they could fix this, but my opinion is that CreatiCode shouldn’t be used for cases where you really need to make sure someone is who they say you are unless you are working with something simpler or where it doesn’t matter if someone hacks something on your project
And you may be thinking, “but I can hide my code blocks to prevent others from just clicking on blocks i dont want them to?”, but that is wrong, as client side restrictions that can be bypassed by anyone tech savvy enough. Hiding the source code of CreatiCode projects is rendered useless if someone flips open their webtools inspector or something and starts removing code and making the project editor appear as normal and then click a block like to give coins or mess with database blocks. Hidden code blocks (when you publish your project) won’t stop a hacker, because in order for the project to be run, the CreatiCode site has to send the project file to you in order for it to play it. The client/site then does all the work, but a hacker can easily intercept that and download the project and use a program to visualize that file or just load the same file in CreatiCode again but owned by them (like making a copy of the project) regardless of any restriction on the client. Although that wouldnt let them mess with your project, them understanding the code and figuring out how to bypass restrictions on a seperate copy is just as harmful since they could then perform the same thing on your project.
How CreatiCode could fix it
None of these options are 100% doable or would be overkill and would waste CreatiCode’s time/money/resources but they are purely hypothetical:
- Projects are proxied, meaning instead of running on the user’s device, they run on CreatiCode servers and are streamed to users. The client would consist of the streamed visual project running (like video streaming) and giving the project frame inputs like clicks, scrolls, right clicks, left/right drag clicks, and key presses would send them to the server. This way, the only thing that the user can possibly do is inputs, they get sent to the server, and backend code magic does its thing, and plays a project. This would make projects unhackable because users will only be able to change so much and it would just change it for them on their side. This would remove capabilities like selecting text/ copy&pasting unless you make an even more complex system to handle things like that to make it more accessible and natural. With this it would be ensured that code that runs pertaining the server could not be modified by an outside source and therefore be trusted. This could make projects run faster, or run slower depending on how it’s implemented and they would also need to keep in mind other things.
- And a doable one I actually might make a new topic about instead