jQuery-Encoder updated

I have made several updates to the jqencoder plugin over the weekend and thought I would share a little about them quickly.

Plugin Readme: http://bit.ly/ie4J04

First, and most importantly - I have added a series of static methods (that look similar to the methods on the Encoder interface for ESAPI) to perform particular contextual encoding tasks - specifically when building html dynamically rather than building elements up using the DOM.

• encodeForHTML
• encodeForHTMLAttribute
• encodeForCSS
• encodeForURL
• encodeForJavascript

Each of these methods can be accessed under the static $.encoder context.

$.post('http://untrusted.com/external_profile', function(profile) {
      $('#widget').html('<div id="untrusted_widget" width="' + 
                        $.encoder.encodeForHTMLAttribute(profile.width) + 
                        '" onmouseover="' + profile.callback + "(\'' +
                        $.encoder.encodeForJavascript(profile.parm) + 
                        '\')">' + $.encoder.encodeForHTML(profile.data) + 
                        '</div>');
   }

In addition, the $.canonicalize method has also been moved into the $.encoder context.

$('#phonenumber').blur(function() {
      validatePhoneNumber($.encoder.canonicalize(this.val());
   });

The third, and final big change over the weekend - was solidifying the ES5 immutable objects protection. If it is supported by the browser, the $.encoder object will be frozen, sealed, or non-extensible (in that order of priority) to protect the encoding and canonicalize functions themselves from being tampered with at runtime. At this point in time, Chrome has implemented Object.freeze in the latest release version, Mozilla has implemented it in Firefox 4 and Microsoft have implemented it in IE9. Safari shows no indication of implementing it, and neither does Opera.

Now, I pose a question to the developers that may use this plugin. Is there a need to keep the instance method $.fn.encode? It seems to me that due to the nature of setting DOM element properties via Javascript, that this is not really needed at all. So, should I nuke it?

I end this post with a final thought (continuing from my above conversation of Object.freeze)

I strongly recommend that developers start taking the initiative to make their custom JS objects immutable, and also recommend making framework objects immutable as well. If you were to (using jQuery) issue the following in your onready handler

$(document).ready(function(){
   if ( Object.freeze ) $ = Object.freeze($);
   // .. initialize page below here
});

It seems to me, this could eliminate a lot of potential vulnerability exploitation of bugs in framework code. What are your thoughts?

Also, why not consider the following:

var lock_objs = [ String.prototype, 
                     Array.prototype, 
                     Function.prototype, 
                     Object.prototype ];
   for (var i=0;i<lock_objs.length;i++) lock_objs[i] = Object.freeze(lock_objs[i]);