There is no good way to scan Javascript for malicious code. You can't do it. The problem is that there are too many ways a malicious/rogue developer can hide malicious stuff in their code, and you'll never be able to detect it all.
Anti-virus is not helpful here. You need to understand a little bit about how anti-virus software works and its limitations. Roughly speaking, here's how it works. If the anti-virus company detects a virus infecting many machines, then they analyze the virus, identify a signature of the virus (e.g., an excerpt of its code), and build this into their engine. Thereafter, if your machine gets infected by a copy of that particular copy (the exact same one they analyzed), then the anti-virus software will detect its presence through this signature. As a result, anti-virus software is useful primarily only against viruses that have spread widely. Existing anti-virus software is not going to detect malicious code in a rogue extension for your webapp. Anti-virus software has some uses, but it is basically useless for your particular scenario.
You need to accept that this is not a problem you can solve by scanning code. So, you'll need to consider some other approach. What are your options? There are several:
You could give up and embrace the chaos. You could create a public site for extensions, allow users to rate extensions, and post/view reviews. This way, if a developer posts a low-quality extension that is buggy or crashes things, users who notice it can post a negative review. (Of course, if the developer is malicious and posts an evil extension, there's no guarantee that anyone will ever notice -- if you're lucky, maybe some user will happen to notice the malicious code somehow and report it to you, but it's just as likely that no one will ever notice. That's the risk you take.)
This is known as having an open extension system. See, e.g., the Android Market or the Google Chrome Extension Gallery or Userscripts.org (a Greasemonkey extension site).
You could institute some kind of review system, where experts review each extension before it is posted (or shortly after it is posted) on the public extension site. If you just want to catch quality problems, it might be enough to have the experts install the extension and test it, and perhaps run a code quality bug-finding tool to scan for common problems. If you also want to catch malicious extensions, the reviewer will need to be a developer who is capable of reading code and who reads through the extension line-by-line; this is extremely tedious and time-consuming, but there's not really any better option.
This is known as having a curated extension system. See, e.g., the Apple iOS App Store or the Firefox extension site (addons.mozilla.org) for some examples, though I believe they focus only on code quality and not on detecting malice.
Whichever approach you take, there is a significant advantage to extensions served from a single public extension site, which hosts the authoritative version of the extension. You might want to take various steps to encourage users to install extensions from that site and discourage them from installing extensions from other sites (e.g., by default disable installing extensions from other sources and require the user to click to authorize any other domain they want to install from, like Firefox does). What's the benefit? The benefit is that this ensures that all of your users get the same copy of the extension. It prevents attacks, e.g., where a malicious web site uses some script to check whether the user's browser version and where the user is coming from, and based upon that, decide whether to serve malicious code or legitimate code -- those kinds of attacks make it harder to detect malice, so stopping them is a good thing. It also ensures that users get the benefits of reviews and ratings.
You should also consider carefully which APIs are exposed to extensions and which are not. You might consider exposing only a subset of the API to extensions, so that extensions are inherently limited in what they can do, as a way to limit the damage. For instance, the Chrome browser allows extensions to interact with the web page's DOM and the web site, but extensions are not allowed to execute native code (e.g., install and run a .exe). This kind of thing helps security. Alternatively, you could provide a basic API which avoids the highest-risk APIs, and then require any extension which requires access to more than the basic API must get approval from the moderators first before they can be posted on the public site.
Another possible defense against malicious extensions is to introduce a permission system. You identify a set of permissions. The extension is required to include a manifest, which specifies the set of permissions it needs. When the user installs the permission, the system should show the user the set of permissions the extension is requesting and what those permissions imply (e.g., what security/privacy risks they pose, what access they grant to the extension), allowing the user to either approve the permissions and proceed with installation or to reject the permissions and cancel installation. This gives users more control and visibility over extensions, reduces the risks of buggy extensions (because the consequences of a security vulnerability in an extension are now limited to only the permissions it requested, not all permissions), and may make malicious extensions more apparent (because they need to request certain permissions to do harm). See, e.g., Android applications or Google Chrome extensions for an example of this sort of thing.
