In your evolution as a web developer, you'll run into some security problems eventually. The makers of JavaScript have identified and solved most of the really glaring security holes; the browser vendors have plugged up some the holes themselves, along with adding a certain measure of guaranteed security through browser operations. There are several different approaches to security inherent in JavaScript. Each has its own pros and cons, but as a whole they work pretty well. Some of the security procedures are within the JavaScript interpreter, and some are within the browser itself. As you begin to develop, you (or your employer) will no doubt insist on the implementation of some measure of security. Not taking security considerations into account will lead to tampering. It's a fact, so you have to deal with it. Leaving out security in your development will open your creation (and your company) to tampering. Your site users will not use your offered content when word gets out that they are vulnerable due to your security holes.
The browser runs off of the operating system itself; this means that the file system of the user's machine is a potential target for malicious users. It is entirely possible to access a user's directory listing through JavaScript. Hackers know this, and exploit it on a regular basis. Security starts with your servers, because it is there that the user downloads—and executes upon their machine—your code. Your servers must be tightly controlled and regularly monitored. Your code must be clean, leaving no threads open to outside access. This is the developer's responsibility...
Read full article on Developer.com