NoScript's preemptive script blocking approach and its frequent updates give it a reputation for safet.
Security and usage
NoScript takes the form of a toolbar in Firefox. It will display every site whose content is being both blocked and allowed for the current page being viewed, with options to either allow the blocked content or forbid the allowed content. Additional options can also be modified through this toolbar.
Site matching and whitelisting
For each site, the exact address, exact domain, or parent domain can be allowed, and subsequently, its content will be executed. By enabling a domain, (e.g. mozilla.org), all its subdomains are implicitly enabled (e.g. www.mozilla.org, addons.mozilla.org and so on) with every possible protocol (e.g. http and https). By enabling an address (protocol://host, e.g. http://www.mozilla.org, its subdirectories are enabled (e.g. http://www.mozilla.org/firefox and http://www.mozilla.org/thunderbird), but not its domain ancestors nor its siblings. Therefore, mozilla.org and addons.mozilla.org will not be automatically enabled.
Sites can also be blacklisted with NoScript. Blacklisting a site not only blocks it from executing scripted content, but also removes the option of allowing it to execute said content, unless it is removed from the blacklist.
By default, Anti-XSS protection filters all requests from untrusted origins to trusted destinations, considering trusted either "Allow"ed or "Temporary allow"ed sites. Furthermore, since version 220.127.116.11 NoScript also checks requests started from whitelisted origins for specific suspicious URL patterns landing on other trusted sites: if a potential XSS attack is detected, even if coming from a trusted source, filters are promptly triggered.
NoScript is very popular, often topping Mozilla's most popular extension list
NoScript has also received numerous awards and recommendations, and is often recommended by the media. It has received critical acclaim, winning a PC world 2006 world class award.
NoScript is sometimes viewed as overkill, unnecessary, and tedious.
NoScript's unique whitelist based pre-emptive script blocking approach prevents exploitation of security vulnerabilities (known and even not known yet!) with no loss of functionality...
Watch the "Using NoScript" video kindly contributed by John Wilkerson.
When you browse a site containing blocked scripts, a brief sound is optionally played and a notification, similar to those issued by popup blocker, is shown.
Look at the statusbar icon to know current NoScript permissions:
- - this means that scripts are blocked for the current site
- - this means scripts are allowed for some of the URLs sourcing scripts from the current site. It happens when there are multiple frames, or script elements linking code hosted on 3rd party hosts.
- - this means scripts are allowed for some URLs, and all the other ones are marked as untrusted.
- - this means that script execution is allowed for the current site
- - this means that scripts are globally allowed (why did you decide to browse without any protection??!)
If you left click on the icon, you can change script permissions using a simple menu.
You can reach the same menu by right clicking over the document, so you can operate also in windows which don't provide a status-bar. Of course, if you don't like contextual menus, you can hide it.
Most menu items are in the form "Allow somesite.com", "Temporarily allow somesite.com", "Forbid somesite.com". The "Temporarily" permissions are in effect until you exit the browser.
- Allow Scripts Globally (dangerous) switches NoScript in the (not recommended) "Default Allow" mode. Only sites and objects explicitly marked as untrusted will be disabled. Other security features, like Anti-XSS protection or Automatic Secure Cookie Management will still be effective, though.
- Allow all this page and Temporarily allow all this page enable every site shown as allowable by NoScript's menu on the current page, unless already marked as untrusted.
- Make page permissions permanent permanently enables every site shown as temporarily allowed by NoScript's menu on the current page.
- Revoke temporary permissions cancels all the "Temporary allow" commands issued during this session.
A toolbar button is also provided: right click on your toolbar and select the Customize menu item to add it. By clicking on the NoScript toolbar button you will toggle the forbidden/allowed state of the top-most site in the current page, i.e. the one displayed in your address bar. Also, if you click the tiny arrow near the NoScript toolbar button, the usual NoScript menu will be dropped down.
- CTRL + SHIFT + \ (backslash) toggles allowance status for the current top-level site - temporarily by default, to make it permanent set the about:config noscript.toggle.temp preference to false.
- CTRL + SHIFT + S opens the NoScript status bar menu, which lets you perform every NoScript related operation using the cursor keys.
Both these shortcuts can be changed using the about:config noscript.key.* preferences.
Every NoScript menu includes a command to open the Options dialog: you use it to allow or forbid many sites at once, to customize user interface and to decide if you want to automatically reload current site when you change permissions. Other useful options are also available there.
For each site you can decide to allow the exact address, or the exact domain, or a parent domain. If you enable a domain (e.g. mozilla.org), you're implicitly enabling all its subdomains (e.g. www.mozilla.org, addons.mozilla.org and so on) with every possible protocol (e.g. http and https). If you enable an address (protocol://host, e.g. http://www.mozilla.org, you're enabling its subdirectories (e.g. http://www.mozilla.org/firefox and http://www.mozilla.org/thunderbird), but not its domain ancestors nor its siblings, i.e. mozilla.org and addons.mozilla.org will not be automatically enabled.
By default only the 2nd level (base) domain is shown (e.g. mozilla.org) is shown in the menus, but you can configure appearance to show full domains and full addresses as well.
- Jolly port matching - an address with a 0 (zero) port specification will match every site with the same protocol, domain and any non-standard port: if one is met during navigation, it gets temporarily enabled. For instance, http://acme.org:0 matches http://acme.org:8080 and http://acme.org:9999, but not https://acme.org:9999 (different protocol) nor http://acme.org (standard 80 port, omitted). Since protocol specification is mandatory, regular subdomain matching with rightmost components comparison couldn't work for multiple subdomain. You can specify subdomain matching patterns using an asterisk in place of the leftmost domain component: for instance, you need to match all the subdomains of acme.org for all ports with the HTTPS protocol, you can whitelist https://*.acme.org:0. This is the ONLY situation where asterisk is considered a wildcard.
- Subnet matching - an address with a partial numeric IPv4 IP will match all the subnet. You must specify at least the 2 leftmost bytes, e.g. 192.168 or 10.0.0. Again, matching sites will be temporarily allowed on demand.
Important notice: the asterisk character (*) have NO special meaning to NoScript, other than subdomain matching in Jolly port matching patterns (see above). Asterisk is NOT a general wildcard, so if you're typing it while manually adding a site to your whitelist, double check you know what you're doing. By the way, most of the time you prefer not to fiddle with your whitelist manually: just use the NoScript "Allow" and "Forbid" menu items, it's much simpler and error free!
On a non-whitelisted site you can still temporarily allow an individual plugin object with just one left click on its placeholder (screenshot). The movie/applet/clip will stay enabled until the end of the session or until you Revoke Temporary Permissions.
Middle clicking on a Java/Silverlight/Flash/Plugin object placeholder opens it in a window of its own.
Right clicking on a Java/Silverlight/Flash/Plugin object placeholder opens the context menu for links, allowing you to save the content with Save Link As....
Holding down the Shift key and clicking on a Java/Silverlight/Flash/Plugin object placeholder temporarily hides it.
You can also use the Blocked Objects menu to find out which plugin content instances you're blocking even if their placeholder is not easily visible, and/or enable them individually, per site or per type.
It's worth noticing that while early NoScript versions used to block plugin content objects checking exclusively their origin, i.e. the site where they were downloaded from, most recent NoScript versions check also the parent site which is embedding the content: a non-whitelisted site won't be able to run a plugin content piece, even if coming from a trusted site, unless you explictly unblock it through its placeholder or the Blocked Objects menu.
This behavior is meant to provide effective protection against Flash-based XSS. Reverting to the old behavior is possible, even if not recommended: just switch the noscript.forbidActiveContentParentTrustCheck about:config preference to false.
Finally, toggling NoScript Options/Plugins/Apply these restrictions to trusted sites too extends the plugin content restrictions you set for untrusted sites also to whitelisted pages, turning NoScript in a general content blocker for Java, Silverlight, Flash and other plugins functionally similar to FlashBlock.
You can configure some exception to the Forbid Other Plugins option by setting the noscript.allowedMimeRegExp about:config preference to a pattern matching the content types you want to allow. For instance, setting it to "application/pdf" will let PDF document load automatically on every site. That said, are you sure you need to? Adobe Acrobat Reader plugin got its share of vulnerabilites so far, and after all, you can still allow individual PDF documents from untrusted sites just clicking on their placeholders.
Some sites, especially those serving ads, can appear in your "Allow ..." menu more often than you like, making it too much long and noisy.
If you know you don't want to allow a certain site now and in the foreseeable future, you can permanently mark it as untrusted: just click the NoScript icon, open the Untrusted menu and select the Mark bad-site.com as Untrusted menu item.
NoScript won't even propose you to allow it again and your NoScript will be even more clean and usable.
If you later change your mind, don't worry: just open the Untrusted menu again (on the same page), and you'll find the Allow bad-site.com command there.
This feature is especially useful if you decided to use the (not recommended) NoScript Options|General|Temporarily allow top level sites by default mode, because sites marked as untrusted won't be allowed anyway.
Advanced users: even though the untrusted sites blacklist has no listing UI of its own, you can mass-edit it either modifying the noscript.untrusted about:config preference or using the Import/Export functionality of the NoScript Options|Whitelist panel, knowing that the untrusted entries are exported under an [UNTRUSTED] header.
Cross-Site Scripting (XSS) vulnerabilities are usually programming errors made by web developers, which allow an attacker to inject his own malicious code from a certain site into a different site. They can be used, for instance, to steal your authentication credentials and, more in general, to impersonate you on the victim site (e.g. your online banking or your web mail).
NoScript features unique Anti-XSS counter-measures, even against XSS Type 1 attacks targeted to whitelisted sites.
Then a yellow notification bar displays a message like
"NoScript filtered a potential cross-site scripting (XSS) attempt from [some-evil-url.com]. Technical details have been logged to the Console."
On the left side of this bar there's also an "Options..." button: if you click it, you can choose among the following actions:
- Show Console, displaying the Error Console where further technical details about the actions taken by NoScript are logged.
- Unsafe Reload, which will "replay" the request bypassing XSS filters. Use this command only if you're absolutely sure that NoScript detected a false positive.
- Suppress the XSS-related notifications (you will still be able to operate through the standard NoScript menu).
- Open the XSS Options panel.
- Navigate to the XSS FAQ web page.
The specific Anti-XSS counter-measures are controlled by the NoScript Options|Advanced|XSS options.
Both these options are enabled by default for your maximum protection.
By default, Anti-XSS protection filters all requests from untrusted origins to trusted destinations, considering trusted either "Allow"ed or "Temporary allow"ed sites. If you prefer "Temporarily allow"ed sites to be still considered as untrusted origins from the XSS point of view, you just need to set about:config noscript.xss.trustTemp preference to false.
Furthermore, NoScript checks also requests started from whitelisted origins for specific suspicious URL patterns landing on other trusted sites: if a potential XSS attack is detected, even if coming from a trusted source, filters are promptly triggered.
This feature can be tweaked changing the value of the noscript.injectionCheck about:config preference as follows:
0 - never check
1 - check cross-site requests from temporary allowed sites
2 - check every cross-site request (default)
3 - check every request
NoScript's Anti-XSS filters have been deeply tested and proved their ability to defeat every known reflective XSS technique, but their power is a double-edged sword: sometime they may detect a weird looking but legitimate request as a "potential XSS attempt". This should almost never be a show stopper, since the filter most of the time doesn't prevent you from navigating the filtered page, but the aforementioned Unsafe reload command and the XSS Advanced Options have been made easily accessible so you can work-around if you hit a false positive with side effects. Just please notify me when it happens, possibly reporting the messages NoScript logged (the lines starting with "[NoScript XSS]" in the Error Console), so I can keep tweaking NoScript's "XSS sensibility" as needed.
While Cross-Site Scripting (XSS) vulnerabilities need to be fixed by the web developers, users can finally do something to protect themselves: NoScript is the only effective defense available to "web-consumers", waiting for "web-providers" to clean up their mess.
See also the NoScript XSS FAQ, or read the excellent Cross Site Scripting Attacks: Xss Exploits and Defense book.
Most NoScript options are quite simple and self explanatory.
Default values are almost always OK, however you may find useful knowing about these:
| || |