Important Security Information

Retrieved 2/24/2013 from NoScript facts at  http://noscript.net/faq#qa1_7

 1.10

Q:   Why should I allow JavaScript, Java, Flash and plugin execution only for trusted sites?
A:   JavaScript, Java and Flash, even being very different technologies, do have one thing in common: they execute on your computer code coming from a remote site.
All the three implement some kind of sandbox model, limiting the activities remote code can perform: e.g., sandboxed code shouldn't read/write your local hard disk nor interact with the underlying operating system or external applications.
Even if the sandboxes were bullet proof (not the case, read below) and even if you or your operating system wrap the whole browser with another sandbox (e.g. IE7+ on Vista or Sandboxie), the mere ability of running sandboxed code inside the browser can be exploited for malicious purposes, e.g. to steal important information you store or enter on the web (credit card numbers, email credentials and so on) or to "impersonate" you, e.g. in fake financial transactions, launching "cloud" attacks like Cross Site Scripting (XSS) or CSRF, with no need for escaping your browser or gaining privileges higher than a normal web page. This alone is enough reason to allow scripting on trusted sites only.
Moreover, many security exploits are aimed to achieve a "privilege escalation", i.e. exploiting an implementation error of the sandbox to acquire greater privileges and perform nasty task like installing trojans, rootkits and keyloggers.
This kind of attack can target JavaScript, Java, Flash and other plugins as well:

1. JavaScript looks like a very precious tool for bad guys: most of the fixed browser-exploitable vulnerabilities discovered to date were ineffective if JavaScript was disabled. Maybe the reason is that scripts are easier to test and search for holes, even if you're a newbie hacker: everybody and his brother believe to be a JavaScript programmer :P
   
2. Java has a better history, at least in its "standard" incarnation, the Sun JVM.
   There have been viruses, instead, written for the Microsoft JVM, like the ByteVerifier.Trojan. Anyway, the Java security model allows signed applets (applets whose integrity and origin are guaranteed by a digital certificate) to run with local privileges, i.e. just like they were regular installed applications. This, combined with the fact there are always users who, in front of a warning like "This applet is signed with a bad/fake certificate. You DON'T want to execute it! Are you so mad to execute it, instead? [Never!] [Nope] [No] [Maybe]", will search, find and hit the "Yes" button, caused some bad reputation even to Firefox (notice that the article is quite lame, but as you can imagine had much echo).
   
3. Flash used to be considered relatively safe, but since its usage became so widespread severe security flaws have been found at higher rate. Flash applets have also been exploited to launch XSS attacks against the sites where they're hosted.
   
4. Other plugins are harder to exploit, because most of them don't host a virtual machine like Java and Flash do, but they can still expose holes like buffer overruns that may execute arbitrary code when fed with a specially crafted content. Recently we have seen several of these plugin vulnerabilities, affecting Acrobat Reader, Quicktime, RealPlayer and other multimedia helpers.
   

Please notice that none of the aforementioned technologies is usually (95% of the time) affected by publicly known and still unpatched exploitable problems, but the point of NoScript is just this: preventing exploitation of even unknown yet security holes, because when they are discovered it may be too late ;)
The most effective way is disabling the potential threat on untrusted sites.