The following is a discussion of JavaScript Security
Understanding Security
You may have noticed that when you try to use the window.close() method on the main browser window, a confirmation box appears asking if you really want to allow the window to be closed. This situation is one of the issues of JavaScript security.
The browser does not want a site to close a window that the viewer opened without permission from the viewer. If that were allowed, the programmer would have some control of the viewer's computer, which could be a problem.
Another aspect of security is the thought that you can "protect" Web pages with passwords or keep the source code of the page from being viewed by a user.
Security and Signed Scripts
To get permission to close the main browser window or to use certain properties or methods in JavaScript, you must use signed scripts. Signed scripts will open up some additional JavaScript features, but you must do some additional work. Signing scripts involves generating a digital signature and associating that signature with the script it signs. By signing a script using a valid certificate issued from a certificate authority (such as VeriSign) you certify that you are the owner of the script and that the script was not modified before reaching the end user. Because signed scripts offer this proof of identity, only signed scripts can be granted extended privileges by the user. Using this model you can sign any JavaScript in an HTML page or referred to by the HTML page with /SCRIPT SRC="..."/.
A signed script can request expanded privileges that give it access to restricted information and abilities. You can use these expanded privileges to exercise fine-grained control over activities beyond those which are normally allowed to JavaScript. You should always keep in mind that a user may deny the privileges requested by your script. You should write your scripts to react gracefully to such decisions. For more information on signed scripts, go to Signed Scripts in Mozilla.
Page Protection
Many scripts attempt to keep viewers out in some way, such as by using password protection or by using a "no-right-click" script to keep the source code of the page from being viewed. (I have used a no-right-click to attempt to secure photos on pages but it only worked on the first right click, from that point on, the photos were available) However, these security strategies are largely ineffective because these "no-right-click" scripts can often be bypassed by turning off JavaScript or by doing a little extra work.
Some password systems are better then others, but none really seem to offer true Web page security. If you don't want someone to view a page, much better methods exist than using a JavaScript system, such as using server-side languages or using certain setups on your Web server. Keep in mind that a JavaScript password system is unlikely to be foolproof and that you should not protect anything important with this system.
Many of us would love to hide the source code of our pages however JavaScript isn't going to do the trick. A number of scripts try various means of disabling the right-click. Basically these stategies don't work because they can be bypassed in different ways. In the long run they just make viewing the source code more difficult.
The Same-Origin Policy
The primary JavaScript security policy is the same-origin policy. The same-origin policy prevents scripts loaded from one Web site from getting or setting properties of a document loaded from a different site. This policy prevents hostile code from one site from "taking over" or manipulating documents from another. Without it, JavaScript from a hostile site could do any number of undesirable things such as snoop keypresses while you’re logging in to a site in a different window, wait for you to go to your online banking site and insert spurious transactions, steal login cookies from other domains, and so on. For more information on same-origin policy, go to Windows IT Library.
Cross-Site Scripting
Not all security problems related to JavaScript are the fault of the browser. Sometimes the creator of a Web application is to blame. Consider a site that accepts a user name in form input and then displays it in the page. Entering the name “Fred” and clicking Submit might result in loading a URL like http://www.example.com/mycgi?username=Fred, and the following snippet of HTML to appear in the resulting page:
Hello, Fred!
But what happens if someone can get you to click on a link to http://www.example.com/ mycgi?username=Fred"script"alert(‘Uh oh’);"/script"? The CGI might write the following HTML into the resulting page:
Hello, Fred"script"alert('Uh oh');"/script"
The script passed in through the username URL parameter was written directly into the page, and its JavaScript is executed as normal.
This exceedingly undesirable behavior is known as cross-site scripting (commonly referred to as XSS). It allows JavaScript created by attackers to be “injected” into pages on your site. The previous example was relatively benign, but the URL could easily have contained more malicious script.
For more information, go to Dev Articles.
Security, whether it be with JavaScript or plain HTML will always be a concern to developers and end users a like. By staying on top of the game and installing the newest patches and security measures, you can protect yourself somewhat from malicious code and hackers who have far too much time on their hands. "Better to be safe then sorry" should be the motto of all web developers.