Black Box Validators

help
1

I was googling something related to collection validators today when I stumbled onto this blog post from a month ago:

http://blog.east5th.co/2015/06/29/black-box-meteor-shared-validators/

I tried the test for client access to the allow and deny methods for my primary collection (which are stored in my app’s top-level /lib directory for access on both the client and the server), and just as was predicted in the blog post, the entire source of my allow update validator was printed in the console in Chrome:

Post._validators.update.allow.toString() : printed the function source to the console

If I understood the author of the post correctly, he’s saying a collection’s allow and deny validators run only on the server, so should they be stored in a directory accessible only from the server?

And, if that’s the case, should all of the code related to a collection be stored in a /server directory? Are there any other source bits that could be accessed in the console by a malicious individual (potentially)?

2

Yes, allow and deny only run on the server. If you’re allow deny were written perfectly securely it shouldn’t matter if they exist on the client as well. History shows us though that security related bugs are common and thus allowing security critical code to be sent to the client for easy inspection by a malicious user is a bad idea.

As for the collections, You must create them in shared code or they will not exist on the client. Personally create packages for all of my models and define collections and schemas in shared space and allow/deny and collection hooks on the server. You can also easily achieve this same thing with a directory structure in you app though.

3

Yeah, this seems like a really good idea. I don’t know what might come from people reading my allow/deny functions in the console, but in the worst case scenario, they will see a way to exploit them that I didn’t think of. That’s all the reason I need to move mine to the /server directory.

1 Like