Does the policy prohibiting jQuery in enterprise applications make sense?

Are there any vulnerabilities in jQuery (2) that were not addressed in the latest version, for example? Any other valid reason why security packages will mark the library as unsafe?

This question is related to (1), but is broader in nature.

(1) - jQuery vulnerability (NVD CVE-2007-2379)

(2) - http://www.networkworld.com/news/2007/040207-javascript-ajax-applications.html

+4
source share
6 answers

In a word? No.

+8
source

Ask yourself: if you plan to develop and deploy a corporate application that has enough Javascript code on the client, which jQuery seems to be a useful tool for use, how confident are you on the client side security of your own development team? "Basic" framework; Dojo, prototype, jQuery, MooTools, even Qooxdoo - to attract the attention of some of the most knowledgeable and experienced Javascript encoders in the industry and a huge susceptibility to testing in a variety of conditions.

In addition, it is true that this is your own application code that is going to make or break your security history, except in rare cases.

+4
source

I'm going to let hardcore security gurus give a final verdict on this, but I think you pretty much understand it simply because of the nature of jQuery as a library. If there is a serious leak, it should be in the core JavaScript core, and not in the library built on top of it.

+2
source

I do not believe that you will have many vulnerabilities in jQuery that are not in their main security vulnerabilities in the implementation of JavaScript Javascript.

+1
source

JQuery or javascript is not vulnerable, website developers write that they are vulnerable because they really do not know the business or because from time to time there is someone smarter than a web expert.

Probably the most dangerous part will be Ajax requests (jQuery or javascript driven ;-)), because there is a tendency to relax in security matters.

But this is only the beginning in any application, even if there is no javascript line, the client / user can use javascript / jquery using simple Firebug, so checking is always required for the client and the shared server.

A quick and simple example: I can change the values ​​of a specific form using javascript, even if the values ​​are readonly, etc.

+1
source

I agree that jQuery is reliable and reliable for the enterprise.

However, I would add two caveats based on personal experience that we encountered after the jQuery statement.

1) jQuery itself is safe, but jQuery plugins can have vulnerabilities (I think XSS). When we approved jQuery for enterprise use, the developers suddenly used random third-party plugins that were not easy to identify for vulnerabilities. If you open the door to jQuery, you need to clearly understand which plugins in the jQuery ecosystem are also allowed.

2) jQuery greatly simplifies the work with user interfaces, which can be both good and bad. We passed our user interface design to a design firm that went crazy using jQuery for complex user interface effects. The client liked the visual effects, but we realized too late that the jQuery user interface code was cumulatively very slow in Internet Explorer. As a result, we spent a lot of time optimizing our code for IE. They were not known during dev, as everyone used Firefox / Chrome, which have excellent JavaScript engines.

0
source

All Articles