Javascript doesn’t let you give private data or methods to objects, like you can in C++. Oh, well actually, yes it does, via some workarounds involving closure. But coming from a Python background, I am inclined to believe that “pretend privacy” (via naming conventions and documentation) is good enough, or maybe even preferable to “enforced privacy” (enforced by Javascript itself). Sure, I can think of situations where this is not true — e.g. people interface with my code without RTFM but I get blamed — but I’m not in that situation.
But, something gives me pause. Javascript guru Douglas Crockford, in “Javascript: The Good Parts” and elsewhere, repeatedly refers to fake-privacy as a “security” issue. For example, “an attacker can easily access the fields directly and replace the methods with his own”.
I’m confused by this. It seems to me that if I follow minimal security practices (validate, don’t blindly trust, data sent from a browser to my server; don’t include third-party scripts on my site without inspecting them) then there is no situation where pretend-privacy is less “secure” than enforced privacy. Is that right? If not, what’s a situation where pretend-privacy versus enforced-privacy has security implications?
It seems the answer is “No, fake privacy is fine”. Here are some elaborations:
In javascript as it exists today, you cannot include an unknown and untrusted third-party script on your webpage. It can wreak havoc: It can rewrite all the HTML on the page, it can prompt the user for his password and then send it to an evil server, etc. etc. Javascript coding style makes no difference to this basic fact. See PleaseStand’s answer for a discussion of methods to deal with this.
An incompetent but not evil script might unintentionally mess things up through name conflicts. This is a good argument against creating lots of global variables with common names, but has nothing to do with whether to avoid fake-private variables. For example, my banana-selling website might use the fake-private variable
window.BANANA_STORE_MODULE.cart.__cart_item_array. It is not completely impossible that this variable would be accidentally overwritten by a third-party script, but it’s extraordinarily unlikely.There are ideas floating around for a future modification of javascript that would provide a controlled environment where untrusted code can act in prescribed ways. I could let the untrusted third-party javascript interact with my javascript through specific exposed methods, and block the third-party script from accessing the HTML, etc. If this ever exists, it could be a scenario where private variables are essential for security. But it doesn’t exist yet.
Writing clear and bug-free code is always, obviously, helpful for security. Insofar as truly-private variables and methods make it easier or harder to write clear and bug-free code, there’s a security implication. Whether they are helpful or not will always be a matter of debate and taste, and whether your background is, say, C++ (where private variables are central) versus Python (where private variables are nonexistent). There are arguments in both directions, including the famous blog post Javascript Private Variables are Evil.
For my part, I will keep using fake privacy: A leading underscore (or whatever) indicates to myself and my collaborators that some property or method is not part of the publicly-supported interface of a module. My fake-privacy code is more readable (IMO), and I have more freedom in structuring it (e.g. a closure cannot span two files), and I can access those fake-private variables while I debug and experiment. I’m not going to worry that these programs are somehow more insecure than any other javascript program.